Zum Hauptinhalt springen
Didit erhält 7,5 Mio. $ für die Infrastruktur für Identität und Betrug
Didit
Zurück zum Blog
Blog · 21. Mai 2026

SAR-Workflow ohne separates Fallbearbeitungstool (DE)

Warnmeldungen, Fallbearbeitung, Analystenzuweisung und SAR-Einreichung sind in Didits Transaktionsüberwachung integriert – nicht nachträglich von einem separaten Fallmanagement-Anbieter hinzugefügt.

Von DiditAktualisiert
sar-workflow-case-management-api.png

Eine auslösende Regel ist der einfache Teil. Was danach passiert – die Warnung, die Untersuchung, die Eskalation, die Entscheidung, eine Verdachtsmeldung (SAR) einzureichen – ist der Bereich, in dem die meisten Compliance-Vorgänge tatsächlich stattfinden und wo sich die meisten Kosten verbergen. Die typische Einrichtung verbindet drei Dinge miteinander: einen Überwachungsanbieter, der Warnmeldungen generiert, ein separates Fallmanagement-Tool, das die Untersuchung verwaltet, und einen manuellen SAR-Prozess, der oft in einer Tabelle und einem PDF endet. Daten werden zwischen Systemen neu eingegeben, die Prüfspur fragmentiert sich, und Analysten verbringen ihren Tag mit dem Wechsel zwischen Tabs.

Didits Transaction Monitoring API liefert den gesamten Workflow in einem Produkt. Wenn eine Regel ausgelöst wird, öffnet sich eine Warnmeldung; Warnmeldungen werden zu Fällen zusammengefasst; Analysten werden zugewiesen; und die SAR wird über dieselbe Konsole eingereicht, über die die Warnmeldung ausgelöst wurde. Es gibt kein separates Falltool, das lizenziert, integriert oder abgestimmt werden muss – und die Transaktionen, die es speisen, kosten jeweils 0,02 $.

Dieser Leitfaden führt den Workflow von einer ausgelösten Regel bis zu einer eingereichten SAR durch.

Wichtige Erkenntnisse

  • Warnmeldungen öffnen sich automatisch, wenn eine Regel ausgelöst wird, und durchlaufen einen definierten Lebenszyklus: OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED, DISMISSED.
  • Fälle gruppieren verwandte Warnmeldungen, tragen Priorität und Schweregrad und verfolgen eine Untersuchung durch OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD und RESOLVED.
  • Analysten werden Warnmeldungen und Fällen zugewiesen, sodass Eigentum und Leistung messbar sind.
  • Die SAR-Einreichung befindet sich in derselben Konsole wie die Warnmeldung – kein Export in ein separates Tool, keine neu eingegebenen Daten.
  • Der Pfad AWAITING_USER ermöglicht es einem Analysten, eine Warnmeldung zur Behebung an den Benutzer zurückzuschicken, anstatt sie manuell zu lösen.
  • 0,02 $ pro Transaktion, keine Mindestbeträge. Die AML-Prüfung einer markierten Partei wird separat mit 0,20 $ berechnet.

Was der Fallmanagement-Workflow leistet

Transaktionsüberwachung erzeugt Signale; Fallmanagement wandelt diese in verteidigungsfähige Entscheidungen um. Jede Warnmeldung in Didit trägt eine Quelle – regelbasiert, anbieterbasiert oder vom Analysten erstellt – und einen Status, der ihre Position in der Untersuchung widerspiegelt. Ein Analyst öffnet die Warnmeldung, prüft die Transaktion und die ausgelösten Regeln und entscheidet: als Fehlalarm abweisen, lösen, in einen Fall eskalieren, an den Benutzer zurückschicken oder in Richtung einer SAR bewegen.

Fälle sind der Container für alles, was größer ist als eine einzelne Warnmeldung. Mehrere Warnmeldungen für denselben Benutzer – ein Geschwindigkeitshöchststand am Montag, ein Treffer einer sanktionierten Gegenpartei am Mittwoch – werden zu einem Fall zusammengefasst, der das Gesamtbild mit eigener Priorität und Schweregrad enthält. Der Fall ist das, woran ein Ermittler arbeitet, und der Fall dokumentiert die Entscheidung des Unternehmens.

