Was ist der Maker-Checker-Workflow?

Was ist der Maker-Checker-Workflow?\n\nBei der Bekämpfung von Finanzkriminalität, der Fraud-Prävention und in Compliance-Prozessen kann es erhebliche Risiken bergen, wenn bestimmte Vorgänge durch die Entscheidung einer einzelnen Person freigegeben werden. Bei Schritten wie der Liveschaltung einer neuen Regel, dem Schließen eines hochriskanten Falls oder der Umsetzung einer kritischen Maßnahme ist eine zweite Kontrollinstanz unerlässlich.\n\nDer Maker-Checker-Workflow ist ein Kontrollmechanismus, der sicherstellt, dass die Person, die eine kritische Transaktion oder Aktion vorbereitet, diese nicht im Alleingang genehmigen kann.\n\nDie Logik ist einfach:\n\nDer Maker bereitet den Vorgang vor. Der Checker prüft, genehmigt oder sendet ihn zur Überarbeitung zurück.\n\nDiese Struktur gewährleistet insbesondere in AML-, Fraud Detection-, Rule Engine- und Case Management-Prozessen die Aufgabentrennung, reduziert Fehler und erleichtert die Nachverfolgbarkeit von Entscheidungen.\n\n## Wie funktioniert der Maker-Checker-Workflow?\n\nNehmen wir an, ein Compliance-Spezialist erstellt eine neue Transaction Monitoring-Regel.\n\nDer Spezialist legt fest, welches Verhalten als risikoreich eingestuft wird, gibt die Schwellenwerte ein und definiert, für welche Kunden- oder Transaktionssegmente die Regel gelten soll.\n\nIn dieser Phase agiert der Spezialist in der Rolle des Makers.\n\nAnstatt die Regel direkt live zu schalten, wird sie an den Checker übermittelt. Der Checker prüft die Bedingungen, Schwellenwerte und die potenziellen Auswirkungen der Regel auf den operativen Betrieb.\n\nBei Bedarf können auch Simulationsergebnisse herangezogen werden, um zu sehen, wie sich die Regel auf historische Daten ausgewirkt hätte.\n\nWenn der Checker die Regel für angemessen hält, genehmigt er sie. Wenn er Änderungen für notwendig erachtet, sendet er sie mit einer Begründung an den Maker zurück.\n\nAuf diese Weise wird eine kritische Änderung niemals durch die Entscheidung einer einzelnen Person implementiert.\n\n## Warum ist eine zweite Kontrolle erforderlich?\n\nEine kleine Änderung an einer Regel kann im operativen Betrieb massive Auswirkungen haben.\n\nWenn beispielsweise der Schwellenwert für ein Szenario, das normalerweise Kunden mit 10 Transaktionen in den letzten 24 Stunden untersucht, versehentlich auf 2 gesetzt wird, kann dies in kürzester Zeit zu einer extrem hohen Anzahl von Alerts führen.\n\nIn diesem Fall müsste das Compliance-Team irrelevante Alerts prüfen, anstatt sich auf tatsächliche Risiken zu konzentrieren.\n\nAuch das Gegenteil ist möglich: Wird der Schwellenwert zu hoch angesetzt, können verdächtige Verhaltensweisen, die eine Überprüfung erfordern, unentdeckt bleiben.\n\nDie Maker-Checker-Struktur schafft hier eine zweite Kontrollinstanz.\n\nDas Ziel ist nicht, den Prozess zu verlangsamen, sondern sicherzustellen, dass kritische Änderungen kontrolliert ablaufen.\n\n## Wie wird es in Case Management-Prozessen eingesetzt?\n\nEin wesentlicher Anwendungsbereich des Maker-Checker-Ansatzes sind Case Management-Prozesse.\n\nWenn ein Alert untersucht wird, liegt dem Analysten nicht nur eine einzelne Transaktion vor. Die Kundenhistorie, Screening-Ergebnisse, verknüpfte Konten, frühere Fälle und andere Risikosignale können gemeinsam bewertet werden.\n\nDer Analyst schließt seine Untersuchung ab und schlägt eine Entscheidung für den Fall vor.\n\nDiese Entscheidung kann beispielsweise Folgendes umfassen:\n\n- Schließen des Falls,\n- Einleitung einer zusätzlichen Überprüfung,\n- Weiterleitung an ein anderes Team,\n- Einstufung in eine höhere Risikokategorie,\n- Vorbereitung für den Meldeprozess\n\nsein.\n\nJe nach dem vom Unternehmen definierten Workflow können kritische Entscheidungen zur Genehmigung an den Checker gesendet werden.\n\nDer Checker prüft dabei nicht nur das Ergebnis, sondern auch, auf welchen Beweisen und Begründungen die Entscheidung basiert.\n\nDies erleichtert es später, folgende Fragen zu beantworten:\n\nWer hat die Entscheidung getroffen? Wer hat sie geprüft? Auf welcher Informationsbasis wurde sie genehmigt?\n\n## Maker-Checker aufseiten der Rule Engine\n\nÄnderungen an der Rule Engine wirken sich direkt darauf aus, welche Verhaltensweisen vom System als risikoreich eingestuft werden.\n\nZum Beispiel:\n\n> Erstelle einen Alert, wenn innerhalb kurzer Zeit von demselben Device aus auf mehrere Konten zugegriffen wird.\n\nWenn die Anzahl der Konten, das Zeitfenster oder das Kundensegment in diesem Szenario geändert werden, ändert sich auch das Ergebnis, das die Regel generiert.\n\nDaher ist es ein wichtiger Kontrollmechanismus, dass die Person, die die Regel erstellt, und die Person, die deren Liveschaltung genehmigt, unterschiedliche Personen sind.\n\nDer Maker bereitet die Regel vor.\n\nAnschließend kann die Regel anhand historischer Daten getestet werden. Das erwartete Alert-Volumen und die Ergebnisse verschiedener Schwellenwerte werden bewertet.\n\nDer Checker prüft diese Daten und kann die Regel genehmigen oder eine Überarbeitung anfordern.\n\nDank dieser Struktur basieren Regeländerungen nicht auf bloßen Vermutungen, sondern werden auf der Grundlage möglichst messbarer Ergebnisse bewertet.\n\n## Warum ist die Aufgabentrennung wichtig?\n\nDer Maker-Checker-Ansatz basiert im Wesentlichen auf dem Prinzip der Aufgabentrennung.\n\nWenn ein Benutzer einen Vorgang sowohl erstellen als auch im Alleingang genehmigen kann, schwächt dies den Kontrollmechanismus.\n\nDaher sollten kritische Berechtigungen auf verschiedene Rollen verteilt werden.\n\nIn einer Organisation könnte dies beispielsweise wie folgt aussehen:\n\nAnalyst kann den Fall untersuchen. \nCompliance Manager kann die Entscheidung prüfen. \nAutorisierter Benutzer kann bestimmte Aktionen genehmigen.\n\nDa jedes Unternehmen eine andere Organisationsstruktur hat, muss nicht für jedes Unternehmen dasselbe Maker-Checker-Modell gelten.\n\nEntscheidend ist, dass klar definiert ist, welcher Benutzer welche Aktionen durchführen darf und welche Vorgänge eine zweite Genehmigung erfordern.\n\n## Warum ist ein Audit Trail Teil dieser Struktur?\n\nDie Genehmigung durch eine zweite Person allein reicht nicht aus. Die durchgeführten Aktionen müssen auch protokolliert werden, damit sie später überprüft werden können.\n\nAn dieser Stelle kommt das Immutable Audit Log ins Spiel.\n\nBeispielsweise kann im System Folgendes protokolliert werden:\n\n- wer den Vorgang erstellt hat,\n- welche Felder geändert wurden,\n- wann die Änderung vorgenommen wurde,\n- wer die Genehmigung erteilt hat,\n- ob der Vorgang zurückgesendet wurde,\n- auf welcher Grundlage die Entscheidung getroffen wurde.\n\nDiese Struktur erleichtert es insbesondere Compliance- und internen Revisionsteams, die Entscheidungshistorie nachzuvollziehen.\n\n## Was bietet Truvali bei Maker-Checker-Prozessen?\n\nBei Truvali wird der Maker-Checker-Ansatz nicht nur als einfacher Freigabebildschirm betrachtet. Er arbeitet nahtlos mit Plattformfunktionen wie Rule Engine, Case Management, Autorisierung und Audit Trail zusammen, um sicherzustellen, dass kritische Entscheidungen kontrolliert ablaufen.\n\nBeispielsweise kann der Prozess bei einem neuen AML- oder Fraud-Szenario wie folgt ablaufen:\n\n1. Der Maker erstellt den Regelentwurf.\n2. Schwellenwerte und Bedingungen werden definiert.\n3. Die Regel kann durch Simulationen auf historischen Daten getestet werden.\n4. Das erwartete Alert-Volumen und die operativen Auswirkungen werden bewertet.\n5. Die Regel wird zur Genehmigung an den Checker übermittelt.\n6. Der Checker genehmigt die Regel oder sendet sie zur Überarbeitung zurück.\n7. Änderungen und Genehmigungen im Prozess werden im Audit Trail lückenlos dokumentiert.\n\nEine ähnliche Struktur kann auch im Case Management angewendet werden. Wenn der Analyst eine Entscheidung für einen Fall trifft, können kritische Aktionen an die Kontrolle eines zweiten, autorisierten Benutzers gekoppelt werden.\n\nDank der Role-Based Access Control-Struktur von Truvali können die Berechtigungen der Benutzer für bestimmte Aktionen auf Rollenbasis getrennt werden. So kann beispielsweise ein Benutzer zwar die Berechtigung zum Erstellen einer Regel besitzen, nicht aber die Berechtigung, dieselbe Regel im Alleingang freizugeben.\n\nDieser Ansatz lässt sich auch in KI-gestützten Prozessen beibehalten. Truvali kann die Erstellung von Fallzusammenfassungen, Regelentwürfen oder Meldungsvorlagen unterstützen; kritische Ergebnisse können jedoch an die Überprüfungs- und Genehmigungsprozesse autorisierter Benutzer gekoppelt werden.\n\nDas Ziel besteht hierbei nicht darin, die menschliche Kontrolle durch Automatisierung zu ersetzen, sondern Automatisierung und Governance im selben Workflow zu vereinen.\n\n## Häufig gestellte Fragen zum Maker-Checker-Workflow\n\n### Können Maker und Checker dieselbe Person sein?\n\nDas Hauptziel dieser Struktur ist die Aufgabentrennung. Daher wird bei kritischen Vorgängen vorausgesetzt, dass die Rollen des Makers und des Checkers von unterschiedlichen Benutzern wahrgenommen werden.\n\n### Erfordert jeder Vorgang die Genehmigung eines Checkers?\n\nNein. Welche Vorgänge eine zweite Genehmigung erfordern, kann basierend auf den Risikorichtlinien und dem Berechtigungsmodell des jeweiligen Unternehmens festgelegt werden.\n\n### Wird das Maker-Checker-Prinzip nur für AML eingesetzt?\n\nNein. Es kann auch in den Bereichen Fraud Detection, Case Management, Rule Engine, Benutzerautorisierung und anderen kritischen operativen Prozessen eingesetzt werden.\n\n### Werden von KI erstellte Entwürfe automatisch angewendet?\n\nDas hängt von dem vom Unternehmen definierten Workflow ab. Kritische Ergebnisse können an die Überprüfung durch autorisierte Benutzer und die Maker-Checker-Genehmigung gekoppelt werden.