Zum Hauptinhalt springen
Gesichtsbiometrie ist für jede Benutzer-Entität zentral. Didit erfasst während der Liveness-Erkennung ein Gesicht, erzeugt ein Vektor-Embedding und speichert es für vier nachgelagerte Funktionen: 1:N-Gesichtssuche, Duplikaterkennung, Durchsetzung der Sperrliste und erneute biometrische Authentifizierung.
Gespeicherte Gesichter dienen zugleich als Referenz für die Biometrische Authentifizierung. Erstellen Sie eine Sitzung für die biometrische Authentifizierung mit den vendor_data des Benutzers und lassen portrait_image weg, dann verwendet Didit das gespeicherte Gesicht automatisch (zuerst das genehmigte Liveness-Gesicht, dann das Foto aus dem ePassport-Chip, dann das Porträt aus dem Ausweisdokument und zuletzt ein manuell hinterlegtes Profilgesicht).

Wie Gesichter einem Benutzer zugeordnet werden

1

Während der Liveness-Erkennung erfasst

Wenn ein Benutzer eine Sitzung mit aktivierter Liveness-Erkennung durchläuft, nimmt Didit ein Selfie auf, führt eine passive Liveness-Erkennung durch, extrahiert das größte Gesicht und erzeugt ein Vektor-Embedding für die Suche.
2

Im Benutzerprofil gespeichert

Das Gesicht wird mit der Sitzung und der übergeordneten Benutzer-Entität verknüpft. Die Porträt-URL wird im Benutzerprofil als portrait_image angezeigt.
3

Für die Suche indexiert

Das Embedding wird dem Suchindex hinzugefügt. Nachfolgende Sitzungen können 1:N-Suchen gegen diesen Index ausführen.

Gesichtssuche (1:N)

Mit der Gesichtssuche finden Sie einen Benutzer, indem Sie ein Bild hochladen und es mit allen registrierten Gesichtern in Ihrer Anwendung abgleichen. Anwendungsfälle:
  • Duplikaterkennung beim Onboarding: verhindern, dass dieselbe Person zwei Konten anlegt.
  • Umgekehrte Suche: den Benutzer hinter einem CCTV-Standbild oder einem Bild in einer Betrugsuntersuchung identifizieren.
  • Wiedererkennung von Bestandskunden: KYC für einen wiederkehrenden Kunden überspringen.
Die Gesichtssuche läuft automatisch bei neuen Sitzungen, wenn in Ihrem Workflow die Duplikaterkennung aktiviert ist. Sie steht außerdem als eigenständige API zur Verfügung:

Duplikaterkennung

Jedes neue Gesicht kann mit bereits registrierten Gesichtern verglichen werden, um Duplikate aufzudecken. Didit weist jedem Gesicht einen approved_duplicate_status zu: Workflows lassen sich so konfigurieren, dass sie:
  • Sitzungen mit Duplikat-Kennzeichnung automatisch ablehnen.
  • zur Prüfung markieren: an einen menschlichen Analysten weiterleiten.
  • nur warnen: die Sitzung zulassen, aber ein Risiko-Tag hinzufügen.
Konfigurieren Sie dies in der Konsole unter Workflows → [Ihr Workflow] → Face Match / Liveness → Duplicate detection.

Sperrliste für Gesichter

Wenn Sie eine Sitzung ablehnen, wird das Gesicht nicht in eine Sperrliste aufgenommen. Um künftige Sitzungen mit demselben Gesicht abzulehnen, sperren Sie es selbst: fügen Sie es über die Sperrlisten-Seite oder mit der Lists API hinzu. Eine neue Sitzung, deren Liveness-Selfie zu diesem Eintrag passt, wird automatisch abgelehnt.

Ein importiertes Gesicht einem Benutzerprofil hinzufügen