Warum es wichtig ist

Regulierungsbehörden erwarten nicht nur, dass Sie verdächtige Aktivitäten erkennen – sie erwarten, dass Sie diese untersuchen und melden und eine saubere Audit-Trail aufzeigen, wie Sie von der Warnmeldung zur Entscheidung gelangt sind. Ein fragmentierter Stack arbeitet in jeder Hinsicht gegen Sie. Das erneute Eingeben von Daten zwischen einem Überwachungsanbieter und einem Falltool führt zu Fehlern. Ein SAR-Prozess in einer Tabelle ist unmöglich zu prüfen und langsam zu verteidigen. Und jede Integrationsnaht ist ein Ort, an dem eine Warnmeldung verloren gehen kann.

Die Zusammenführung des Stacks in einem Produkt behebt das operative und das regulatorische Problem gleichzeitig. Die Warnmeldung, die Untersuchung, der Analyst, der sie verantwortet hat, und die SAR leben alle im selben Datensatz. Die Audit-Trail ist kontinuierlich, weil nichts das System verlässt. Und die Kosten skalieren mit Transaktionen, nicht mit Pro-Sitz-Lizenzen für ein Falltool, das Sie auch warten müssen.

Technische Details

Wenn eine Regel bei einer Transaktion ausgelöst wird, enthält die Antwort den Status und eine alert_id:

