> ## 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-Regelbibliothek: 150+ Vorlagen für Transaktionsüberwachung

> Didit: 150+ KYT-Regelvorlagen für Structuring, Velocity, Sanktionen, Krypto und Travel Rule. 1,000 im Monat inklusive, danach $0.001 je Aufruf.

**Über 150 vorkonfigurierte Regeln zur Transaktionsüberwachung**, die Didit als kuratierte Bibliothek bereitstellt, können Sie einzeln oder als Bundle installieren. Jede Regel bildet eine reale AML-, Betrugs- oder Compliance-Typologie ab, die auf globalen Standards und aufsichtsrechtlichen Leitlinien beruht: FATF-Empfehlungen, FinCEN-Hinweise, NACHA-Regeln, Wolfsberg-Grundsätze, Typologien der Egmont Group und Missbrauchsmuster im iGaming.

Wählen Sie die gewünschten Presets oder Bundles aus und steuern Sie danach den Modus jeder installierten Regel (`ACTIVE`, `TEST` oder `DISABLED`). Die Bedingungen, Schwellenwerte und Aktionen von Presets sind fest vorgegeben. Wenn Sie eine andere Logik benötigen, erstellen Sie eine benutzerdefinierte Regel. Um ein Preset aus der Anwendung zu entfernen, deinstallieren Sie es. Bei Bedarf können Sie es später erneut installieren.

