Zum Hauptinhalt springen
DELETE

KYC- und KYB-Unterstützung

Funktioniert sowohl für Sitzungen der Benutzerverifizierung (KYC) als auch der Unternehmensverifizierung (KYB). Die session_id wird für beide Sitzungstypen aufgelöst; für beide gilt dasselbe Löschverhalten. Die Aufbewahrung biometrischer Templates gilt nur für KYC-Sitzungen, da nur KYC-Sitzungen ein Gesichts-Embedding enthalten.

Verhalten

  • Die Sitzung wird zusammen mit jedem darin enthaltenen Verifizierungsversuch gelöscht, einschließlich der Ergebnisse, die durch eine erneute Einreichung ersetzt wurden: ihre Entscheidung, ihre extrahierten Daten, ihre zugehörigen Funktionsdatensätze (Ausweisverifizierungen, Registerprüfungen, Dokumente, AML, IP-Analyse usw.), ihre Prüfungen und das Aktivitätsprotokoll sowie alle ihre gespeicherten Dateien.
  • Das Löschen einer Sitzung der Unternehmensverifizierung (KYB) löscht auch die Verifizierungen, die sie für ihre Schlüsselpersonen (KYC) und ihre Unternehmenseigentümer (KYB) erstellt hat, und zwar rekursiv. Die Antwort gibt in deleted_child_verifications an, wie viele dies sind. Eine Verifizierung, auf die sie lediglich verlinkt, wie etwa ein bestehendes, genehmigtes KYC, das wiederverwendet wurde, wird nicht gelöscht.
  • E-Signatur-Daten werden mitgelöscht: die zu unterzeichnenden Dokumente und ihre ursprünglichen Word-Dateien, die signierten PDFs, die Nachweis-PDFs, die Signaturbilder und jeder Feldwert. Ihre Download-Pfade geben 404 zurück.
  • Die Sitzung verschwindet sofort aus Listen- und Entscheidungsantworten, und Medien-URLs, die vor dem Aufruf ausgestellt wurden, lassen sich nicht mehr auflösen.
  • Webhook-Zustellungen, die sich noch in der Warteschlange für die Sitzung befinden, sowie deren Wiederholungsversuche werden verworfen.
  • Die laufende AML-Überwachung und die KYB-Registerüberwachung, die durch die gelöschten Verifizierungen gestartet wurden, werden beendet.
  • Die Löschung ist dauerhaft und unwiderruflich. Es gibt keinen Wiederherstellungs-Endpoint; exportieren Sie daher alles, was Sie benötigen, wie etwa ein Entscheidungs-PDF, bevor Sie ihn aufrufen.
  • Die Antwort ist 200 OK und wird gesendet, sobald die Löschung abgeschlossen ist, mit einem JSON-Body, der angibt, was mit den biometrischen Gesichtsdaten der Sitzung geschehen ist. Siehe Migration, falls Ihr Client noch 204 erwartet.

Daten in einem finalisierten aufsichtsrechtlichen Bericht

Ist die Sitzung Teil eines Falls mit einem finalisierten aufsichtsrechtlichen Bericht, gibt die Anfrage 409 zurück und es wird nichts gelöscht. Die Antwort verwendet code: in_filed_report und nennt jeden Bericht:
Löschen Sie jeden Bericht mit Bericht löschen und wiederholen Sie anschließend den Löschvorgang. Das Löschen des Berichts löscht nicht die Sitzung; die Sitzung bleibt bestehen, bis Sie diesen Endpoint erneut aufrufen.

Biometrische Gesichtsdaten: löschen oder aufbewahren

