KYT-Regeln & Scoring: Velocity & Bedingungen

Jede an Didit übermittelte Transaktion wird anhand aller aktiven Regeln für Ihre Anwendung ausgewertet. Regeln definieren Bedingungen, Velocity-Prüfungen und Aktionen, die den endgültigen Status und den Score der Transaktion bestimmen. Dieses Kapitel der Lektion zur Betrugs-Regel-Engine in der Didit Academy setzt beim Erstellen einer Regel an. In der Academy-Lektion zur Regel-Engine wird ab 7:54 eine Regel vor laufender Kamera erstellt: Auslöser, Bedingungen, Aktionen und Scoring, danach das Backtesting vor dem Deployment.

​

Integrierte Regelpakete

Didit stellt eine vorkonfigurierte Regelbibliothek bereit, die gängige regulatorische Typologien abdeckt. Installieren Sie die gewünschten Voreinstellungen oder ganze Pakete aus der Bibliothek, entweder in der Konsole, über die Install-API oder mit den MCP-Tools, und steuern Sie den Modus jeder installierten Voreinstellung. Die vollständige Übersicht aller voreingestellten Regeln mit Schwellenwerten und Aktionen finden Sie in der Regelbibliothek.

​

Regelquellen

Jede Regel hat eine source, die angibt, wer sie verwaltet:

​

Aufbau einer Regel

Jede Regel besteht aus folgenden Bestandteilen:

​

Aktionen

Wenn eine Regel mit einer Transaktion übereinstimmt, werden eine oder mehrere Aktionen ausgeführt. Jede Regel kann mehrere Aktionen haben, die alle gemeinsam angewendet werden: Die meisten vorkonfigurierten Regeln kombinieren Score hinzufügen mit Status ändern. Beispielsweise addiert eine Regel für eine sanktionierte Gegenpartei 90 Punkte zum Score und lehnt die Transaktion sofort ab.

​

Benutzerverifizierung erforderlich (AWAITING_USER)

Eine Aktion Status ändern → AWAITING_USER setzt nicht nur einen Status. Didit erstellt beim Auslösen der Regel automatisch eine gehostete Verifizierungssitzung für das Subjekt der Transaktion (dieselbe vendor_data). Die Sitzung wird im Block action_required der Transaktion (und im Objekt remediation) in der Antwort auf die Erstellung sowie bei jedem späteren Lesen zurückgegeben. Sie erscheint außerdem in beiden Transaktions-Webhooks. So können Sie den Benutzer sofort weiterleiten. Siehe erforderliche Benutzeraktionen. Benutzerdefinierte Regeln müssen den Workflow in der Aktion selbst angeben (workflow_id). Sowohl der Regel-Builder der Konsole als auch die Regel-API verlangen dies. Vorkonfigurierte Regeln der Bibliothek enthalten keinen Workflow. Für sie wird der Sitzungs-Workflow in dieser Reihenfolge ermittelt:

1. Der Remediation-Workflow, der in Ihren Transaktionseinstellungen konfiguriert ist.
2. Ihr Workflow für Biometrische Authentifizierung, sofern das Subjekt bereits ein gespeichertes Referenzgesicht aus einer genehmigten Verifizierung hat.
3. Der Standard-Workflow Ihrer Anwendung.

Das bedeutet: Vorkonfigurierte Regeln mit AWAITING_USER erzeugen von Anfang an immer eine nutzbare Sitzung. Für Benutzer, die Sie bereits verifiziert haben, ist es ein biometrischer Step-up. Für alle anderen ist es eine vollständige Verifizierung. Travel-Rule-Transaktionen sind von dieser automatischen Ausweichlösung ausgeschlossen. Ihr Warten auf AWAITING_USER dient dem Nachweis der Wallet-Inhaberschaft, und dafür gibt es einen eigenen Ablauf. Für Transaktionen mit hohem Risiko ist ein Workflow für Biometrische Authentifizierung die stärkste Wahl. Da das Subjekt der Benutzer ist, den Sie bereits per KYC geprüft haben, verwendet Didit das verifizierte Referenzgesicht aus dessen Onboarding wieder. Dies ist das genehmigte Liveness-Selfie, das Foto aus dem Passchip oder das Porträt aus dem Dokument. Der Benutzer macht lediglich ein Live-Selfie, und Didit führt eine Liveness-Prüfung sowie einen 1:1-Gesichtsabgleich mit der Identität durch, die das Konto eröffnet hat. Gestohlene Zugangsdaten, gephishte OTPs und SIM-Swaps scheitern an dieser Hürde. Vollständige Anleitung: Step-up-Biometrie bei einer Auszahlung mit hohem Wert. Sobald für die Sitzung eine Entscheidung vorliegt, richtet sich die Transaktion automatisch danach, und ein Webhook transaction.status.updated wird ausgelöst. Eine genehmigte Sitzung genehmigt die Transaktion (decision_reason_code: user_action_approved). Eine abgelehnte Sitzung lehnt die Transaktion ab (user_action_declined). Endet eine Sitzung in der Prüfung, wechselt die Transaktion zu IN_REVIEW (user_action_in_review). Eine abgelaufene oder abgebrochene Sitzung lässt die Transaktion im Status AWAITING_USER.

