Geschwindigkeitsregeln und Strukturierungserkennung: Ein Entwicklerhandbuch (DE-1)

Betrachten Sie eine einzelne Zahlung, und sie sagt Ihnen in der Regel nichts. 9.700 € an einen Geschäftspartner sind unauffällig. Aber zehn Zahlungen von 9.700 € an denselben Geschäftspartner innerhalb von drei Tagen oder zwanzig eingehende Überweisungen von zwanzig verschiedenen Konten an einem Nachmittag sind Anzeichen für Strukturierungs- und Mule-Aktivitäten. Um diese zu erkennen, müssen Transaktionen als Stream – über die Zeit, mit Zählen und Summieren – und nicht einzeln betrachtet werden.

Das ist die Aufgabe von Geschwindigkeitsregeln, und sie sind der schwierigste Teil der Transaktionsüberwachung, den man selbst aufbauen kann. Sie benötigen einen Stream-Prozessor, der rollierende Fenster pro Benutzer verwaltet, Zählungen und Summen durchführt und Geschäftspartner innerhalb dieser Fenster dedupliziert sowie Schwellenwerte in Echtzeit bewertet. Didits Transaction Monitoring API bietet Ihnen diese Engine sofort einsatzbereit: Definieren Sie ein Fenster, wählen Sie eine Aggregation – Zählen, Summe oder Distinct –, legen Sie einen Schwellenwert fest, und die Regel wird gegen jede Transaktion zu 0,02 $ pro Transaktion ausgeführt.

Dies ist ein Entwicklerhandbuch zum Erstellen von Geschwindigkeitsregeln und deren Verwendung zur Erkennung von Strukturierungen.

Wichtige Erkenntnisse

• Geschwindigkeitsregeln werden über Zeitfenster bewertet – „in den letzten 24 Stunden“, „über 7 Tage“ – anstatt eine einzelne Transaktion isoliert zu bewerten.
• Drei Aggregationen: count (wie viele), sum (kumulierter Betrag) und distinct (eindeutige Geschäftspartner oder Attribute) – die Bausteine der Strukturierungs- und Mule-Erkennung.
• Strukturierung – viele Zahlungen knapp unter einem Meldeschwellenwert – wird durch die Kombination eines Summenfensters mit einer Schwellenwertnähe-Bedingung erfasst.
• Mule- und Smurfing-Muster werden mit Distinct-Counterparty-Zählungen innerhalb eines Fensters erfasst.
• Kein Stream-Prozessor erforderlich – die Engine verwaltet die Fenster; Sie deklarieren die Regel in der Konsole.
• 0,02 $ pro Transaktion, keine Mindestbeträge. Die AML-Prüfung einer markierten Partei wird separat mit 0,20 $ berechnet.

Was Geschwindigkeitsregeln sind

Eine Geschwindigkeitsregel besteht aus drei Teilen: einem Fenster (der Betrachtungszeitraum – 1 Stunde, 24 Stunden, 7 Tage), einer Aggregation über die Transaktionen in diesem Fenster und einem Schwellenwert, der bei Überschreitung eine Aktion auslöst. Die Aggregationen sind der expressive Kern:

• count – wie viele Transaktionen die Bedingungen der Regel im Fenster erfüllt haben. „Mehr als 5 eingehende Überweisungen in 24 Stunden.“
• sum – der kumulierte Wert der übereinstimmenden Transaktionen. „Kumuliertes Volumen über 10.000 € in 7 Tagen.“
• distinct – die Anzahl der eindeutigen Werte eines Attributs, normalerweise der Geschäftspartner. „Überweisungen von mehr als 8 verschiedenen Absendern in 24 Stunden.“

Fenster werden standardmäßig pro Subjekt schlüsselbasiert – jeder Benutzer hat seine eigenen rollierenden Zähler – so dass ein geschäftiger Tag für Ihre gesamte Plattform das Signal eines einzelnen Benutzers nicht überdeckt.

Warum es wichtig ist