Jede KYC-Sitzung mit einem Liveness-Selfie enthält ein Gesichts-Embedding, das die Gesichtssuche 1:N und die Duplikaterkennung unterstützt. Standardmäßig wird dieses Embedding zusammen mit der Sitzung gelöscht (face_retention_policy: delete_with_session), sodass sich eine Person, deren Sitzung Sie gelöscht haben, erneut verifizieren kann, ohne als Duplikat markiert zu werden. Anwendungen, bei denen die Duplikaterkennung auch nach dem Löschen der Sitzung erhalten bleiben muss, können die Aufbewahrung biometrischer Templates aktivieren. Didit löscht dann wie gewohnt die Sitzung und alle zugehörigen Daten und behält ein separat verwaltetes, bildfreies biometrisches Template bei, das an den Benutzer der Sitzung gebunden ist.
Ein aufbewahrtes biometrisches Template stellt biometrische Daten dar. Es ist weder anonym noch flüchtig und wird nicht zusammen mit der Sitzung gelöscht. Es bleibt bis zu seinem geplanten Ablauf, einer früheren Frist nach geltendem Recht, der Löschung des Benutzers, einer datenschutzrechtlichen Löschanfrage oder einer expliziten Bereinigung bestehen. Aktivieren Sie die Aufbewahrung nur, wenn die Weisung des Verantwortlichen und Ihre Datenschutzerklärung dies abdecken.
Was ein aufbewahrtes Template enthält und was nicht: Die Aufbewahrung wird an drei Stellen konfiguriert, von der allgemeinsten bis zur spezifischsten:
  1. Anwendungsrichtlinie in Business Console → App Settings → Data retention oder über PATCH /v3/webhook/ (face_retention_policy, face_retention_days). Siehe Datenaufbewahrung.
  2. Überschreibung pro Aufruf mit retain_face_embeddings an diesem Endpoint und bei Sitzungen stapelweise löschen.
  3. Anweisungsklasse mit deletion_instruction. Eine privacy_erasure-Anweisung hat immer Vorrang: Sie bereinigt jedes aufbewahrte Template für diesen Benutzer und behält niemals ein neues auf.

Request-Body

Alle Felder sind optional. Lassen Sie den Body weg, um der Anwendungsrichtlinie zu folgen.

Antwort

Die Antwort bestätigt, dass Didit Ihre Löschanweisung akzeptiert und angewendet hat. Sie stellt kein Löschzertifikat dar: Bewahren Sie die instruction_id in Ihrem eigenen Löschprotokoll auf, um den Audit-Trail später abgleichen zu können.

Aufbewahrungsdauer und Ablauf

Jedes aufbewahrte Template hat einen zeitlich begrenzten Ablaufzeitpunkt in expires_at. Didit setzt diesen auf den frühesten der folgenden Zeitpunkte:
  1. face_retention_days aus der Anfrage oder face_retention_days der Anwendung, wenn die Anfrage diesen Wert weglässt;
  2. das allgemeine Datenaufbewahrungsfenster der Anwendung, sofern eines konfiguriert ist;
  3. face_retention_deadline aus der Anfrage, sofern angegeben.
Eine Anfrage, die ein Template ohne endliche Dauer aufbewahren würde, wird mit 400 abgewiesen und es wird nichts gelöscht. Aufbewahrte Templates dürfen die früheste geltende Kundenanweisung, das Zweckende, den konfigurierten Ablauf, die auf die betroffene Person bezogene Löschanweisung oder die gesetzliche Frist für biometrische Daten nicht überdauern. Sie sind dafür verantwortlich, eine Dauer zu wählen, die den für Ihre Benutzer geltenden Gesetzen entspricht; wählen Sie eine kürzere Dauer, wann immer eine anwendbare Vorschrift dies erfordert.

Datenschutzrechtliche Löschung

Senden Sie deletion_instruction: "privacy_erasure", wenn Sie einer Anfrage einer betroffenen Person nachkommen. Didit löscht jedes gespeicherte biometrische Template, das an den Benutzer der Sitzung gebunden ist, und löscht anschließend die Sitzung sowie deren Embedding. Die Aufbewahrungsrichtlinie der Anwendung kann eine Anweisung zur Datenschutzlöschung nicht überschreiben, und retain_face_embeddings: true wird mit 400 abgelehnt. Das Löschen des Benutzers mit Batch Delete Users löscht ebenfalls seine gespeicherten Templates.

Was nicht betroffen ist

