Zum Hauptinhalt springen

Übersicht

Der Bericht zum Gesichtsabgleich erfasst einen biometrischen 1:1-Abgleich zwischen dem während der Liveness-Erkennung aufgenommenen Live-Selfie und einem Referenzbild – meist das aus dem Ausweisdokument extrahierte Porträt. Er gibt einen einzelnen Ähnlichkeits-Score von 0–100, signierte URLs für die beiden verglichenen Bilder, die Quellsitzung für das Referenzbild sowie alle durch den Abgleich ausgelösten Warnungen zurück. Der Bericht wird erstellt, nachdem der Benutzer sowohl den Liveness-Schritt als auch den Dokumentenschritt in einem Workflow abgeschlossen hat (oder bei porträtbasierten Workflows wie der biometrischen Authentifizierung nach der Liveness-Erkennung allein) oder direkt über die eigenständige Gesichtsabgleich-API, wenn Sie selbst zwei beliebige Gesichtsbilder übergeben. Jeder Bericht enthält einen eigenen status – unabhängig vom Gesamtsitzungsstatus –, der widerspiegelt, wie der Schritt des Gesichtsabgleichs allein abgeschlossen wurde:
  • Genehmigt — score liegt über dem Prüfschwellenwert und es wurde keine Warnung zur automatischen Ablehnung ausgelöst.
  • In Prüfung — score liegt zwischen dem Ablehnungs- und dem Prüfschwellenwert, oder es konnte kein Score berechnet werden und face_match_not_computed_action ist REVIEW.
  • Abgelehnt — score liegt bei oder unter dem Ablehnungsschwellenwert, NO_REFERENCE_IMAGE wurde ausgelöst oder es konnte kein Score berechnet werden und face_match_not_computed_action ist DECLINE.
  • Erneute Einreichung angefordert — ein Prüfer hat über die Konsole angefordert, dass der Benutzer diesen Schritt erneut einreicht.
  • Nicht abgeschlossen — der Schritt des Gesichtsabgleichs hat noch kein Ergebnis geliefert (einschließlich während der Benutzer eine fehlgeschlagene Erfassung wiederholt).

Wo er in API-Antworten erscheint

Der Bericht zum Gesichtsabgleich wird im Array face_matches[] geliefert – immer als JSON-Array, niemals als einzelnes face_match-Objekt. Er ist null, bis mindestens ein Schritt des Gesichtsabgleichs Daten erzeugt hat, und mehrere Einträge erscheinen, wenn ein Workflow den Gesichtsabgleich mehr als einmal ausführt. Ein Workflow für die Adaptive Age Verification füllt ihn ebenfalls aus, wenn der Fallback zur Ausweisverifizierung ausgeführt wird: Dieser Eintrag gibt den Altersschätzungs-Knoten als seine node_id an, da der Workflow keinen eigenen Gesichtsabgleich-Knoten besitzt.
  • Sitzungsentscheidungs-API — GET /v3/session/{sessionId}/decision/ gibt face_matches[] auf oberster Ebene zurück. Siehe Sitzungsentscheidung abrufen.
  • Webhooks — session.status.updated-Payloads enthalten dasselbe face_matches[]-Array, sobald der Schritt Daten erzeugt hat. Siehe Webhooks.
  • Eigenständige Gesichtsabgleich-API — für direkte 1:1-Abgleiche siehe Eigenständige Gesichtsabgleich-API.
Lesen Sie response.face_matches[0] aus und iterieren Sie über das Array – die singuläre face_match-Struktur, auf die in einigen älteren Tutorials verwiesen wurde, existiert am v3-Entscheidungs-Endpoint nicht.

Schema

Das kanonische Schema für jedes Feld befindet sich auf der Referenzseite Datenmodelle. Die folgenden Felder spiegeln dieses kanonische Schema wider.

Statuswerte

Fehlschläge aufgrund geringer Ähnlichkeit werden wiederholt, bevor der Status festgelegt wird: Der Benutzer kann bis zu face_match_max_attempts Erfassungsversuche durchführen (standardmäßig 3), und nur der Score des letzten Versuchs wird angewendet. Benutzerdefinierte Statusregeln, die am Workflow-Knoten konfiguriert sind, können den resultierenden Status weiter anpassen und ihn mit dem aus dem Score abgeleiteten Status gemäß der Rangfolge Declined > In Review > Approved kombinieren.

Beispiele

Genehmigt – eindeutige Übereinstimmung

In Prüfung – grenzwertige Ähnlichkeit

Abgelehnt – kein Referenzbild für den Abgleich vorhanden

Sicherheitshinweis

Die signierten URLs für source_image und target_image stellen biometrische Daten dar und laufen nach einem kurzen Gültigkeitsfenster ab. Behandeln Sie sie als kurzlebig: Cachen Sie sie nicht und stellen Sie sie nicht öffentlich bereit. In der Regel benötigt Ihre Anwendung lediglich status und score – speichern Sie so wenig wie möglich, um die Menge biometrischer Daten auf Ihren Servern zu minimieren.

Verwandte Themen

Zuletzt geändert am 7. November 2026