Strukturierung (auch Smurfing genannt) ist eine der ältesten Geldwäschetechniken und eine der am explizitesten regulierten. Meldeschwellenwerte – 10.000 € in weiten Teilen der EU, 10.000 $ in den USA – schaffen einen Anreiz, große Summen in kleinere Zahlungen aufzuteilen, die jeweils unter der Grenze bleiben. Eine Zeitpunktregel, die nur einzelne Beträge prüft, wird dies nie erkennen; das gesamte Muster liegt im Aggregat.

Dasselbe gilt für Mule-Netzwerke. Das Merkmal eines Money Mules ist keine einzelne Überweisung – es ist der Zufluss von Geldern von vielen verschiedenen Konten, gefolgt von einem schnellen Abfluss. Dies sehen Sie nur bei Distinct-Counterparty-Zählungen über ein Fenster. Aufsichtsbehörden erwarten von Unternehmen, dass sie diese Typologien erkennen, und Geschwindigkeitsregeln sind der Weg, dies zu tun, ohne einen eigenen Streaming-Analytics-Stack aufzubauen.

Technische Details

Transaktionen werden über die vereinheitlichte /v3/ API erstellt, idempotent auf einer transaction_id, die Sie kontrollieren:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_a19f04",
    "category": "finance",
    "amount": 9600,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T13:18:00Z",
    "subject": { "vendor_data": "user_3310", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" },
    "payment_method": "BANK_TRANSFER"
  }'

Wenn die Transaktion ein Strukturierungsmuster vervollständigt, wird die Geschwindigkeitsregel ausgelöst und die Antwort benennt sie:

{
  "transaction_id": "txn_a19f04",
  "status": "IN_REVIEW",
  "risk_score": 66,
  "triggered_rules": [
    {
      "name": "Strukturierung — kumulative Summe nahe am Schwellenwert",
      "bundle": "Finance",
      "aggregation": "sum",
      "window": "7d",
      "action": "CHANGE_STATUS"
    }
  ],
  "alert_id": "alrt_b4d8e1"
}

Webhooks. Abonnieren Sie transaction.created und transaction.status.updated, um Ihr Ledger synchron zu halten, wenn Warnungen behoben werden.

Preis. 0,02 $ pro Transaktion, pro Aufruf abgerechnet, keine Mindestbeträge. Die AML-Prüfung einer markierten Partei wird separat mit 0,20 $ berechnet.

Erstellen von Strukturierungs- und Mule-Regeln

Strukturierung (Summenfenster). Kombinieren Sie eine sum-Aggregation über ein 7-Tage-Fenster mit einer Pro-Transaktion-Bedingung, dass der Betrag knapp unter Ihrem Meldeschwellenwert liegt. Die Regel wird ausgelöst, wenn die kumulierten Zahlungen eines Benutzers, die knapp unter dem Schwellenwert liegen, eine von Ihnen festgelegte Grenze überschreiten – die aggregierte große Transaktion, die die Strukturierung verbergen sollte. Passen Sie die Schwellenwertnähe (wie nah an der Meldelinie als „knapp unter“ zählt) und den kumulativen Auslöser an.

Smurfing (Zählfenster). Eine count-Aggregation über ein kurzes Fenster erfasst einen Stoß von kleinen Zahlungen. „Mehr als 10 ausgehende Überweisungen unter 1.000 € in 24 Stunden“ deckt das Fragmentierungsmuster auf, selbst wenn keine einzelne Zahlung groß ist.

Mule Fan-in (Distinct-Fenster). Eine distinct-Aggregation auf dem Geschäftspartner erfasst den Fan-in: „Eingehende Überweisungen von mehr als 8 verschiedenen Absendern in 24 Stunden.“ Kombinieren Sie dies mit einer schnellen Fan-out-Zählregel, und Sie haben die vollständige Mule-Signatur beschrieben.

Diese lassen sich den vordefinierten Bundles zuordnen – Strukturierung und Schwellenwertvermeidung finden sich in Finance, kumuliertes Volumen und schnelle Ein-/Ausgänge in AML/CTF, Geschwindigkeitspitzen in der Anomalieerkennung – und Sie können diese erweitern oder Ihre eigenen im Custom-Bundle erstellen. Jede Regelaktion kann zum Risikowert beitragen, den Status ändern, Tags hinzufügen oder die Partei zu einer Liste hinzufügen.