​

Scoring

Wenn eine Transaktion mit einer oder mehreren Regeln übereinstimmt, werden die Scores kombiniert:

1. Jede Regelübereinstimmung trägt über die Aktion add_score zum gesamten Risiko-Score der Transaktion bei.
2. Der finale Score bestimmt anhand der Score-Schwellenwerte Ihrer Anwendung den Transaktionsstatus.
3. Enthält eine Regel die Aktion change_status, wird dieser Status direkt angewendet. DECLINED hat immer Vorrang.

Standardmäßige Score-Schwellenwerte (in der Konsole konfigurierbar):

​

Eigene Regeln erstellen

Eigene Regeln können in der Business-Konsole oder über die Management API erstellt werden (auch erreichbar über das Didit MCP und jeden KI-Assistenten mit MCP-Anbindung). Regeln im Modus Active wirken sofort auf alle neuen Transaktionen. Titel sind pro Anwendung eindeutig.

​

Backtesting

Bevor Sie eine Regel aktivieren, können Sie sie anhand historischer Daten validieren:

• Setzen Sie eine Regel auf den Modus Test. Die Regel wird dann bei jeder neuen Transaktion ausgewertet, die Ergebnisse wirken sich aber nicht auf Status oder Score der Transaktion aus. Ausführungsstatistiken (Anzahl der Treffer, betroffene Entitäten) werden gesammelt, sodass Sie die Auswirkungen vor dem Livebetrieb beurteilen können.
• Nutzen Sie die Backtest-Funktion – in der Konsole oder über POST /v3/transactions/rules/backtest/ – um die Bedingungen und die Aggregation einer Regel nachträglich gegen Transaktionen aus einem festgelegten Zeitraum auszuwerten. Der Backtest gibt die Anzahl der ausgewerteten und der übereinstimmenden Transaktionen sowie die betroffenen Entitäten zurück, ohne historische Daten zu verändern. Senden Sie dieselben conditions, aggregation, evaluation_mode und scope wie bei der Regel, die Sie aktivieren möchten. Ein weggelassener Geltungsbereich bedeutet keine Einschränkung. Der Backtest würde dann Transaktionen zählen, die die gespeicherte Regel überspringt.

​

Velocity-Fenster (Aggregation)

Velocity-Regeln aggregieren historische Transaktionsdaten über einen Zeitraum, um Muster zu erkennen, die Einzeltransaktionsprüfungen übersehen würden: Jede Aggregation legt Folgendes fest:

• Ein Zeitfenster: <N>m (Minuten), <N>h (Stunden) oder <N>d (Tage), z. B. 30m, 6h, 7d, 30d. Achtung: m steht für Minuten, nicht für Monate.
• Filter, um einzugrenzen, welche historischen Transaktionen einbezogen werden. Schlüssel sind Feldpfade aus dem Feldkatalog. Der Sonderwert "__current__" wird auf den Wert desselben Feldes der ausgewerteten Transaktion aufgelöst (z. B. begrenzt "subject_vendor_data": "__current__" das Fenster auf dasselbe Subjekt). Ein Listenwert bedeutet Zugehörigkeit. Filter vergleichen nur auf Gleichheit oder Zugehörigkeit. Es gibt keinen lt/gte-Filter, daher lässt sich ein Bereich wie Transaktionen unter 10.000 nicht mit einem Filter ausdrücken. Setzen Sie den Bereich stattdessen auf die Metrik (max unter 10.000, min über 1.000). Denken Sie daran, dass eine Bedingung immer die ausgewertete Transaktion einschränkt, niemals das Fenster.
• Einen Operator und Schwellenwert (eq, ne, gt, gte, lt, lte gegen value, z. B. count >= 20)

​

Beispielmuster

