Ü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.

Wo es in API-Antworten erscheint
Am Sitzungsentscheidungs-Endpoint wird das AML-Screening als Arrayaml_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).
Drei Scores, kein einzelnes Urteil
Derstatus 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 inhits[] 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
Wennis_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.
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
- AML-Warnungen – alle Warncodes, die AML ausgeben kann
- AML-Risiko-Score und AML-Übereinstimmungswert – wie die beiden Scores berechnet werden
- Laufende AML-Überwachung – Aktivieren und Verarbeiten von Überwachungsereignissen
- Beobachtungslisten-Datenbank – abgedeckte Datensätze
- Datenmodelle – AML-Screening – kanonisches Schema
- Webhooks –
status.updatedwird ausgelöst, wenn AML den Sitzungsstatus ändert; Änderungen des Prüfstatus von Treffern und Aktualisierungen der Überwachungsdaten lösendata.updatedaus