> [!NOTE]
>
> Regeln aus der Bibliothek können Sie im *Transactions -> Rules -> Library* der Business Console durchsuchen, installieren und deinstallieren, über die [Regel-Bibliothek-API](https://docs.didit.me/de/management-api/transactions/rules-library.md) (`GET /v3/transactions/rules/library/`, `POST`/`DELETE /v3/transactions/rules/install/`) oder über die `didit_transaction_rule_library_list`, `didit_transaction_rule_install` und `didit_transaction_rule_uninstall` [MCP-Tools](https://docs.didit.me/de/integration/mcp/tools.md). Installierte Presets akzeptieren nur Änderungen des `mode` (aktivieren, deaktivieren, testen). Ihre Schwellenwerte sind fest. Um einen Schwellenwert anzupassen, erstellen Sie eine [benutzerdefinierte Regel](https://docs.didit.me/de/transaction-monitoring/rules.md#eigene-regeln-erstellen). Wie Regeln zum Scoring beitragen, erfahren Sie unter [Risiko-Scoring](https://docs.didit.me/de/transaction-monitoring/risk-scoring.md).

> [!NOTE]
>
> Eine Bibliotheksregel, deren Bedingungen Daten abfragen, die die Regel-Engine noch nicht auswerten kann, wird zurückgehalten, bis sie ausgeführt werden kann. Die Bibliothek listet sie dann nicht auf. Eine Anfrage, die sie in `library_keys` nennt, führt zu einer `400`-Antwort und installiert nichts (ein unbekannter Schlüssel wird dagegen übersprungen). Eine `bundle`-Installation überspringt sie. Eine zuvor installierte Kopie wird auf `DISABLED` gesetzt und bleibt in Ihrer Regelliste. Das Setzen ihres `mode` auf einen anderen Wert führt zu einer Antwort mit `400`. Eine zurückgehaltene Regel steht automatisch wieder zur Verfügung, sobald die Regel-Engine ihre Bedingungen auswerten kann. Die Bibliotheksliste zeigt daher immer die Regeln, die Sie heute installieren können.

## Wie Presets aufgebaut sind

Jedes Preset gehört zu einem **Bundle** (seiner funktionalen Familie) und zu einer **Kategorie** (seinem übergeordneten Risikothema). Bundles ermöglichen es Ihnen, zusammengehörige Regeln in der Console gemeinsam ein- und auszuschalten. Kategorien steuern Scoring und Reporting.

| Bundle | Was es abdeckt |
| - | - |
| `finance` | Strukturierung, große Transaktionen, kumulatives Volumen, Länderverteilung, Layering, Mule-Fan-in, Smurfing |
| `aml_ctf` | Sanktionen, verdächtige Zahlungsreferenzen, Layering mit runden Beträgen, schnelles Ein- und Ausgehen von Geldern |
| `aml_monitoring` | Aus der Blockchain abgeleitete Exposition gegenüber einer risikoreichen Mittelherkunft, Terrorismusfinanzierung, Ausbeutung von Kindern |
| `anomaly_detection` | Hohe Transaktionsfrequenz, Reaktivierung ruhender Konten, Aktivität außerhalb der Geschäftszeiten |
| `fatf` | Exposition gegenüber Hochrisikojurisdiktionen |
| `device_intelligence` | Wiederverwendung von Geräte-Fingerprints, Konten mit mehreren Fingerprints, IP- und Browser-Anomalien, VPN/Proxy, unmögliche Reisebewegungen |
| `fraud_prevention_multi_accounting` | Geteilte Fingerprints über unterschiedliche Subjekte hinweg |
| `fraud_prevention_app` | Signale zu autorisierten Push-Zahlungen, erstmaligen Zahlungsempfängern und Betrugsopfern |
| `fraud_prevention_ato` | Zusammengesetzte Signale für Kontoübernahme (Änderung personenbezogener Daten, neue Zahlungsmethode) |
| `fraud_prevention_consortium` | Gegenparteien, die andere Institute im gemeinsamen Netzwerk markiert haben |
| `crypto_monitoring` | Exposition gegenüber Mixer-, Darknet- und sanktionierten Wallets, Chain-Hopping, selbstverwahrte Wallets, VASP-Lücken |
| `travel_rule` | Globale und regionale Travel-Rule-Pflichten (12 Regelwerke) und Due Diligence bei VASP-Gegenparteien |
| `travel_rule_eu_tfr` | EU-TFR-Prüfungen: Abweichungen bei den Daten der Gegenpartei, nicht verifizierte Wallet-Inhaberschaft, nicht identifizierter VASP der Gegenpartei, abgelaufene Bestätigung |
| `responsible_gaming` | Ein- und Auszahlungslimits für sicheres Spielen, Selbstsperre, Spielen außerhalb der üblichen Zeiten |
| `igaming_fraud` | Ereignisbasierter Bonusmissbrauch, Gegenwetten, Affiliate-Betrug, Chat-Rain-Farming, Chip-Dumping, Kontoübernahme |
| `e_commerce` | Kartentests mit Kleinstbeträgen, Chargeback-Indikatoren, Abweichung des Rechnungslands, Affiliate-Schübe |
| `check_fraud` | Beträge außerhalb des zulässigen Bereichs, fehlende Nummern, mehrfach vorgelegte Schecks, Treffer auf Dark-Web-Beobachtungslisten, gewaschene Schecks, Kiting |
| `bnpl` | First-Party-Betrug bei fehlgeschlagenen Rückzahlungen, gemeinsam genutzte Identifikatoren über BNPL-Konten hinweg, Ratenzahlungen auf neuen Konten |

## So lesen Sie diese Seite

Jede Regel führt ihren `library_key` auf. Das ist eine stabile Kennung, auf die Sie in der API oder in der Console-URL verweisen können. Außerdem nennt jede Regel die Bedingungen und die Aggregation, die sie auslösen, sowie die Standardaktionen, die sie ausführt. Die hier angegebenen numerischen Schwellenwerte sind die Standardwerte bei Auslieferung. Jeder Wert ist pro Anwendung bearbeitbar, ohne dass die Regel ihre Identität verliert.

***

## Finanzpaket

Diese Regeln gelten für jede Transaktion mit `transaction_type = FINANCE`. Sie bilden die regulatorische Grundlage ab (BSA/FinCEN-Meldeschwellen, FATF-Heuristiken zur Transaktionsgeschwindigkeit) sowie Muster für Money Mules und Smurfing.

### Structuring und Nähe zum Schwellenwert

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `structuring-inbound` | ≥20 eingehende Überweisungen unter \$10,000 durch dasselbe Subjekt innerhalb von 30 Tagen | +35 Score |
| `structuring-outbound` | ≥20 ausgehende Überweisungen unter \$10,000 durch dasselbe Subjekt innerhalb von 30 Tagen | +35 Score |
| `single-transaction-just-below-threshold` | Eine einzelne Transaktion zwischen $9,000 und $9,999 | +25 Score |
| `round-amount-layering` | Der Überweisungsbetrag entspricht einem verdächtig runden Wert ($10k, $25k, $50k, $100k, $250k, $500k, \$1M…) | +20 Score |

### Volumen und Geschwindigkeit

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `large-single-transaction` | Einzelne Transaktion ≥ \$25,000 | +50 Score, `IN_REVIEW` |
| `cumulative-outbound-volume` | Ausgehendes Volumen ≥ \$100,000 in 30 Tagen | +45 Score, `IN_REVIEW` |
| `cumulative-inbound-volume-90d` | Eingehendes Volumen ≥ \$200,000 in 90 Tagen | +30 Score, `IN_REVIEW` |
| `cumulative-outbound-volume-7d` | Ausgehendes Volumen ≥ \$50,000 in 7 Tagen | +30 Score, `IN_REVIEW` |
| `business-4h-inbound-volume` | Eingehendes Volumen des Unternehmens ≥ \$30,000 in einem beliebigen 4-Stunden-Zeitfenster | +30 Score, `IN_REVIEW` |
| `business-4h-outbound-volume` | Ausgehendes Volumen des Unternehmens ≥ \$30,000 in einem beliebigen 4-Stunden-Zeitfenster | +30 Score, `IN_REVIEW` |
| `high-velocity-inbound` | ≥20 eingehende Transaktionen in 7 Tagen | +25 Score |
| `high-velocity-outbound` | ≥20 ausgehende Transaktionen in 7 Tagen | +25 Score |

### Layering, Money Mule und Smurfing

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `rapid-in-and-out-movement` | Eine ausgehende Transaktion, der innerhalb von 6 Stunden eine eingehende vorausging | +60 Score, `IN_REVIEW` |
| `cash-deposit-followed-by-withdrawal` | Bareinzahlungen ≥ \$50,000 innerhalb von 72 Stunden, gefolgt von einer Barabhebung | +30 Score, `IN_REVIEW` |
| `money-mule-fan-in-to-counterparty` | Eine Gegenpartei erhält Überweisungen von ≥5 verschiedenen Subjekten in 7 Tagen | +30 Score, `IN_REVIEW` |
| `rapid-repeated-payments-same-counterparty` | ≥5 ausgehende Überweisungen an dieselbe Gegenpartei in 24 Stunden | +30 Score, `IN_REVIEW` |
| `cross-border-small-amount-velocity` | Ein Subjekt sendet Beträge unter \$1,000 an ≥4 verschiedene Länder der Gegenparteien in 24 Stunden | +30 Score, `IN_REVIEW` |
| `high-risk-jurisdiction-smurfing` | ≥5 ausgehende Überweisungen unter \$1,000 an dasselbe Hochrisikoland in 7 Tagen | +30 Score, `IN_REVIEW` |
| `many-unique-counterparties-24h` | Das Subjekt wickelt Transaktionen mit ≥6 verschiedenen Gegenparteien in 24 Stunden ab | +30 Score, `IN_REVIEW` |
| `many-unique-payment-methods-7d` | Das Subjekt wechselt innerhalb von 7 Tagen zwischen ≥4 verschiedenen Zahlungsmethoden | +30 Score, `IN_REVIEW` |
| `counterparty-country-spread-24h` | Das Subjekt wickelt Transaktionen mit ≥4 verschiedenen Ländern von Gegenparteien in 24 Stunden ab | +30 Score, `IN_REVIEW` |

### Verhaltensanomalien

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `dormant-account-reactivation` | Erste Transaktion ≥ \$1,000 nach ≥365 Tagen Inaktivität | +20 Score |
| `off-hours-high-value-finance` | Hochwertige Überweisung (≥ \$5,000), die für die Region des Subjekts als außerhalb der üblichen Zeiten markiert ist | +25 Score |

***

## AML-/CTF-Paket

Diese Regeln bilden klassische AML-/CTF-Typologien ab, die nicht auf Blockchain-Anreicherung angewiesen sind. Sie gelten einheitlich für Fiat- und Krypto-Überweisungen.

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `sanctions-counterparty` | Die geprüfte Wallet selbst wird einer sanktionierten Stelle zugeordnet (`wallet_sanctioned`). Eine Exposition allein löst diese Regel nicht aus | +90 Score, `DECLINED` |
| `sanctions-exposure-review` | Über die geprüfte Wallet wurden Gelder an sanktionierte Stellen gesendet oder von dort empfangen, ohne dass die Wallet selbst sanktioniert ist | +50 Score, `IN_REVIEW` |
| `suspicious-payment-reference` | Der Verwendungszweck enthält Schlüsselwörter, die mit Erlösen aus Straftaten in Verbindung stehen | +45 Score, `IN_REVIEW` |
| `high-risk-jurisdiction-exposure` | Das Land der Gegenpartei oder das Land der IP-Adresse des Subjekts steht auf der Hochrisikoliste | +40 Score, `IN_REVIEW` |
| `high-risk-inbound-single` | Eingehend ≥ \$20,000 aus einem Hochrisikoland | +30 Score, `IN_REVIEW` |
| `high-risk-outbound-single` | Ausgehend ≥ \$20,000 in ein Hochrisikoland | +30 Score, `IN_REVIEW` |

Die standardmäßige Liste der Hochrisikojurisdiktionen umfasst FATF-Jurisdiktionen mit Aufforderung zum Handeln sowie Konfliktgebiete: `IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`. Sie können die Liste pro Anwendung überschreiben.

> [!NOTE]
>
> **Die Abdeckung von PEP-Gegenparteien wird derzeit nicht angeboten.** Kein angebundener Screening-Anbieter meldet, ob eine Gegenpartei eine politisch exponierte Person ist: Das Feld `pep_counterparty` ist bei jedem Screening-Ergebnis derzeit `null`. Deshalb gibt es in der Bibliothek keine Voreinstellung für PEP-Gegenparteien (siehe [Wallet-Screening](https://docs.didit.me/de/transaction-monitoring/wallet-screening.md#antwort)). Eine Regel, die vor der Zurückziehung dieser Voreinstellung installiert wurde, wird weiterhin ausgewertet, kann aber bei keinem echten Screening greifen. Entfernen Sie sie oder ersetzen Sie sie durch eine benutzerdefinierte Regel, wenn Sie auf ein anderes Signal reagieren müssen.

***

## Krypto-Screening-Paket

Diese Regeln verarbeiten die angereicherten Daten aus dem Krypto-Screening von Didit. Sie sind vor allem für krypto-native Anwendungen und VASPs nützlich.

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `aml-high-risk-source-exposure` | ≥30% der Mittel stammen aus den Kategorien sanktionierte Entitäten, Darknet, gestohlene Gelder, Ransomware oder Betrug | +70 Score, `IN_REVIEW` |
| `aml-multiple-risky-counterparties` | ≥3 Verbindungen zu Hochrisiko-Entitäten im Graphen der Mittelherkunft | +50 Score, `IN_REVIEW` |
| `aml-terrorist-financing-exposure` | Jede Exposition gegenüber Terrorismusfinanzierung auf der Wallet | +100 Score, `DECLINED` |
| `aml-child-exploitation-exposure` | Jede Exposition gegenüber Material zur Ausbeutung von Kindern auf der Wallet | +100 Score, `DECLINED` |
| `aml-wallet-risk-score-medium` | Risiko-Score der Wallet laut Anbieter zwischen 40 und 70 | +30 Score |

***

## Bundle Krypto-Überwachung

Regeln zur Wallet-Exposition auf Wallet-Ebene sowie Integritätsprüfungen im Umfeld von VASP und Travel Rule.

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `crypto-mixer-exposure` | Wallet mit Verbindung zu einem Mixer oder Verschleierungsdienst | +80 Score, `IN_REVIEW` |
| `crypto-darknet_market-exposure` | Wallet-Exposition gegenüber Darknet-Märkten | +80 Score, `IN_REVIEW` |
| `crypto-sanctioned-exposure` | Wallet-Exposition gegenüber sanktionierten Wallets | +90 Score, `IN_REVIEW` |
| `crypto-stolen_funds-exposure` | Wallet-Exposition gegenüber gestohlenen Mitteln | +85 Score, `IN_REVIEW` |
| `crypto-scam-exposure` | Wallet-Exposition gegenüber Scams | +70 Score, `IN_REVIEW` |
| `crypto-ransomware-exposure` | Wallet-Exposition gegenüber Ransomware | +90 Score, `IN_REVIEW` |
| `crypto-hacked_exchange-exposure` | Wallet-Exposition gegenüber gehackten Börsen | +80 Score, `IN_REVIEW` |
| `crypto-gambling_unlicensed-exposure` | Wallet-Exposition gegenüber unlizenziertem Glücksspiel | +60 Score, `IN_REVIEW` |
| `high-risk-wallet-exposure` | Das Wallet-Risiko betrifft einen Darknet-Markt, sanktionierte Wallets oder gestohlene Mittel | +70 Score, `IN_REVIEW` |
| `crypto-wallet-risk-score-critical` | Wallet-Score des Anbieters ≥ 90 | +90 Score, `IN_REVIEW` |
| `crypto-wallet-risk-score-high` | Wallet-Score des Anbieters ≥ 70 | +60 Score, `IN_REVIEW` |
| `crypto-unhosted-wallet-large-outbound` | Ausgehender Transfer von ≥ \$1,000 an eine selbstverwahrte Wallet | +45 Score, `IN_REVIEW` |
| `crypto-repeated-unhosted-wallet-withdrawals` | ≥5 ausgehende Überweisungen an selbstverwahrte Wallets innerhalb von 24 Stunden | +35 Score, `IN_REVIEW` |
| `crypto-many-new-wallets-per-subject` | Subjekt sendet an ≥5 verschiedene Wallets innerhalb von 24 Stunden | +40 Score, `IN_REVIEW` |
| `crypto-chain-hopping-pattern` | Dasselbe Subjekt transferiert Mittel über ≥3 Blockchains innerhalb von 24 Stunden | +45 Score, `IN_REVIEW` |
| `crypto-missing-vasp-id-high-value` | Transfer über eine verwahrte Wallet ≥ \$1,000 ohne VASP-Kennung | +30 Score, `IN_REVIEW` |

***

## Travel-Rule-Bundle

Travel-Rule-Regeln gelten nur für `travelRule`-Transaktionen.
Jedes regionale Regelwerk umfasst vier Regeln (wartende Gegenpartei, ausstehende Aktion, fehlende Daten, fehlgeschlagener Datenaustausch).

### Globale Travel Rule

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `travel-rule-pending-counterparty` | Status ist `AWAITING_COUNTERPARTY` (wartet auf den VASP der Gegenpartei) | +35 Score, `IN_REVIEW` |
| `travel-rule-pending-action` | Status ist `ON_HOLD` (bei einer verwalteten Börse ein eingehender Transfer, der auf Ihre Klärung wartet: keine Übereinstimmung im Wallet-Adressbuch oder eine Anfrage, die auf manuelle Genehmigung wartet) | +35 Score, `AWAITING_USER` |
| `travel-rule-missing-required-data` | `travel_rule_required` ist `true` und `travel_rule_obligations_count` ist größer als `0`; nur Travel-Rule-Daten, die Sie selbst in `travel_rule_details` erfassen, enthalten eine Anzahl von Pflichten, daher wird diese Regel bei einem Transfer, den die verwaltete Börse ausführt, nie ausgelöst | +50 Score, `IN_REVIEW` |

### Regionale Regelwerke

Die gleiche Vier-Regel-Vorlage wird für jedes Regelwerk angewendet. Ersetzen Sie `<regime>` unten durch einen der folgenden Werte: `australia`, `dubai`, `eu`, `hong_kong`, `india`, `indonesia`, `japan`, `kazakhstan`, `singapore`, `south_africa`, `turkey`, `uk`.

Die Regime-Zuordnung erfolgt automatisch: Didit setzt `custom_values.travel_rule_regime` bei jeder Travel-Rule-Transaktion anhand des `jurisdiction` in Ihren [Travel-Rule-Einstellungen](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#einrichtung). Dabei gilt `SG` → `singapore`, `GB` → `uk` und jeder Ländercode eines EU- oder EWR-Mitgliedstaats wie `DE` oder `FR` → `eu`. Codes ohne regionales Bundle werden in Kleinbuchstaben übernommen (`US` → `us`), damit benutzerdefinierte Regeln sie trotzdem ansprechen können. Ein `props.travel_rule_regime`-Wert, der bei der Transaktion übermittelt wird, überschreibt immer das abgeleitete Regime.

| `library_key`-Vorlage | Auslöser |
| - | - |
| `travel-rule-<regime>-pending-counterparty` | Transfer mit Regime-Kennzeichnung wartet auf den VASP der Gegenpartei |
| `travel-rule-<regime>-pending-action` | Transfer mit Regime-Kennzeichnung hat den Status `ON_HOLD` |
| `travel-rule-<regime>-missing-required-data` | Transfer mit Regime-Kennzeichnung ist erforderlich, aber nicht geklärt |
| `travel-rule-<regime>-failed-exchange` | Transfer mit Regime-Kennzeichnung hat den Status `CANCELLED` |

Das ergibt 48 regionsspezifische Regeln zusätzlich zu den drei globalen Travel-Rule-Regeln und den fünf Gegenpartei-Regeln unten.
Das separate Bundle `travel_rule_eu_tfr` ergänzt vier EU-TFR-Regeln, die im [EU-TFR-Regel-Bundle](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#regelpaket-eu-tfr) beschrieben sind.

### Due-Diligence der Gegenpartei

Diese Regeln werten aus, was Ihre Anwendung über den VASP der Gegenpartei weiß, mit dem die Börse Kontakt aufgenommen hat: Ihre eigene Entscheidung dazu, dessen Due-Diligence-Risikostufe, dessen Land und dessen Reaktionsverhalten.
Die Herkunft der einzelnen Werte finden Sie unter [Due-Diligence der Gegenpartei](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#due-diligence-für-gegenparteien).

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `travel-rule-counterparty-blocked` | Ihre Entscheidung zur Gegenpartei (`counterparty_dd_status`) ist `BLOCKED` | +90 Score, `DECLINED` |
| `travel-rule-counterparty-restricted` | Ihre Entscheidung zur Gegenpartei ist `RESTRICTED` | +50 Score, `IN_REVIEW` |
| `travel-rule-counterparty-high-risk` | Die Risikostufe der Gegenpartei (`counterparty_risk_level`) ist `HIGH`: ein Due-Diligence-Score unter 40 oder Ihr eigenes aktuelles Screening der Gegenpartei hat einen möglichen Treffer im Zusammenhang mit Sanktionen oder in negativen Medienberichten ergeben | +40 Score, `IN_REVIEW` |
| `travel-rule-counterparty-high-risk-jurisdiction` | Die Gegenpartei ist in einem Land ansässig, das auf der Standard-Hochrisikoliste steht (`IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`) | +60 Score, `IN_REVIEW` |
| `travel-rule-counterparty-unresponsive` | Die Gegenpartei hat weniger als 10 Prozent der Travel-Rule-Anfragen beantwortet, die Didit-Kunden in den letzten 90 Tagen an sie gesendet haben, wobei mindestens 5 davon entschieden wurden | +30 Score, `IN_REVIEW` |

***

## Geräteintelligenz & Betrugsprävention

Diese Regeln wandeln Signale aus dem Client-SDK (Geräte-Fingerprint, IP, Browser, Sitzungsalter) und die Anreicherung durch Anbieter in Ereignisse zur Betrugserkennung um.

### Geräte-Fingerprint & Mehrfachkonten

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `multi-accounting-shared-fingerprint` | Ein Geräte-Fingerprint wird innerhalb von 7 Tagen von ≥3 verschiedenen Subjekten genutzt | +50 Score, `IN_REVIEW` |
| `multiple-device-fingerprints-for-same-subject` | Ein Subjekt erscheint innerhalb von 24 Stunden mit ≥3 verschiedenen Fingerprints | +20 Score |
| `same-fingerprint-transaction-burst` | ≥6 Transaktionen von einem Fingerprint innerhalb von 24 Stunden | +30 Score |
| `same-ip-multi-accounting` | Eine IP-Adresse wird innerhalb von 7 Tagen von ≥3 verschiedenen Subjekten geteilt | +30 Score |
| `same-ip-transaction-burst` | ≥6 Transaktionen von einer IP-Adresse innerhalb von 24 Stunden | +30 Score |
| `same-fingerprint-multiple-payment-methods` | Ein Fingerprint wechselt innerhalb von 7 Tagen zwischen ≥4 Zahlungsmethoden | +30 Score |
| `shared-payment-method-across-subjects` | Eine Zahlungsmethode wird innerhalb von 7 Tagen von ≥3 verschiedenen Subjekten wiederverwendet | +30 Score |
| `many-ip-addresses-per-subject` | Ein Subjekt nutzt innerhalb von 24 Stunden ≥4 verschiedene IP-Adressen | +30 Score |
| `new-browser-and-new-ip-combination` | Ein Subjekt zeigt innerhalb von 24 Stunden ≥3 verschiedene Browser UND ≥3 verschiedene IP-Adressen | +30 Score |

### IP, Netzwerk & VPN

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `vpn-or-proxy-high-value` | VPN oder Proxy bei einer Überweisung ab \$5,000 erkannt | +30 Score |
| `impossible-travel-between-transactions` | Ein Subjekt führt innerhalb von 1 Stunde Transaktionen aus ≥2 verschiedenen Ländern der IP-Adressen durch | +30 Score |

### Verhaltensbasierte Kombination

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `browser-spoofing-password-reuse` | Browser-Spoofing erkannt UND ≥2 Transaktionen mit demselben Passwort-Hash innerhalb von 30 Minuten | +30 Score |
| `remote-access-high-value-transfer` | Remote-Access-Tool bei einer Überweisung ab \$5,000 erkannt | +30 Score |
| `low-session-age-high-value-transfer` | Überweisung ab \$5,000 innerhalb von 30 Sekunden nach Sitzungsbeginn | +30 Score |
| `synthetic-identity-fresh-account-high-value` | Konto, das in den letzten 7 Tagen eröffnet wurde, führt Transaktionen über ≥ \$1,000 durch | +30 Score |

### Kontoübernahme & APP-Betrug

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `recent-pii-change-and-transaction` | Überweisung ab \$1,000 innerhalb des Zeitfensters der letzten PII-Änderung | +45 Score, `IN_REVIEW` |
| `new-payment-method-high-value` | Überweisung ab \$5,000 mit einer Zahlungsmethode, die in den letzten 7 Tagen hinzugefügt wurde | +30 Score |
| `first-time-payee-high-value` | Ausgehende Zahlung ab \$5,000 an eine Gegenpartei, an die das Subjekt noch nie gezahlt hat | +40 Score, `IN_REVIEW` |
| `consortium-flagged-counterparty` | Überweisung ab \$500, deren Gegenpartei von einem anderen Institut gemeldet wurde | +60 Score, `IN_REVIEW` |

### Affiliate- & Bonusmissbrauch

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `repeated-bonus-campaign-from-same-fingerprint` | ≥6 Transaktionen derselben Kampagne mit demselben Fingerprint innerhalb von 2 Stunden | +35 Score |
| `shared-fingerprint-across-bonus-campaigns` | Ein Fingerprint beansprucht innerhalb von 7 Tagen ≥3 verschiedene Kampagnen | +30 Score |
| `affiliate-fraud-repeated-fingerprint` | ≥5 Transaktionen desselben Affiliates mit demselben Fingerprint innerhalb von 2 Stunden | +30 Score |

***

## Paket für verantwortungsvolles Spielen

Für iGaming-Anwendungen. Diese Regeln sind darauf ausgelegt, sowohl Signale zum Spielerschutz als auch Muster von Bonusmissbrauch zu erkennen.

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `responsible-gaming-rapid-deposits` | ≥10 eingehende Transaktionen derselben Aktion innerhalb von 24 Stunden | +20 Score |
| `responsible-gaming-rapid-withdrawals` | ≥8 ausgehende Transaktionen derselben Aktion innerhalb von 24 Stunden | +20 Score |
| `responsible-gaming-cumulative-deposits-7d` | Eingehendes Volumen ab \$5,000 innerhalb von 7 Tagen | +20 Score |
| `responsible-gaming-cumulative-withdrawals-7d` | Ausgehendes Volumen ab \$5,000 innerhalb von 7 Tagen | +20 Score |
| `responsible-gaming-self-excluded-activity` | Jede Transaktion von einem Konto mit Selbstausschluss | +20 Score |
| `responsible-gaming-loss-limit-hit` | Aktivität wird nach einem Verlustlimit-Signal fortgesetzt | +20 Score |
| `responsible-gaming-bonus-hunting` | ≥4 Transaktionen mit derselben Kampagne und demselben Fingerprint innerhalb von 24 Stunden | +20 Score |
| `responsible-gaming-multiple-payment-methods` | ≥4 verschiedene Zahlungsmethoden innerhalb von 7 Tagen | +20 Score |
| `responsible-gaming-off-hours-high-value` | Als außerhalb der Geschäftszeiten markiertes Spiel ab \$1,000 | +20 Score |
| `responsible-gaming-failed-withdrawals` | ≥3 fehlgeschlagene Auszahlungsversuche | +20 Score |
| `responsible-gaming-many-counterparties` | ≥5 verschiedene Gegenparteien innerhalb von 24 Stunden | +20 Score |

***

## iGaming-Betrugs-Bundle

Für Betreiber, die neben Geldbewegungen auch Überwachungsereignisse senden. Diese Regeln verwenden `scope.record_types = ["event"]`, daher ändert sich das Verhalten bei Kunden, die nur Transaktionen senden, nicht. Wo ein Fallback für reine Transaktionen existiert, installieren Sie die genannte Fallback-Regel zusätzlich zur Ereignisregel, bis Ihre Integration die Ereigniskategorie sendet.

| `library_key` | Auslöser | Standardaktion | Fallback für reine Transaktionen |
| - | - | - | - |
| `igaming-account-takeover-drain` | 3+ fehlgeschlagene Anmeldungen, danach eine MFA-Änderung, danach eine Änderung der Auszahlungsadresse, danach eine Auszahlungsanfrage, in dieser Reihenfolge innerhalb von 24h | +90 Score, `DECLINED` | `recent-pii-change-and-transaction`, `new-payment-method-high-value` |
| `igaming-minimal-play-laundering` | Auszahlungsanfrage ≥ \$1,000, während die Wetten des Kontos in den vorangegangenen 24h höchstens 5% seiner abgeschlossenen Einzahlungen betragen | +60 Score, `IN_REVIEW` | `rapid-in-and-out-movement` |
| `igaming-chargeback-deposit-ratio` | Eröffnete Chargebacks erreichen in 30 Tagen mindestens 50% der abgeschlossenen Einzahlungen | +80 Score, `DECLINED` | `ecommerce-chargeback-indicator` |
| `igaming-chip-dumping-pair-net-winner` | Dasselbe P2P-Paar schließt in 7 Tagen mindestens 2 verschiedene Hände, Runden oder Matches ab **und** das Nettoergebnis einer Seite beträgt insgesamt ≥ \$400 | +70 Score, `IN_REVIEW` | Ereignis erforderlich |
| `igaming-opposite-betting-same-market` | Beide Seiten desselben Matches und Markts werden von 2+ verschiedenen Konten mit demselben Geräte-Fingerprint gesetzt, innerhalb von 1h | +65 Score, `IN_REVIEW` | Ereignis erforderlich |
| `igaming-bot-rta-cadence` | `session.bot_signal_observed` meldet einen Bot-Score ≥ 90 und eine Timing-Varianz ≤ 10ms | +55 Score, `IN_REVIEW` | Ereignis erforderlich |
| `igaming-self-exclusion-evasion` | Treffer im Selbstsperr-Register mit `exclusion_status: active` bei einem Versuch der erneuten Registrierung | +100 Score, `DECLINED` | `responsible-gaming-self-excluded-activity` |
| `igaming-chat-rain-farming` | Zweiter Anspruch auf **denselben** Chat-Rain-Bonus durch ein Konto in 24h, geltend gemacht innerhalb von 500ms | +45 Score, `IN_REVIEW` | `responsible-gaming-bonus-hunting` |
| `igaming-repeated-bonus-claims-one-device` | Dritter Anspruch auf **denselben** Bonus von einem Geräte-Fingerprint in 7 Tagen | +50 Score, `IN_REVIEW` | `repeated-bonus-campaign-from-same-fingerprint`, `shared-fingerprint-across-bonus-campaigns`, `responsible-gaming-bonus-hunting` |
| `igaming-affiliate-self-referral` | Zuordnung zu einem Affiliate-Code, den 3+ verschiedene Konten in 7 Tagen von einem Geräte-Fingerprint aus verwendet haben | +50 Score, `IN_REVIEW` | `affiliate-fraud-repeated-fingerprint` |
| `igaming-multi-accounting-device` | Anmeldung oder Registrierung von einem Geräte-Fingerprint, der in 24h von 3+ verschiedenen Konten verwendet wird | +60 Score, `IN_REVIEW` | `multi-accounting-shared-fingerprint` |
| `igaming-shared-proxy-ip` | Anmeldung von einer Adresse, die in 24h von 3+ verschiedenen Konten verwendet wird | +40 Score, `IN_REVIEW` | `same-ip-multi-accounting` |

### Ereignissignale, die jede Regel benötigt

Jede der oben genannten Regeln liest benannte Ereignisfelder. Fehlt ein benötigtes Feld, greift die Regel einfach nicht. Sie leitet das Signal nie aus anderen Daten ab und greift nie allein auf Transaktionsdaten zurück. Senden Sie die unten aufgeführten Schlüssel im Ereignis-`payload` und in `device_context` (siehe [Ereignisse](https://docs.didit.me/de/transaction-monitoring/events.md) für den vollständigen Übermittlungsvertrag und [Ereignisregeln](https://docs.didit.me/de/transaction-monitoring/event-rules.md) für die Feldpfade der Regeln).

| `library_key` | Gelesene Ereignisaktionen | Felder, die die Regel benötigt |
| - | - | - |
| `igaming-account-takeover-drain` | `security.login_failed`, `security.mfa_changed`, `payment.withdrawal_address_changed`, `payment.withdrawal_requested` | `changed_field`, `withdrawal_address_hash` sowie die standardmäßigen Zahlungsschlüssel |
| `igaming-minimal-play-laundering` | `payment.withdrawal_requested`, `gameplay.bet_placed`, `payment.deposit_completed` | `amount` bei jedem dieser Ereignisse |
| `igaming-chargeback-deposit-ratio` | `dispute.chargeback_opened`, `payment.deposit_completed` | `payment_reference_id` sowie `dispute_id` oder `chargeback_id` |
| `igaming-chip-dumping-pair-net-winner` | `gameplay.p2p_settlement` | `counterparty_vendor_data`, `net_result_amount` und einen von `hand_id` / `round_id` / `match_id` |
| `igaming-opposite-betting-same-market` | `gameplay.bet_placed` | `match_id`, `market_id`, `side`, `device_context.fingerprint` |
| `igaming-bot-rta-cadence` | `session.bot_signal_observed` | `device_context.bot_score`, `timing_variance_ms` |
| `igaming-self-exclusion-evasion` | `responsible_gambling.self_exclusion_match` | `exclusion_status`, `re_registration_attempt` sowie die erforderlichen `registry_source` und `identity_match_ref` |
| `igaming-chat-rain-farming` | `bonus.bonus_claimed` | `bonus_id`, `bonus_type`, `claim_delay_ms` |
| `igaming-repeated-bonus-claims-one-device` | `bonus.bonus_claimed` | `bonus_id`, `device_context.fingerprint` |
| `igaming-affiliate-self-referral` | `affiliate.affiliate_attributed` | `affiliate_code`, `device_context.fingerprint` |
| `igaming-multi-accounting-device` | `security.login_succeeded` oder ein benutzerdefiniertes `security.registration_attempt` | `device_context.fingerprint` |
| `igaming-shared-proxy-ip` | `security.login_succeeded` | `device_context.network_context.ip_address` |

Verwenden Sie das `igaming_fraud`-Bundle, wenn Ihre Integration Ereignisse zu Logins, Gameplay, Boni, Affiliates, Zahlungen, Disputes, Sicherheit und verantwortungsvollem Spielen sendet. Die Regeln sind Opt-in: Das Hinzufügen zur Bibliothek installiert sie nicht für bestehende Anwendungen und ändert nicht die aktuellen Presets aktiver Kunden.

***

## E-Commerce-Bundle

Für Marktplätze und Merchant-of-Record-Anwendungen.

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `ecommerce-card-testing-microtransactions` | ≥10 Transaktionen ≤ \$5 vom selben Fingerprint in 1 Stunde | +30 Score |
| `ecommerce-high-order-velocity` | ≥8 Transaktionen auf einem Fingerprint in 30 Minuten | +30 Score |
| `ecommerce-chargeback-indicator` | Anbieter/Workflow hat einen Chargeback-Indikator gekennzeichnet | +30 Score |
| `ecommerce-billing-country-mismatch` | Abweichendes Rechnungsland bei einer Transaktion ≥ \$500 | +30 Score |
| `ecommerce-shared-payment-method` | Zahlungsmethode wurde von ≥3 E-Commerce-Subjekten innerhalb von 7 Tagen wiederverwendet | +30 Score |
| `ecommerce-shared-ip-multi-accounting` | Eine Adresse wird von ≥4 E-Commerce-Subjekten innerhalb von 24 Stunden geteilt | +30 Score |
| `ecommerce-remote-checkout-high-value` | Fernzugriff bei einem Checkout im Wert von ≥ \$1,000 erkannt | +30 Score |
| `ecommerce-affiliate-burst` | ≥5 Transaktionen über denselben Affiliate und Fingerprint in 2 Stunden | +30 Score |

***

## Bundle für Scheckbetrug

Für Anwendungen, die Scheckeinzahlungs-Transaktionen übermitteln. Jede Regel wird durch `custom_values.check_*`-Flags ausgelöst, die der Aufrufer setzt, wenn ein Scheck ein bekanntes Risikosignal aufweist (Washing, fehlende MICR-Zeile, im Dark Web gelistete Seriennummer usw.).

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `check-amount-out-of-range` | Scheckbetrag als außerhalb des üblichen Bereichs des Kontos markiert UND ≥ \$1,000 | +40 Score, `IN_REVIEW` |
| `check-missing-or-invalid-number` | Scheck kam mit einer fehlenden, inkonsistenten oder nicht fortlaufenden Schecknummer an | +35 Score, `IN_REVIEW` |
| `check-duplicate-presentation` | Derselbe Scheck scheint zweimal eingereicht worden zu sein (mobil + Filiale) | +70 Score, `IN_REVIEW` |
| `check-on-dark-web-watchlist` | Seriennummer bzw. Abbild des Schecks wurde in einem Dark-Web- oder Telegram-Feed mit gestohlenen Schecks gefunden | +90 Score, `DECLINED` |
| `check-altered-or-washed` | Scheck weist chemische Entfernung, MICR-Manipulation oder andere Hinweise auf Scheckwäsche auf | +70 Score, `IN_REVIEW` |
| `check-deposit-rapid-multi-bank` | Dasselbe Subjekt reicht Schecks bei ≥3 verschiedenen Banken von Gegenparteien innerhalb von 24 Stunden ein (Kiting) | +45 Score, `IN_REVIEW` |

***

## BNPL-Bundle

Für Anbieter von Buy-now-pay-later-Angeboten (BNPL). Erkennt First-Party-Betrug (Nichtzahlung) und Muster bei gemeinsam genutzten Identifikatoren, die für Ratenkredite typisch sind.

| `library_key` | Auslöser | Standardaktion |
| - | - | - |
| `bnpl-failed-repayment-velocity` | ≥2 kürzliche fehlgeschlagene Rückzahlungen beim Subjekt: Signal für First-Party-Betrug | +45 Score, `IN_REVIEW` |
| `bnpl-shared-identifier-across-accounts` | Telefonnummer, E-Mail-Adresse oder Postanschrift wurde bei mehreren verschiedenen BNPL-Subjekten gesehen | +40 Score, `IN_REVIEW` |
| `bnpl-high-installment-on-fresh-account` | Ratenzahlung ≥ \$500 von einem Konto, das in den letzten 7 Tagen eröffnet wurde | +35 Score |

***

## Referenz: Standards hinter der Bibliothek

Jedes Preset in der Bibliothek von Didit ist einer allgemein anerkannten Typologie aus den Bereichen AML, Betrug oder Compliance zugeordnet. Dies sind die Standards, auf die wir uns stützen:

| Quelle | Zur Bibliothek beigetragene Typologien |
| - | - |
| **FATF-Empfehlungen** | Structuring, schnelle Bewegung von Geldern, Risikoexposition gegenüber Hochrisikojurisdiktionen, Sanktionsprüfung von Gegenparteien |
| **FinCEN-Hinweise** | BSA-/CTR-Meldeschwellen, Reaktivierung ruhender Konten, verdächtige Bargeldmuster |
| **NACHA-Regeln** | ACH-spezifische Schwellenwerte und Muster außerhalb der Geschäftszeiten |
| **Wolfsberg-Prinzipien** | Typologien des Korrespondenzbankgeschäfts und des Private Banking |
| **Egmont-Group-Typologien** | Grenzüberschreitende Muster und Layering |
| **Bewährte Branchenpraxis** | Velocity-Fensterung, Impossible Travel, erstmaliger Zahlungsempfänger, Wiederverwendung von Geräte-Fingerprints, BNPL-Signale für First-Party-Betrug |

Didit implementiert nur Typologien, die anerkannte Branchenstandards sind, und macht jeden Schwellenwert für Sie zur Anpassung zugänglich.

***

## Presets anpassen

Jedes Preset kann folgendermaßen angepasst werden:

* **Feinabgestimmt**: Schwellenwerte, Zeitfenster, Score-Werte oder Aktionen pro Anwendung ändern
* **Deaktiviert**: Ein Preset auf den Modus `DISABLED` setzen. Es wird dann nicht mehr ausgewertet, behält aber seine Identität.
* **Getestet**: Ein Preset auf den Modus `TEST` setzen, um es im Schattenmodus auszuwerten, ohne die Ergebnisse von Transaktionen zu beeinflussen
* **Erweitert**: Eigene Regeln anlegen, die Presets ergänzen oder überschreiben

Siehe [Regeln und Scoring](https://docs.didit.me/de/transaction-monitoring/rules.md) für den Aufbau von Regeln, die API-Endpoints und Beispiele zum Erstellen eigener Regeln.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.