Wenn Sie von einem anderen KYC-Anbieter migrieren, können Sie zuerst den Benutzer anlegen und anschließend ein vertrauenswürdiges Gesichtsbild diesem Profil zuordnen. Der Benutzer wird weiterhin über Ihr vendor_data identifiziert, der Endpoint zum Hochladen des Gesichts verwendet jedoch die interne Benutzer-ID von Didit (didit_internal_id), damit das Ziel eindeutig ist.
1

Benutzer anlegen oder abrufen

Rufen Sie POST /v3/users/create/ mit Ihrem stabilen vendor_data auf oder rufen Sie GET /v3/users/{vendor_data}/ auf, wenn der Benutzer bereits existiert.
2

didit_internal_id auslesen

Die Benutzerantwort enthält didit_internal_id. Verwenden Sie in Ihrem eigenen System weiterhin vendor_data; verwenden Sie didit_internal_id nur für die Endpoints zum Anhängen an Profile.
Importierte Profilgesichter werden in denselben Gesichtsindex aufgenommen, der für Duplikaterkennung und Gesichtssuche verwendet wird. Sie werden nicht automatisch gesperrt. Um einen bekannten Täter zu sperren, laden Sie das Gesicht stattdessen in eine Liste vom Typ Gesicht hoch.
Laden Sie nur Gesichter hoch, deren Verarbeitung nach Ihrer eigenen Datenschutzerklärung und Migrationsvereinbarung zulässig ist. Hinterlegen Sie Kennungen des Quellanbieters nur dann in metadata oder comment, wenn sie Ihren Compliance-Beauftragten offengelegt werden dürfen.

So erfolgt die Sperrung

Ein Gesicht in die Sperrliste hochladen

Um einen Benutzer programmatisch anhand seines Gesichts zu sperren, laden Sie das Gesichtsbild über den eigens dafür vorgesehenen Endpoint Gesicht in Liste hochladen in eine Sperrliste vom Typ Gesicht hoch. Didit extrahiert das biometrische Embedding und fügt es dem passenden Index hinzu. Jede künftige Sitzung, deren Liveness-Selfie übereinstimmt, wird automatisch abgelehnt.
Das Hochladen eines Profilgesichts und das Hochladen in eine Gesichts-Sperrliste sind unterschiedliche Vorgänge. Verwenden Sie den Profil-Upload, um einem Benutzer ein vertrauenswürdiges importiertes Gesicht als Nachweis, zur Duplikaterkennung und Gesichtssuche zuzuordnen. Verwenden Sie die Lists API, um ein Gesicht zu sperren, damit passende künftige Sitzungen abgelehnt werden.

Ein Gesicht aus der Sperrliste entfernen

Entfernen Sie den Eintrag in der Konsole unter Blocklist → Faces → Zeilenaktionen → Remove oder verwenden Sie den Endpoint Eintrag löschen.

Aufbewahrte biometrische Templates nach dem Löschen einer Sitzung

Beim Löschen einer Sitzung werden das Gesichtsbild und standardmäßig auch das Gesichts-Embedding gelöscht. Die Person fällt damit aus der Duplikatserkennung und der Gesichtssuche heraus. Wenn Sie Sitzungen kurz nach der Genehmigung löschen, aber dennoch wiederholte Registrierungen erkennen müssen, aktivieren Sie die Aufbewahrung biometrischer Templates für die Anwendung oder senden Sie retain_face_embeddings: true beim Löschaufruf. Didit löscht danach die Sitzung und alle zugehörigen Daten wie gewohnt und behält ein separat verwaltetes, bildfreies biometrisches Gesichts-Template, das mit dem Benutzer verknüpft ist:
  • Es enthält nur das numerische Gesichts-Template und Aufbewahrungsmetadaten. Es enthält niemals das Gesichtsbild, das Liveness-Video, Dokumentdaten, extrahierte Identitätsfelder, die Entscheidung oder die ID der gelöschten Sitzung.
  • Es nimmt an der Duplikatserkennung, der Gesichtssuche, der biometrischen Authentifizierung und Ihren Gesichtslisten genauso teil wie das Gesicht einer aktiven Sitzung. Treffer werden mit source: "retained_template", dem vendor_user_id und vendor_data des Benutzers sowie einer biometric_template_id gemeldet.
  • Es handelt sich um biometrische Daten mit einem endlichen expires_at. Das Template wird entfernt, wenn der Benutzer gelöscht wird, wenn eine Sitzung dieses Benutzers mit deletion_instruction: "privacy_erasure" gelöscht wird, wenn es abläuft oder wenn Sie es unter Lists → Biometric templates oder über die Biometric Templates API entfernen.
  • Eine Sitzung, die ohne vendor_data erstellt wurde, hat keinen Benutzer, mit dem ein Template verknüpft werden könnte. Beim Löschen wird ineligible_no_vendor_user gemeldet, und das Embedding wird zusammen mit der Sitzung gelöscht.
  • Aufbewahrte Templates werden niemals auf die Sperrliste gesetzt. Ein Eintrag in der Gesichts-Sperrliste, der aus der gelöschten Sitzung erstellt wurde, behält seinen eigenen, unabhängigen biometrischen Eintrag und Lebenszyklus.