​

Feldkatalog

Bedingungen und Aggregationsfilter referenzieren Transaktionsfelder über ihren Pfad:

​

Bedingungsoperatoren

Regeln unterstützen die folgenden Vergleichsoperatoren für Bedingungen: Alle übrigen Operatoren benötigen einen nicht leeren value; ohne diesen antwortet die API mit 400. contains, not_contains und regex akzeptieren einen einzelnen String, keine Liste und kein Objekt; contains_any akzeptiert eine Liste von Strings.

​

Werttypen der Bedingung

Ein optionaler value_type an einer Bedingung legt fest, wie value interpretiert wird:

​

Gruppierte Bedingungen

Eine flache Bedingungsliste wird gemäß dem evaluation_mode der Regel (ALL/ANY) kombiniert. Für gemischte Logik vergeben Sie einen group_index an Bedingungen: Bedingungen mit demselben Index bilden eine Gruppe. group_logic (AND/OR, Standard AND) verknüpft die Bedingungen innerhalb einer Gruppe, und groups_logic in der ersten Bedingung (AND/OR, Standard OR) verknüpft die Gruppenergebnisse. Sobald eine Bedingung einen group_index trägt, ersetzt die gruppierte Auswertung den evaluation_mode.

​

Auf benutzerdefinierte Eigenschaften verweisen

Jeder Schlüssel, der im Objekt custom_properties von POST /v3/transactions/ übermittelt wird, wird als custom_values in der Transaktion gespeichert und kann in Bedingungen über den Feldpfad custom_values.<key> verwendet werden. Wurde zum Beispiel eine Transaktion mit "custom_properties": {"channel": "mobile_app"} übermittelt, erfüllt sie die Bedingung custom_values.channel eq "mobile_app". Alle oben genannten Operatoren funktionieren mit benutzerdefinierten Eigenschaften; sie können außerdem mit anderen Feldern verglichen oder in Velocity-Filtern verwendet werden. Im Regel-Builder der Console erscheinen Schlüssel, die bei kürzlich erfassten Transaktionen beobachtet wurden, automatisch im Auswahlfeld für Bedingungsfelder unter Benutzerdefinierte Eigenschaften. Sie können einen Schlüssel auch verwenden, bevor eine Transaktion ihn enthält: Wählen Sie in derselben Gruppe Benutzerdefinierte Eigenschaft eingeben und geben Sie den Schlüssel genau so ein, wie Ihre Integration ihn sendet (Schlüssel unterscheiden Groß- und Kleinschreibung). Die Regel wird so lange als nicht zutreffend ausgewertet, bis Transaktionen mit diesem Schlüssel eintreffen.

​

Automatische Ablehnung über Sperrliste

Bevor Regeln ausgewertet werden, prüft Didit die Entitäten der Transaktion gegen die Sperrlisten Ihrer Anwendung. Wird auch nur eine Übereinstimmung gefunden, wird die Transaktion sofort abgelehnt, und die Regeln werden nicht ausgewertet. Die folgenden Entitäten werden geprüft: Bei einer Übereinstimmung mit der Sperrliste geschieht Folgendes:

• Der Transaktionsstatus wird auf DECLINED gesetzt.
• Der Entscheidungsgrund wird auf blocklisted gesetzt.
• Es wird ein Aktivitätseintrag zur Nachvollziehbarkeit angelegt.

​

Transaktionsscreening

Didit ist mit externen AML- und Blockchain-Analyseanbietern integriert, die Transaktionen mit Risikoinformationen anreichern. Wird eine Transaktion übermittelt, kann das System:

• Gegenparteien gegen Datenbanken globaler Sanktions- und Beobachtungslisten prüfen
• Wallet-Adressen (bei Krypto-Transaktionen) anhand von Blockchain-Intelligence-Daten bewerten, einschließlich der Exposure gegenüber Mixern, Verbindungen zu sanktionierten Entitäten und Interaktionen mit Diensten mit hohem Risiko
• den AML-Status des Antragstellers prüfen, indem die mit der Transaktion verknüpfte Benutzerin bzw. der verknüpfte Benutzer mit den neuesten AML-Screening-Ergebnissen abgeglichen wird

Die Screening-Ergebnisse werden der Transaktion zugeordnet und fließen in das Scoring der Regel-Engine ein. Wenn eine Gegenpartei oder Wallet auf einer Sanktionsliste steht, markiert oder lehnt die entsprechende Regel die Transaktion automatisch ab.

​

Nächste Schritte