Zum Hauptinhalt springen

Übersicht

Das AML-Screening gleicht die Identität der verifizierten Person mit globalen Datensätzen zu Sanktionen, PEPs, Beobachtungslisten und negativen Medienberichten ab. Jeder Treffer liefert die übereinstimmende Entität, die Datensätze, die den Treffer erzeugt haben, zwei Scores – match_score (Identitätskonfidenz) und risk_score (Entitätsrisiko) – sowie eine strukturierte Aufschlüsselung nach Quelle (pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[]). Der aggregierte score ist der höchste risk_score unter den Treffern, die nicht als False Positive markiert sind. Die gleiche Struktur wird beim AML-Screening in Benutzersitzungen (KYC), Unternehmenssitzungen (KYB) und der Standalone-AML-API zurückgegeben.
Screenshot des Didit-AML-Screening-Berichts mit Treffern zu Sanktionen, PEP und negativen Medienberichten

Wo es in API-Antworten erscheint

Am Sitzungsentscheidungs-Endpoint wird das AML-Screening als Array aml_screenings[] zurückgegeben. Jeder Eintrag entspricht einer AML-Ausführung im Workflow (eine AML-Prüfung, die zweimal ausgeführt wird, erzeugt zwei Einträge mit unterschiedlichen node_id-Werten).
Standalone-AML- und Unternehmenssitzungen geben dieselbe Struktur pro Datensatz zurück. Die nachstehenden Felder spiegeln das kanonische Schema auf der Seite Datenmodelle wider.

Drei Scores, kein einzelnes Urteil

Der status ist eine Entscheidung; die Zahlen, aus denen er abgeleitet wurde, befinden sich in derselben Payload. Berücksichtigen Sie sie, wenn Sie Ihre eigene Risikostufung aufbauen (z. B. die Kombination von AML-Risiko mit Fragebogenantworten wie Vermögensherkunft oder PEP-Selbsterklärung), anstatt nur nach Approved / In Review / Declined zu verzweigen: Alle drei sind an jeder Stelle vorhanden, an der der AML-Bericht bereitgestellt wird: GET /v3/session/{sessionId}/decision/, das decision-Objekt von status.updated- und data.updated-Webhooks in jeder Webhook-Version (V3 aml_screenings[] sowie das ältere singuläre aml in V2 / V1) und der Standalone-AML-API. Ein Consumer, der nur eine Kennzeichnung wie markiert / unbedenklich sieht, liest status (oder den review_status eines Treffers) und überspringt die Scores daneben. Die Konsole zeigt dieselben Zahlen: Der Header des AML-Abschnitts enthält den aggregierten Risiko-Score, und jede Zeile der Treffertabelle enthält Übereinstimmungswert und Risiko-Score mit einer Aufschlüsselung, die beim Darüberfahren mit der Maus angezeigt wird.

Schema

Das kanonische Schema finden Sie unter AML-Screening in der Referenz zu den Datenmodellen. Felder auf oberster Ebene:

Felder pro Treffer

Jeder Eintrag in hits[] enthält die folgenden Felder (Auszug dargestellt). Quellarrays für die Übereinstimmung — pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[] — werden nur für den Datensatz bzw. die Datensätze befüllt, zu denen der Treffer gehört.
Treffer, die als False Positive klassifiziert wurden (weil der match_score unter den Schwellenwert für den Übereinstimmungswert fiel oder weil ein Prüfer sie so markiert hat), verbleiben aus Gründen der Prüfbarkeit in hits[]. Sie werden lediglich von der Berechnung des aggregierten score ausgeschlossen.

Laufende Überwachung

Wenn is_ongoing_monitoring_enabled auf true gesetzt ist, führt Didit kontinuierlich ein erneutes Screening der Person durch und gibt den AML-Bericht jedes Mal neu aus, wenn ein Treffer hinzugefügt, entfernt oder geändert wird. Erneute Screenings, die den AML-Status ändern, lösen einen status.updated-Webhook aus; erneute Screenings, die lediglich Trefferdaten ändern, lösen data.updated aus. Das Überwachungsfenster läuft ab last_aml_bill_date für 365 Tage; next_ongoing_monitoring_bill_date gibt an, wann die nächste jährliche Verlängerung ansteht. Diese Signale sind alle änderungsgesteuert, sodass eine über Monate hinweg ohne neue Treffer erneut gescreente Person keines davon auslöst. last_ongoing_screening_at ist das einzige Feld, das sich bei jedem abgeschlossenen Durchlauf ändert, und der Screening-History-Endpoint führt jeden Durchlauf einzeln auf – einschließlich derjenigen, die nichts geändert haben. Den vollständigen Lebenszyklus finden Sie unter Laufende AML-Überwachung.
Drei Datumsangaben in diesem Bericht bedeuten drei unterschiedliche Dinge. next_ongoing_monitoring_bill_date gibt an, wann die nächste Abrechnung erfolgt. last_ongoing_screening_at ist der Zeitpunkt, zu dem die Person tatsächlich zuletzt gescreent wurde. last_ongoing_screening_datasets_updated_at gibt an, wann die Listen hinter diesem Screening zuletzt durch den Anbieter aktualisiert wurden. Nur die zweite Angabe belegt, dass die Kontrolle ausgeführt wurde.

Statuswerte

Die Schwellenwerte sind pro Workflow-Knoten konfigurierbar – siehe AML-Risiko-Score. Benutzerdefinierte Statusregeln werden mit dem abgeleiteten Status gemäß der Rangfolge Declined > In Review > Approved kombiniert; Prüfer können den AML-Status auch über die Konsole oder den AML-Status-Endpoint überschreiben.

Beispiele

Approved – keine Treffer

In Review – PEP + Treffer zu negativen Medienberichten

Alle nachfolgenden Namen, URLs und Artikel sind frei erfunden.

Verwandte Themen

Zuletzt geändert am 7. November 2026