Mit einem Benutzer verknüpfte Templates erscheinen im Benutzerprofil unter Biometric templates mit einer Aktion zum Entfernen.

Zusammenfassung des Gesichts-Lebenszyklus

Ein Gesicht über die Konsole hochladen

Compliance-Mitarbeitende können Gesichter manuell hochladen:
  1. Navigieren Sie zu Users → [user] → Actions → Upload face.
  2. Wählen Sie ein Bild aus; Didit extrahiert das größte Gesicht und speichert einen neuen Gesichtseintrag, der mit dem Benutzer verknüpft ist.
  3. Das Gesicht wird für Profilnachweise, Duplikatserkennung und Gesichtssuche registriert. Verwenden Sie den Bereich Sperrliste, wenn künftige passende Sitzungen abgelehnt werden sollen.
Das ist nützlich, wenn:
  • Sie ein bekanntes Porträt eines Kunden haben, das über einen Offline-Kanal verifiziert wurde.
  • Sie eine Sperrliste mit bekannten Betrügern aus Ihrer Betrugsdatenbank vorbefüllen möchten.

Datenschutz und Aufbewahrung

  • Gesichts-Embeddings sind numerische Vektoren, keine Bilder. Die Bilder selbst werden in verschlüsseltem Objektspeicher mit Zugriff über signierte URLs gespeichert. Ein Gesichts-Embedding stellt biometrische Daten dar.
  • Die Aufbewahrung richtet sich nach der Datenaufbewahrung Ihrer Anwendung. Aufbewahrte biometrische Templates folgen dem strengeren, endlichen Aufbewahrungszeitraum der Aufbewahrung biometrischer Templates.
  • Beim Löschen einer Sitzung werden das Bild und standardmäßig das Embedding gelöscht. Wenn Ihre Anwendung die Aufbewahrung biometrischer Templates aktiviert hat, bleibt beim Löschen einer Sitzung ein bildfreies Template erhalten, bis es abläuft oder entfernt wird.
  • Bei einer Anfrage gemäß GDPR/CCPA zum Recht auf Vergessenwerden löschen Sie die Sitzungen der Person mit deletion_instruction: "privacy_erasure" oder löschen Sie den Benutzer. Beides entfernt auch alle aufbewahrten Templates. Von Ihnen verwaltete Einträge in der Gesichts-Sperrliste bleiben bestehen, bis Sie sie entfernen.

Nächste Schritte

Gesichtssuche

Wie die 1:N-Gesichtssuche funktioniert.

Liveness

Liveness-Erkennung, die das Gesicht erfasst.

Sperrlisten-API

Ein Gesicht in eine Sperrliste hochladen.

Biometrische Templates

Nach dem Löschen einer Sitzung aufbewahrte Templates.

Benutzer-Sperrliste

Wie das Hinzufügen eines Benutzers zur Sperrliste funktioniert.
Zuletzt geändert am 7. November 2026