Das Löschen einer Sitzung bereinigt diese Daten nicht automatisch. Wenn Sie eine Anfrage auf Löschung bearbeiten, müssen Sie diese separat berücksichtigen.
  • Sperrlisteneinträge, die aus der Sitzung erstellt wurden (Gesicht oder Dokument), bleiben bestehen. Entfernen Sie diese aus der Sperrliste. Ein Gesichts-Sperrlisteneintrag behält seinen eigenen biometrischen Eintrag, unabhängig von jedem gespeicherten Template.
  • Bereits für die Sitzung ausgestellte Share-Token werden nicht widerrufen, aber es gibt für sie nichts mehr zu importieren: Ein Import mit einem solchen Token gibt 400 mit {"share_token": ["Original session does not exist."]} zurück.
  • Bereits für die Sitzung zugestellte Webhooks sind nicht betroffen. Zustellungen, die sich noch in der Warteschlange befinden, sowie deren Wiederholungsversuche werden verworfen. Für die Löschung selbst wird kein Webhook ausgelöst.
  • Bereits durch die Verifizierung verbrauchte Credits werden nicht zurückerstattet.
  • Unterzeichnete Kopien, die bereits per E-Mail durch einen E-Signatur-Schritt an einen Unterzeichner gesendet wurden, verbleiben im Postfach des Unterzeichners und sind nicht betroffen.
  • Die übergeordnete Entität Benutzer oder Unternehmen wird nicht gelöscht. Verwenden Sie dafür Delete Users oder Delete Businesses. Wenn das Profilporträt des Benutzers aus der gelöschten Sitzung stammte, wird das Porträt entfernt.
  • Ein gespeichertes biometrisches Template (nur, wenn Sie sich dafür entschieden haben) bleibt bestehen, bis es abläuft oder Sie es löschen. Löschen Sie es mit der Biometric Templates API, indem Sie den Benutzer löschen oder indem Sie die Löschung einer anderen Sitzung desselben Benutzers mit deletion_instruction: "privacy_erasure" wiederholen.

Beispiele

Antwort bei einer Anwendung, die sich nicht dafür entschieden hat:

Fehler

Bei 400 wird nichts gelöscht. Bei 503 bleibt die Sitzung bestehen: Wiederholen Sie dieselbe Anfrage, bis sie 200 zurückgibt. Einige ihrer gespeicherten Dateien oder ihr Gesichts-Embedding sind möglicherweise bereits gelöscht, verlassen Sie sich daher nach einem 503 nicht mehr darauf.

Berechtigung

Erfordert delete:sessions. Dieselbe Berechtigung gilt sowohl für Sitzungen der Benutzerverifizierung (KYC) als auch der Unternehmensverifizierung (KYB) sowie für das Überschreiben der Aufbewahrung.

Batch-Löschung

Für Massenoperationen auf KYC-Sitzungen verwenden Sie POST /v3/sessions/delete/. Dieser Endpoint akzeptiert dieselben Aufbewahrungs- und Anweisungsfelder. Bis zu 20 übereinstimmende Sitzungen werden in der Anfrage mit einem Ergebnis pro Sitzung gelöscht; darüber hinausgehende werden als Löschauftrag ausgeführt. Siehe Batch Delete Sessions.

Migration von 204-Antworten

Bis zu dieser Version gab der Endpoint 204 No Content zurück. Er gibt jetzt 200 OK mit dem oben dokumentierten JSON-Body zurück, sodass jede Löschung ihr face_retention_outcome meldet. Aktualisieren Sie Clients, die auf 204 prüfen. Das Standardverhalten bleibt unverändert: Bestehende Anwendungen verbleiben auf delete_with_session, und keine Migration aktiviert die Aufbewahrung automatisch für Sie. Aktivieren Sie sie explizit in der Konsole oder über PATCH /v3/webhook/.

Ähnliche Themen

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.

Pfadparameter

sessionId
string<uuid>
erforderlich

UUID (session_id) der zu löschenden Sitzung der Benutzerverifizierung (KYC) oder Unternehmensverifizierung (KYB), wie sie bei der Sitzungserstellung zurückgegeben wurde. Muss eine kanonische UUID mit Bindestrichen sein — ein Wert, der keine UUID ist, stimmt nicht mit der Route überein und gibt 404 zurück.

Beispiel:

"11111111-2222-3333-4444-555555555555"

Body

application/json

Optional. Lassen Sie den Payload vollständig weg, um die Datenaufbewahrungsrichtlinie der Anwendung durch eine operative Löschung zu befolgen.

retain_face_embeddings
boolean | null

Überschreibt die face_retention_policy der Anwendung für diese Löschung. true behält ein bildfreies biometrisches Gesichts-Template, das dem Benutzer der Sitzung zugeordnet ist, bei, nachdem die Sitzung gelöscht wurde; false löscht das Gesichts-Embedding mit der Sitzung; weglassen oder null, um der Richtlinie der Anwendung zu folgen. Wird für KYB-Sitzungen und für Sitzungen ohne Gesichts-Embedding ignoriert.

