> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # KYT-Regeln & Scoring: Velocity & Bedingungen > In Didit KYT-Regeln mit Bedingungen, Velocity-Fenstern und Aktionen konfigurieren. 1,000 pro Monat inklusive, danach $0.001 je Anfrage. 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. [Regel erstellen – Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1) > [!NOTE] > > Regeln können über die **Business-Konsole**, die **Management-API** und die **Didit MCP** verwaltet werden. Verwenden Sie die Konsole, wenn eine Person in Ihrem Compliance-Team jede Änderung prüfen soll. Verwenden Sie die API oder das MCP, wenn Regeln programmatisch erstellt und abgestimmt werden, etwa beim Übernehmen eines Regelsatzes von einem anderen Anbieter. Siehe die [API-Referenz](https://docs.didit.me/de/management-api/transactions/rules-list.md) und den [Leitfaden zur Verwaltung von Regeln über API und MCP](https://docs.didit.me/de/transaction-monitoring/rules-api.md). Regeln werden bei jeder Transaktion ausgewertet, die über [`POST /v3/transactions/`](https://docs.didit.me/de/management-api/transactions/create) übermittelt wird. Das Ergebnis erscheint im Array `rule_runs[]` der Transaktion (siehe [Antwortschema](https://docs.didit.me/de/transaction-monitoring/response-schema.md)). ## 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](https://docs.didit.me/de/management-api/transactions/rules-install.md) 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](https://docs.didit.me/de/transaction-monitoring/rules-library.md). | Paket | Beispiele | | - | - | | **Finanzen** | Erkennung von Strukturierung (eingehend/ausgehend), große Einzeltransaktionen oberhalb der Meldeschwellen | | **AML/CTF** | Kumulative Volumenlimits, schnelle Ein- und Ausgänge, Abgleich von Gegenparteien mit Sanktionslisten, verdächtige Schlüsselwörter in der Zahlungsreferenz | | **Anomalieerkennung** | Hohe Velocity bei eingehenden/ausgehenden Transaktionen, Reaktivierung inaktiver Konten nach 12+ Monaten Inaktivität | | **FATF** | Bezug zu Hochrisikoländern bei Gegenparteien und Adressen der Subjekte | | **Geräteintelligenz** | Wiederholte Nutzung von Bonuskampagnen über denselben Geräte-Fingerprint, mehrere Geräte-Fingerprints für dasselbe Subjekt | | **Betrugsprävention** | Mehrfachkonten über gemeinsam genutzte Geräte-Fingerprints bei verschiedenen Subjekten | | **Krypto-Überwachung** | Kontakt mit Mixer- oder Verschleierungsdiensten, Hochrisiko-Adressen (Darknet, sanktioniert, gestohlene Mittel) | | **Krypto-Screening** | Exposition gegenüber einer risikoreichen Mittelherkunft (>30%), mehrere riskante Gegenparteien, automatische Ablehnung bei Terrorismusfinanzierung und Kindesausbeutung, Zurückhalten, solange das Screening aussteht, Markierung bei mittlerem Wallet-Risiko-Score | | **Verantwortungsvolles Spielen** | Schnelle Einzahlungsserien innerhalb kurzer Zeitfenster | | **E-Commerce** | E-Commerce-spezifische Transaktionsmuster | ## Regelquellen Jede Regel hat eine `source`, die angibt, wer sie verwaltet: | Quelle | Beschreibung | | - | - | | **Voreinstellung** | Regeln aus der integrierten Bibliothek von Didit. Sie wählen aus, welche Voreinstellungen oder ganze Pakete Sie installieren, und Sie steuern den Modus jeder installierten Voreinstellung (`Active`, `Test`, `Disabled`). Ihre Bedingungen und Schwellenwerte sind fest vorgegeben. Um eine Voreinstellung zu überschreiben, erstellen Sie eine benutzerdefinierte Regel. Voreinstellungen werden durch Deinstallieren entfernt, nicht durch Löschen. | | **Benutzerdefiniert** | Regeln, die Ihr Team in der Business-Konsole erstellt. Sie haben volle Kontrolle über benutzerdefinierte Regeln: Sie können sie nach Bedarf erstellen, bearbeiten und löschen. | ## Aufbau einer Regel Jede Regel besteht aus folgenden Bestandteilen: | Bestandteil | Beschreibung | | - | - | | **Titel und Beschreibung** | Verständlicher Name und Erläuterung, was die Regel erkennt | | **Kategorie** | Logische Gruppierung (z. B. `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) | | **Modus** | `Active` (Auswertung in Echtzeit), `Disabled` (wird übersprungen) oder `Test` (wird ausgewertet, die Ergebnisse wirken sich jedoch nicht auf die Transaktion aus) | | **Auswertungsmodus** | `All` (jede Bedingung muss zutreffen) oder `Any` (mindestens eine Bedingung muss zutreffen) | | **Geltungsbereich** | Begrenzt, auf welche Transaktionen die Regel angewendet wird. Schlüssel: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`. Leer oder fehlend bedeutet keine Einschränkung. | | **Bedingungen** | Feldbezogene Prüfungen: Transaktionsfelder werden mit Operatoren wie `eq`, `lt`, `gte`, `in`, `contains_any` und `exists` mit Werten verglichen | | **Aggregation** | Velocity-Zeitfenster: historische Transaktionen werden über einen Zeitraum aggregiert (z. B. Anzahl, Summe oder Anzahl unterschiedlicher Werte über 1 Stunde, 7 Tage, 30 Tage) | | **Aktionen** | Was passiert, wenn die Regel zutrifft (siehe unten) | ## 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: | Aktion | `type` | Schlüssel | Beschreibung | | - | - | - | - | | **Score hinzufügen** | `add_score` | `value` (Ganzzahl, auch negativ möglich) | Fügt dem Risiko-Score der Transaktion Punkte hinzu. Der kumulierte Score aller übereinstimmenden Regeln bestimmt, ob die Transaktion den Prüfschwellenwert oder den Ablehnungsschwellenwert überschreitet. | | **Status ändern** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, Alias `status`), `workflow_id` (Alias `remediation_workflow_id`) | Setzt den Status der Transaktion direkt, unabhängig vom Score. `workflow_id` ist erforderlich, wenn `value` den Wert `AWAITING_USER` hat. Fehlt es, wird `400` zurückgegeben. | | **Tags hinzufügen** | `add_tags` | `tag_uuid` oder `tag_name` (eines von beiden), `tag_color` | Versieht die Transaktion mit einem Tag zur Kategorisierung und Filterung. Verwendet wird die `tag_uuid` eines bestehenden Tags oder ein `tag_name`, der beim ersten Gebrauch angelegt wird (in Großbuchstaben gespeichert). `tag_color` legt die Hex-Farbe eines neu angelegten Tags fest. | | **Notiz hinzufügen** | `add_note` | `note` (Alias `value`) | Hängt eine automatisch erzeugte Textnotiz an die Transaktion an, als Kontext für Analysten. | | **Zur Liste hinzufügen** | `add_to_list` | `list_id` | Fügt die `vendor_data` des Subjekts einer Sperrliste, Freigabeliste oder benutzerdefinierten Liste hinzu. | | **Fall eröffnen** | `open_case` | `blueprint` (UUID einer Fallvorlage, optional), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (boolean) | Eröffnet einen Untersuchungsfall oder fügt die Transaktion einem bestehenden Fall hinzu. Pro Regel wird nur die erste `open_case`-Aktion angewendet. | 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](https://docs.didit.me/de/transaction-monitoring/sdk-transaction-submission.md#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](https://docs.didit.me/de/transaction-monitoring/settings.md#remediation-workflow) 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](https://docs.didit.me/de/transaction-monitoring/wallet-ownership-widget.md). 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](https://docs.didit.me/de/transaction-monitoring/sdk-transaction-submission.md#beispiel-biometrische-nachprüfung-bei-einer-auszahlung-hoher-beträge). 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`. > [!NOTE] > > Jeder Workflow-Typ außer KYB kann als Remediation-Aktion verwendet werden. > Workflows für Biometrische Authentifizierung (und Workflows, in denen der Gesichtsabgleich vor der Ausweisverifizierung läuft) erfordern zusätzlich ein gespeichertes Referenzgesicht für das Subjekt. Dies kann ein genehmigtes Liveness-Selfie, ein Foto aus dem Passchip, ein Porträt aus dem Dokument oder ein manuell hinterlegtes Profilgesicht sein. > Existiert kein solches Gesicht, wird der Benutzer stattdessen aufgefordert, den Standard-Workflow Ihrer Anwendung abzuschließen. Dabei wird sein Gesicht auch für das nächste Mal hinterlegt. Eine Notiz an der Transaktion hält diesen Ersatz fest. > Die Sitzung wird nur übersprungen, wenn auch kein geeigneter Standard-Workflow existiert. Dann erklärt die Notiz den Grund. ## 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): | Einstellung | Standard | Beschreibung | | - | - | - | | **Prüfschwellenwert** | 75 | Scores, die diesen Wert erreichen oder überschreiten, lösen `IN_REVIEW` aus | | **Ablehnungsschwellenwert** | 500 | Scores, die diesen Wert erreichen oder überschreiten, lösen `DECLINED` aus. Der Standardwert (`500`) führt nie zu einer Ablehnung aufgrund des Scores | ## Eigene Regeln erstellen Eigene Regeln können in der **Business-Konsole** oder über die **Management API** erstellt werden (auch erreichbar über das [Didit MCP](https://docs.didit.me/de/integration/mcp/tools.md) und jeden KI-Assistenten mit MCP-Anbindung). > [tab] Konsole > > 1. Öffnen Sie in der Konsole **Transaktionen** > **Regeln** > 2. Klicken Sie auf **Regel erstellen** > 3. Definieren Sie den Regeltitel, die Beschreibung und die Kategorie > 4. Legen Sie den **Modus** fest – `Active`, um live auszuführen, oder `Test`, um ohne Auswirkungen auf Transaktionen auszuwerten > 5. Wählen Sie den **Auswertungsmodus** – `All` (jede Bedingung muss zutreffen) oder `Any` (mindestens eine) > 6. Legen Sie den **Geltungsbereich** fest – auf welche Transaktionsarten oder Richtungen die Regel angewendet wird > 7. Fügen Sie **Bedingungen** hinzu – Feldvergleiche wie Betragsschwellen, Ländercodes oder Prüfungen benutzerdefinierter Eigenschaften > 8. Fügen Sie optional eine **Aggregation** hinzu – Velocity-Prüfungen über ein Zeitfenster (Anzahl, Summe, Anzahl unterschiedlicher Werte und mehr) > 9. Definieren Sie eine oder mehrere **Aktionen** – Score hinzufügen, Status ändern, Tags hinzufügen, Notizen hinzufügen, zu einer Liste hinzufügen oder einen Fall öffnen > 10. Speichern und aktivieren Sie die Regel > [tab] API > > Rufen Sie [`POST /v3/transactions/rules/`](https://docs.didit.me/de/management-api/transactions/rules-create) mit denselben Feldern auf: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. Die vollständige Referenz zu Feldern, Operatoren und Aktionen finden Sie auf dieser Seite. [Regeln über API und MCP verwalten](https://docs.didit.me/de/transaction-monitoring/rules-api.md) beschreibt den empfohlenen Ablauf von Erstellen über Backtest bis Aktivieren, einschließlich der Migration eines Regelsatzes aus einem CSV-Export eines anderen Anbieters. 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/`](https://docs.didit.me/de/management-api/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: | Metrik | Beschreibung | | - | - | | `count` | Anzahl der Transaktionen, die die Filter im Fenster erfüllen | | `sum` | Summe eines numerischen `field` (z. B. `preferred_currency_amount`) im Fenster | | `max` / `min` / `avg` | Größter, kleinster oder durchschnittlicher Wert eines numerischen `field` im Fenster | | `distinct_count` | Anzahl eindeutiger Werte eines `field` (z. B. unterschiedlicher Geräte-Fingerprints) im Fenster (`unique_count` ist ein akzeptierter Alias) | Jede Aggregation legt Folgendes fest: * Ein **Zeitfenster**: `m` (Minuten), `h` (Stunden) oder `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](#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 | Muster | Funktionsweise | | - | - | | **Strukturierung** | Anzahl der Transaktionen desselben Subjekts über 30 Tage >= 20, wobei der `max`-Betrag im selben Fenster unter \$10,000 liegt | | **Hohe Geschwindigkeit** | Anzahl eingehender Transaktionen desselben Subjekts über 7 Tage >= 20 | | **Schnelles Ein- und Ausgehen** | Aktuelle Transaktion ist ausgehend und Anzahl eingehender Transaktionen desselben Subjekts über 6 Stunden >= 1 | | **Mehrfachkonten** | Anzahl unterschiedlicher Subjekte mit demselben Geräte-Fingerprint über 7 Tage >= 3 | | **Reaktivierung nach Inaktivität** | Tage seit der letzten Transaktion des Subjekts >= 365, kombiniert mit einem Betrag von mindestens \$1,000 | ## Feldkatalog Bedingungen und Aggregationsfilter referenzieren Transaktionsfelder über ihren Pfad: | Feld | Beschreibung | | - | - | | `amount`, `currency` | Betrag und Währungscode der Transaktion | | `preferred_currency_amount`, `default_currency_code` | Betrag, umgerechnet in die bevorzugte Währung Ihrer Anwendung (fällt auf `amount_in_default_currency` zurück) | | `direction` | `INBOUND` oder `OUTBOUND` | | `action_type` | Ihr Aktionstyp, z. B. `withdrawal`, `deposit`, `bet` | | `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` | | `payment_details` | Freitext-Zahlungsreferenz (das Ziel von `contains_any` für Schlüsselwortregeln) | | `score`, `severity` | Aktueller Risiko-Score und Schweregrad der Transaktion | | `subject_vendor_data`, `counterparty_vendor_data` | Ihre Kennungen für die beiden Parteien | | `subject_country`, `counterparty_country` | Ländercodes der Parteien (ISO-2 und ISO-3 werden beide akzeptiert und vor dem Vergleich normalisiert) | | `subject_device_fingerprint`, `counterparty_device_fingerprint` | Geräte-Fingerprint oder persistente Geräte-ID | | `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Details zum Gerätekontext (`counterparty_browser_family` ist ebenfalls verfügbar) | | `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Netzwerkkontext | | `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | Die Zahlungsmethode auf Subjektseite (dieselben vier Felder existieren für `counterparty_payment_method_*`) | | `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Status der Travel-Rule-Prüfung | | `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Was Sie über den Gegenpartei-VASP wissen, mit dem der Travel-Rule-Austausch stattfand: Ihre Entscheidung dazu (`APPROVED`, `RESTRICTED`, `BLOCKED`), seine Risikostufe (`LOW`, `MEDIUM`, `HIGH`; `HIGH`, solange Ihr eigenes Gegenparteien-Screening als auffällig markiert ist), sein Land und seine Reaktionsbereitschaft (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). Siehe [Travel-Rule-Sorgfaltspflicht gegenüber Gegenparteien](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#regelfelder-und-vorlagen) | | `subject_days_since_previous_transaction` | Tage seit der vorherigen Transaktion desselben Subjekts vom selben Typ (Inaktivitätsregeln) | | `tags` | Die Tag-Namen der Transaktion | | `custom_values.` | Jeder Schlüssel, den Sie beim Erstellen der Transaktion in `custom_properties` übermittelt haben | ## Bedingungsoperatoren Regeln unterstützen die folgenden Vergleichsoperatoren für Bedingungen: | Operator | Beschreibung | Beispiel | | - | - | - | | `eq` / `ne` | Gleich / ungleich | `direction eq "OUTBOUND"` | | `gt` / `gte` / `lt` / `lte` | Numerische und Datumsvergleiche; treffen nie zu, wenn eine Seite fehlt | `preferred_currency_amount gte 25000` | | `in` / `not_in` | Enthaltensein in einer Liste (ein einzelner skalarer Wert wird ebenfalls akzeptiert) | `counterparty_country in ["IRN", "PRK", "SYR"]` | | `contains` / `not_contains` | Teilzeichenfolge ohne Berücksichtigung der Groß-/Kleinschreibung in einem String-Wert | `payment_details contains "refund"` | | `contains_any` | Mindestens eine Zeichenfolge aus einer Liste ist eine Teilzeichenfolge des Feldes, ohne Berücksichtigung der Groß-/Kleinschreibung | `payment_details contains_any ["terror", "weapon"]` | | `regex` | Das Wertmuster stimmt mit dem Feldwert überein | `subject_vendor_data regex "^guest-"` | | `fuzzy_match` | Unscharfe Zeichenkettenähnlichkeit; erfordert einen `score`-Schwellenwert (0-100) in der Bedingung | `counterparty_name fuzzy_match "Acme Corp"` mit `score: 85` | | `exists` / `is_not_empty` / `is_not_null` | Feld ist vorhanden (Aliase; `value` wird ignoriert) | `subject_device_fingerprint exists` | | `not_exists` / `is_empty` / `is_null` | Feld fehlt oder ist leer (Aliase; `value` wird ignoriert) | `subject_ip_address is_empty` | 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: | `value_type` | Bedeutung | | - | - | | `list` | `value` ist eine Listen-UUID: Die Einträge der Sperrliste, Zulassungsliste oder benutzerdefinierten Liste werden als Vergleichswert verwendet, sodass eine Regel etwa „Gegenpartei in meiner benutzerdefinierten Beobachtungsliste“ treffen kann. | | `field` | `value` ist ein weiterer Feldpfad: Die Bedingung vergleicht zwei Transaktionsfelder, z. B. `subject_payment_method_account_id ne counterparty_payment_method_account_id`. | | `relative_date` | `value` ist ein relatives Datum, z. B. `{"direction": "past", "unit": "days", "amount": 30}`; für Datumsfelder wie `txn_date`. | ### 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/`](https://docs.didit.me/de/transaction-monitoring/transactions) übermittelt wird, wird als `custom_values` in der Transaktion gespeichert und kann in Bedingungen über den Feldpfad `custom_values.` 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: | Entität | Art der Sperrliste | Was geprüft wird | | - | - | - | | **Benutzer (Antragsteller)** | Benutzer-Sperrliste | Die `vendor_data`-Kennung des Antragstellers | | **Unternehmen** | Unternehmens-Sperrliste | Die `vendor_data`-Kennung des Unternehmens | | **Wallet-Adresse** | Wallet-Adressen-Sperrliste | Die `account_id` von Krypto-Wallet-Zahlungsmethoden | | **Bankkonto** | Bankkonto-Sperrliste | Die `account_id` von Banküberweisungs-Zahlungsmethoden | | **IP-Adresse** | IP-Adressen-Sperrliste | Die Adresse aus dem Gerätekontext der Partei (unterstützt CIDR-Bereiche) | | **Geräte-Fingerabdruck** | Geräte-Fingerabdruck-Sperrliste | Der Geräte-Fingerabdruck oder die persistente Geräte-ID | 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. > [!NOTE] > > Die Sperrlistenprüfung läuft vor der Regelauswertung. Eine gesperrte Entität wird unabhängig von der Regelkonfiguration oder den Score-Schwellenwerten immer abgelehnt. ## 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 > [card] [Transaktionen übermitteln](https://docs.didit.me/de/transaction-monitoring/transactions.md) > > So sind Transaktionen für die Regelauswertung strukturiert. > [card] [Krypto-Screening](https://docs.didit.me/de/transaction-monitoring/aml-screening.md) > > Ergebnisse des Krypto-Screenings und wie voreingestellte Regeln sie nutzen. > [card] [Einstellungen](https://docs.didit.me/de/transaction-monitoring/settings.md) > > Konfigurieren Sie Score-Schwellenwerte und Workflows für Abhilfemaßnahmen. > [card] [API-Referenz](https://docs.didit.me/de/management-api/transactions/create.md) > > Endpoint zum Erstellen von Transaktionen über die API. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.