{
  "transaction_id": "txn_3c81f0",
  "status": "IN_REVIEW",
  "risk_score": 64,
  "triggered_rules": [
    { "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_77a920"
}

Die Transaktion selbst wird über die vereinheitlichte /v3/ API erstellt, idempotent auf einer von Ihnen kontrollierten transaction_id:

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_3c81f0",
    "category": "finance",
    "amount": 24000,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T14:50:00Z",
    "subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
  }'

Warnmeldungsstatus. OPENINVESTIGATING → (AWAITING_USER) → PENDING_SARSAR_FILED, oder endet bei RESOLVED oder DISMISSED.

Fallstatus. OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, RESOLVED.

Webhooks. Abonnieren Sie transaction.created und transaction.status.updated, damit Ihre Systeme synchron bleiben, wenn ein Analyst eine Warnmeldung durch den Workflow bewegt.

Preis. 0,02 $ pro Transaktion. AML-Prüfung einer markierten Partei während einer Untersuchung wird separat mit 0,20 $ berechnet.

Von der Warnmeldung zur eingereichten SAR

  1. Warnmeldung öffnet sich. Eine Regel wird ausgelöst, die Transaktion geht in den Status IN_REVIEW, und eine Warnmeldung öffnet sich im Status OPEN mit den ausgelösten Regeln.
  2. Analyst nimmt sie auf. Die Warnmeldung wechselt zu INVESTIGATING und wird einem Analysten zugewiesen, der die Transaktionshistorie, den Geschwindigkeitskontext und alle AML-Screenings prüft.
  3. Eskalieren oder beheben. Der Analyst gruppiert verwandte Warnmeldungen in einem Fall oder verschiebt die Warnmeldung auf AWAITING_USER, damit der Kunde sie mit einem Nachweis der Mittel oder einer erneuten Überprüfung klären kann.
  4. Entscheidung über eine SAR. Wenn die Aktivität eine Meldung rechtfertigt, wechselt die Warnmeldung zu PENDING_SAR, die SAR wird in derselben Konsole erstellt, und bei der Einreichung wechselt die Warnmeldung zu SAR_FILED.
  5. Abschluss. Warnmeldungen, die keine Maßnahmen erfordern, werden als DISMISSED (Fehlalarm) oder RESOLVED geschlossen. Die gesamte Spur – wer was wann entschieden hat – bleibt im Datensatz erhalten.

Da Warnmeldungen in den Status AWAITING_USER wechseln können, teilen sich die Untersuchung und die automatische Behebungsschleife dieselbe Oberfläche: Ein Analyst kann eine grenzwertige Warnmeldung an den Benutzer zurückgeben, anstatt Zeit damit zu verbrennen, und die Warnmeldung wird automatisch fortgesetzt, sobald der Benutzer antwortet.

Anwendungsfälle

  • Fintech – Gruppieren Sie Geschwindigkeits-, Strukturierungs- und Sanktionswarnmeldungen auf einem einzelnen Konto in einem Fall, bevor Sie über eine SAR entscheiden.
  • Krypto – Untersuchen Sie Warnmeldungen, die durch Wallet-Screening-Exposition zusammen mit On-Chain-Geschwindigkeit in derselben Falldatei ausgelöst wurden.
  • Kreditvergabe – Bearbeiten Sie Betrugsmuster-Warnmeldungen (Mule, synthetische Identität) bis zu einer dokumentierten Entscheidung ohne ein zweites Tool.
  • Marktplätze – Konsolidieren Sie Warnmeldungen zu Rückerstattungsmissbrauch und Rückbuchungen bei einem Verkäufer in einem Fall, dann reichen Sie ein oder lehnen Sie ab.
  • iGaming – Verwalten Sie Warnmeldungen zu verantwortungsvollem Spielen und AML in einem Workflow, mit Analystenverantwortung und einer Audit-Trail.

Integration mit Didit

  1. Aktivieren Sie Ihre Pakete. Aktivieren Sie in der Business Console die Regelpakete, die zu Ihrem Unternehmen passen, damit Warnmeldungen für die richtigen Typologien geöffnet werden.
  2. Senden Sie Transaktionen. POST /v3/transactions/, wenn Geld bewegt wird, mit einer stabilen transaction_id und vendor_data, die jede mit ihrem Benutzer oder ihrer Entität verknüpfen.
  3. Bearbeiten Sie Warnmeldungen in der Konsole. Untersuchen, Analysten zuweisen, Warnmeldungen zu Fällen gruppieren und SARs einreichen – alles von derselben Oberfläche aus.
  4. Synchronisieren Sie mit Webhooks. Hören Sie auf transaction.status.updated, damit Ihre eigenen Systeme Änderungen des Warnmeldungs- und Fallstatus widerspiegeln.

Da alles über die vereinheitlichte /v3/ API läuft, kann eine KYB-Sitzung die KYC-Sitzungen für ihre UBOs generieren, diese Benutzer fließen in die Transaktionsüberwachung ein, und eine markierte Transaktion kann eine KYC-Remediation auslösen – eine Identitäts- und Betrugsplattform, End-to-End.

Häufig gestellte Fragen

Benötige ich ein separates Fallmanagement-Tool?

Nein. Warnmeldungen, Fälle, Analystenzuweisung, Untersuchungsstatus und SAR-Einreichung sind in dasselbe Produkt und dieselbe Konsole integriert.

Welche Zustände durchläuft eine Warnmeldung?

OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED und DISMISSED. Fälle durchlaufen OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD und RESOLVED.

Kann ich Warnmeldungen bestimmten Analysten zuweisen?

Ja. Warnmeldungen und Fälle werden Analysten zugewiesen, sodass die Verantwortlichkeit klar ist und die Leistung messbar ist.

Wo wird die SAR eingereicht?

In derselben Konsole, in der die Warnmeldung ausgelöst wurde. Es gibt keinen Export in ein separates Tool und keine neu eingegebenen Daten, was die Audit-Trail kontinuierlich hält.

Was kostet es?

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

Bereit zum Start?

Lesen Sie die Übersicht zur Transaktionsüberwachung in den Docs, sehen Sie, wie sie zum Rest der Plattform auf der Produktdetailseite zur Transaktionsüberwachung passt, und überprüfen Sie die transparenten Preise pro Anruf 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 Anruf.

Infrastruktur für Identität und Betrugsprävention.

Eine API für KYC, KYB, Transaktionsüberwachung und Wallet-Screening. In 5 Minuten integriert.

Lass dir diese Seite von einer KI zusammenfassen
SAR-Workflow & Fallmanagement, integriert | Didit.