Anwendungsfälle

• Fintech – kumulative Summen-Strukturierungsregeln für Überweisungen und Abhebungen; Distinct-Counterparty-Mule-Regeln für eingehende Einzahlungen.
• Krypto – Zählfenster für schnelle In- und Out-Wallet-Aktivitäten; Distinct-Regeln für Gelder, die von vielen Adressen vor einem einzelnen großen Abfluss ankommen.
• Kreditvergabe – Geschwindigkeitsregeln für Auszahlungs- und Rückzahlungsmuster, um Bust-Out-Betrug zu erkennen.
• Marktplätze – Distinct-Buyer-Zählregeln, um kollusive Transaktionsringe zu erkennen, die das Volumen eines Verkäufers aufblähen.
• iGaming – Einzahlungsgeschwindigkeits-Zählfenster, die auch als Signal für verantwortungsvolles Spielen dienen.

So integrieren Sie Didit

1. Definieren Sie die Fenster. Erstellen Sie in der Business Console Geschwindigkeitsregeln mit dem Fenster, der Aggregation (Zählen/Summe/Distinct) und dem Schwellenwert, die Ihre Richtlinie erfordert.
2. Senden Sie Transaktionen. POST /v3/transactions/ von Ihrem Backend, wenn Geld bewegt wird, mit einer stabilen transaction_id und vendor_data, damit die Engine Fenster dem richtigen Subjekt zuordnet.
3. Verarbeiten Sie Webhooks. Hören Sie auf transaction.status.updated, um zu reagieren, wenn eine Geschwindigkeitsregel ausgelöst wird und ein Analyst die Warnung behebt.
4. Im Laufe der Zeit optimieren. Passen Sie Schwellenwerte in der Konsole an, wenn Sie Ihre True-Positive- und False-Positive-Raten kennenlernen – keine Bereitstellung erforderlich.

Da alles über die vereinheitlichte /v3/ API läuft, fließt ein Benutzer, der mit KYC-Workflows onboarded wurde, direkt in dieselbe Engine, die diese Geschwindigkeitsregeln ausführt – eine Identitäts- und Betrugsplattform, End-to-End.

Häufig gestellte Fragen

Welche Aggregationen kann eine Geschwindigkeitsregel verwenden?

Drei: count (Anzahl der übereinstimmenden Transaktionen), sum (kumulierter Betrag) und distinct (eindeutige Geschäftspartner oder Attribute), jeweils über ein von Ihnen definiertes Zeitfenster bewertet.

Wie erkenne ich speziell Strukturierung?

Kombinieren Sie eine sum-Aggregation über ein Fenster mit der Bedingung, dass jede Zahlung knapp unter Ihrem Meldeschwellenwert liegt. Die Regel wird ausgelöst, wenn die kumulierte Summe die Grenze überschreitet, die die Strukturierung verbergen sollte.

Benötige ich einen eigenen Stream-Prozessor?

Nein. Die Engine verwaltet die rollierenden Fenster pro Subjekt. Sie deklarieren das Fenster, die Aggregation und den Schwellenwert in der Konsole.

Wie viel kostet es?

0,02 $ pro Transaktion, pro Aufruf abgerechnet, ohne Mindestbeträge. Die AML-Prüfung einer markierten Partei wird separat mit 0,20 $ berechnet.

Kann ich Geschwindigkeitsregeln erstellen, die in den vordefinierten Bundles nicht enthalten sind?

Ja. Das Custom-Bundle unterstützt Bedingungen, Geschwindigkeitsfenster und Aggregationen für jede Typologie, die für Ihr Produkt einzigartig ist.

Bereit zum Starten?

Lesen Sie die Übersicht zur Transaktionsüberwachung in den Docs, sehen Sie, wie sie zum Rest der Plattform auf der Produktseite zur Transaktionsüberwachung passt, und überprüfen Sie die transparenten Preise pro Aufruf auf der Preisseite. Wenn Sie bereit sind, starten Sie kostenlos – 500 kostenlose KYC-Prüfungen jeden Monat und Transaktionsüberwachung für 0,02 $ pro Aufruf.