Zum Hauptinhalt springen
POST
curl

Überblick

Aktiviert oder deaktiviert die laufende AML-Überwachung für die ausgewählten Benutzer-Entitäten, genau wie die Aktion Laufende AML-Überwachung in der Business Console. Die Console und dieser Endpoint führen dieselbe zugrunde liegende Operation aus, daher sind die Regeln, die Abrechnung und die Ergebnisse identisch. Senden Sie zuerst estimate_only: true, um zu sehen, wie viele Benutzer ausgewählt sind, wie viele ein neues AML-Screening benötigen, welche einmaligen Kosten das Screening verursacht und welche jährlichen Kosten das Monitoring verursacht. Ein Probelauf nimmt keine Änderungen vor.

Wann verwenden

  • Programmatisches Onboarding: Aktivieren Sie das Monitoring für Benutzer, die Sie über die API importiert oder angelegt haben, ohne sie manuell erneut zu prüfen.
  • Offboarding: Beenden Sie das Monitoring und dessen jährliche Verlängerung für Benutzer, die Ihre Plattform verlassen haben.
  • Kostenkontrolle: Prüfen Sie die genauen Kostenauswirkungen einer Auswahl, bevor Sie sie ausführen.

So wird eine Auswahl verarbeitet

  • Ein überwachtes Screening pro Benutzer. Ein Benutzer, der sich mehrfach verifiziert hat, wird nur einmal überwacht und einmal abgerechnet. Das Deaktivieren schaltet das Monitoring für alle Screenings dieses Benutzers aus.
  • Benutzer ohne AML-Screening werden zuerst geprüft. Didit legt für sie eine neue AML-Verifizierung an (sichtbar im Tab Verifizierungen des Benutzers), rechnet sie wie ein reguläres AML-Screening ab und aktiviert das Monitoring darauf. Dafür werden der vollständige Name, das Geburtsdatum und das Land des Benutzers benötigt. Fehlt eine dieser Angaben, wird der Benutzer als skipped_no_identity_data gemeldet und nicht stillschweigend übergangen.
  • Gesperrte Benutzer werden übersprungen (skipped_blocked). Sandbox-Anwendungen erzeugen niemals Screenings (skipped_sandbox).
  • Das Guthaben wird vorab geprüft. Die Aktivierung wird mit 403 abgelehnt, wenn Ihr Guthaben die Schätzung nicht deckt. Die Antwort enthält die Schätzung, sodass Sie wissen, wie viel Sie aufladen müssen.
  • Jährliche Verlängerung. Einem neu überwachten Benutzer wird der jährliche Monitoring-Preis zu seinem nächsten Verlängerungsdatum berechnet. Dieses Datum zeigt die Console in der Spalte Laufende AML-Überwachung. Das Deaktivieren beendet die Verlängerung, erstattet aber keinen bereits abgerechneten Zeitraum.

Auswahl und Batch-Größe

Wählen Sie Benutzer über vendor_data_list, didit_internal_id_list oder beide Listen aus. Die beiden Listen werden mit „ODER“ verknüpft. Eine Anfrage akzeptiert insgesamt höchstens 1000 Kennungen aus beiden Listen. Kennungen, zu denen in Ihrer Anwendung kein Benutzer existiert, werden unverändert unter unmatched zurückgegeben. Sie führen nie zu einem Fehler der Anfrage: Eine Auswahl ohne Treffer wird als leerer Job abgeschlossen (total: 0), wobei alle Kennungen aufgeführt werden. Das entspricht der Konvention der Batch-Delete-Endpoints.

Synchron oder im Hintergrund

Auswahlen mit 20 Benutzern oder weniger werden synchron verarbeitet. Der Aufruf liefert 200 mit dem abgeschlossenen Job. Größere Auswahlen liefern 202 mit einem Job im Status PENDING. Fragen Sie Job für AML-Monitoring abrufen ab, bis status den Wert COMPLETED oder FAILED hat. In beiden Fällen enthält der Job pro Benutzer einen Eintrag in results mit dessen outcome.

Webhooks

Das Umschalten des Monitorings sendet keinen eigenen Webhook. Sobald das Monitoring aktiv ist, lösen erneute Prüfungen die üblichen Ereignisse status.updated und data.updated aus, die unter Kontinuierliches AML-Monitoring beschrieben sind.

Berechtigungen

Jeder aktive API-Schlüssel der Anwendung kann diesen Endpoint aufrufen. Didit-API-Schlüssel sind anwendungsbezogen, nicht rollenbezogen. Die Rollen und Berechtigungen der Console legen fest, was eine Person in der Console tun darf. Für Datenverkehr der Management API werden sie nicht ausgewertet.

Verwandte Seiten

Autorisierungen

x-api-key
string
header
erforderlich

Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys.

Body

application/json

Wählen Sie Benutzer mit vendor_data_list, didit_internal_id_list oder beiden aus (die beiden Listen werden ODER-verknüpft). Maximal 1000 IDs pro Anfrage über beide Listen hinweg.

is_enabled
boolean
erforderlich

true, um die Überwachung zu aktivieren, false, um sie zu deaktivieren.

estimate_only
boolean
Standard:false

Wenn true, wird die Kostenschätzung zurückgegeben und es werden keine Schreibvorgänge ausgeführt – kein Screening, keine Abrechnung, kein Job.

vendor_data_list
string[]

Ihre eigenen Kennungen der umzuschaltenden Benutzer, exakt so abgeglichen wie übermittelt.

didit_internal_id_list
string<uuid>[]

Interne Didit-IDs der umzuschaltenden Benutzer – die von den Create-, Get- und List-Endpoints zurückgegebene didit_internal_id.

Antwort

Die Schätzung (wenn estimate_only true ist) oder der abgeschlossene Job für eine inline verarbeitete Auswahl.

Kostenvorschau. Wird direkt zurückgegeben, wenn estimate_only wahr ist (es wird nichts geschrieben).

users_total
integer
erforderlich

Profile, die der Auswahl entsprechen.

already_enabled
integer
erforderlich

Profile, die bereits überwacht werden (beim Aktivieren ist nichts zu tun; diese werden beim Deaktivieren abgeschaltet).

with_existing_aml
integer
erforderlich

Profile, deren bestehendes AML-Screening auf überwacht umgestellt wird (kein neues Screening).

needing_screening
integer
erforderlich

Profile ohne bisheriges AML-Screening, die zuerst gescreent werden (abgerechnet als reguläres AML-Screening).

skipped_no_identity_data
integer
erforderlich

Profile, die nicht gescreent werden können, da Identitätsdaten fehlen.

skipped_blocked
integer
erforderlich

Gesperrte Benutzer, die übersprungen werden (bei Unternehmen immer 0).

estimated_screening_cost_usd
number
erforderlich

Einmalige Kosten für die neuen Screenings.

Beispiel:

0.2

estimated_annual_monitoring_cost_usd
number
erforderlich

Jährliche Überwachungskosten für die Profile, die künftig überwacht werden.

Beispiel:

0.07

balance_sufficient
boolean
erforderlich

Gibt an, ob das Guthaben der Organisation das Screening plus das erste Jahr der Überwachung abdeckt.

unmatched
string[]
erforderlich

Kennungen der Anfrage, die mit keinem Profil in dieser Anwendung übereinstimmten, exakt wie gesendet.

Zuletzt geändert am 7. November 2026