Beispiel:

true

face_retention_days
integer

Endliche Aufbewahrungsdauer in Tagen für ein aufbewahrtes Template. Erforderlich, wenn ein Template aufbewahrt wird, es sei denn, die Anwendung legt bereits face_retention_days fest. Das expires_at des Templates wird durch den frühesten der folgenden Zeitpunkte bestimmt: diese Dauer, der allgemeine Datenaufbewahrungszeitraum der Anwendung und face_retention_deadline.

Erforderlicher Bereich: 1 <= x <= 3650
Beispiel:

365

face_retention_deadline
string<date-time>

Optionaler fester Ablaufzeitpunkt für ein aufbewahrtes Template. Muss in der Zukunft liegen.

Beispiel:

"2027-08-28T00:00:00Z"

deletion_instruction
enum<string>
Standard:operational_session_delete

Die Art der Anweisung, die Sie erteilen. operational_session_delete löscht die Sitzung und behält ein Template nur dann bei, wenn die Richtlinie oder retain_face_embeddings dies vorschreibt. privacy_erasure löscht jedes beibehaltene biometrische Template, das mit dem Benutzer der Sitzung verknüpft ist, bevor die Sitzung gelöscht wird, kann nicht durch die Anwendungsrichtlinie überschrieben werden und kann nicht mit retain_face_embeddings: true kombiniert werden (400).

Verfügbare Optionen:
operational_session_delete,
privacy_erasure
Beispiel:

"operational_session_delete"

instruction_id
string

Ihre dauerhafte Referenz für diese Löschanweisung (beispielsweise die ID eines Löschtickets). Wird im Audit-Log und auf jedem aufbewahrten Template erfasst. Wird von Didit generiert, wenn sie weggelassen wird.

Maximum string length: 255
Beispiel:

"dsar-2026-0142"

Antwort

Sitzung gelöscht. Der Body gibt an, was mit den Gesichtsbiometriedaten der Sitzung geschehen ist und bei einer KYB-Sitzung, wie viele von ihr erstellte Verifizierungen zusammen mit ihr gelöscht wurden.

session_id
string<uuid>

Die gelöschte Sitzung.

session_number
integer | null

Die Nummer der gelöschten Sitzung.

face_retention_outcome
enum<string>

Was mit den biometrischen Gesichtsdaten der Sitzung passiert ist. deleted: Das Gesichts-Embedding wurde mit der Sitzung gelöscht (Standard). retained_with_user: Die Sitzung wird gelöscht und ein bildfreies biometrisches Template bleibt beim Benutzer verankert; siehe biometric_template_uuid. none: Die Sitzung hatte kein Gesichts-Embedding (beispielsweise eine KYB-Sitzung oder eine KYC-Sitzung ohne Liveness-Selfie). ineligible_no_vendor_user: Die Aufbewahrung wurde angefordert, aber die Sitzung hat keinen verknüpften Benutzer, daher wurde das Embedding mit der Sitzung gelöscht. Ein Fehler des biometrischen Speichers wird über dieses Feld an diesem Endpoint niemals gemeldet: Er gibt 503 zurück und die Sitzung wird nicht gelöscht.

Verfügbare Optionen:
retained_with_user,
deleted,
none,
ineligible_no_vendor_user
biometric_template_uuid
string<uuid> | null

ID des aufbewahrten biometrischen Templates, wenn face_retention_outcome gleich retained_with_user ist; andernfalls null. Verwalten Sie es über /v3/biometric-templates/{template_uuid}/.

biometric_template_expires_at
string<date-time> | null

Wann das aufbewahrte biometrische Template gelöscht wird, wenn face_retention_outcome auf retained_with_user steht; null, wenn kein Template aufbewahrt wird.

deleted_child_verifications
integer

Für eine Unternehmensverifizierungs-Sitzung (KYB): wie viele der von ihr erstellten Verifizierungen (die KYC-Sitzungen ihrer Schlüsselpersonen und die KYB-Sitzungen ihrer Unternehmenseigentümer, rekursiv) zusammen mit ihr gelöscht wurden. Bei einer KYC-Sitzung immer 0.

Zuletzt geändert am 7. November 2026