Wie Sie ein Verifizierungsergebnis lesen
Ein Session-Ergebnis besteht aus einem Status plus einem Ergebnis pro Prüfung plus einer Liste von Warnungen - die Warnungen sind der Teil, der Ihnen sagt, was tatsächlich passiert ist.
Lesen Sie es in dieser Reihenfolge: der Gesamtstatus, dann die Status pro Prüfung, dann die Warnungen. Die Warnungen sind der einzige Teil, der Ihnen warum sagt - alles andere sagt Ihnen nur was.
Öffnen Sie eine beliebige Session unter Verifizierungen in der Business-Konsole, und Sie erhalten dieselben drei Ebenen, egal ob Sie sich die Konsole, eine Webhook-Payload oder eine API-Antwort ansehen.
- Beginnen Sie hier: die Entscheidung und die Prüfungen, die sie erzeugt haben.
- Liveness enthält das Selfie-Ergebnis und den Gesichtsabgleich-Score.
- Der Dokument-Tab zeigt, was extrahiert wurde und welche Felder übereinstimmten.
- Events erklärt, wie die Session ihren aktuellen Status erreicht hat.
#Ebene 1 - der Gesamtstatus
Das einzige Urteil für die Session: Genehmigt, Abgelehnt, In Prüfung und so weiter. Darauf reagieren die meisten Integrationen. Es ist ein Aggregat: Es entsteht aus der Kombination aller Prüfungsergebnisse gemäß der Konfiguration Ihres Workflows, sagt Ihnen also nie, welche Prüfung verantwortlich war.
#Ebene 2 - ein Ergebnis pro Prüfung
Jede durchgeführte Prüfung hat ihren eigenen Status und ihre eigenen Daten. Die, die Sie am häufigsten sehen:
| Prüfung | Worauf zu achten ist |
|---|---|
| ID-Verifizierung | Extrahierte Felder (Name, Dokumentnummer, Daten), Dokumenttyp und Land, und ob die MRZ validiert wurde |
| Passive / aktive Liveness-Prüfung | Ob ein lebender Mensch erkannt wurde, und jedes Angriffssignal |
| Gesichtsabgleich 1:1 | Der Ähnlichkeitswert zwischen Selfie und Dokumentfoto |
| Gesichtssuche 1:N | Ob dieses Gesicht mit einem bereits verifizierten Nutzer oder einem Sperrlisteneintrag übereinstimmt |
| AML-Screening | Die Treffer, jeweils mit einem Übereinstimmungswert und einem Risikowert |
| Geräte- und IP-Analyse | Land, VPN- oder Proxy-Signale, gesperrte Adressen |
| Adressnachweis | Die extrahierte Adresse und wie gut sie mit der angegebenen übereinstimmte |
| NFC | Ob der Chip gelesen wurde und ob seine Signatur zu einem vertrauenswürdigen Aussteller zurückverfolgt werden konnte |
| Telefon / E-Mail | Ob das OTP bestätigt wurde, plus Risikosignale zur Nummer oder Adresse |
Eine Prüfung kann Genehmigt sein, während die Session Abgelehnt ist, und umgekehrt. Das ist normal - der Session-Status ist die Kombination, nicht der schlechteste Fall.
#Ebene 3 - die Warnungen
Warnungen sind die Ebene, die das Ergebnis tatsächlich erklärt. Jede ist ein spezifischer, benannter Code, der an die Prüfung angehängt ist, die ihn ausgelöst hat - zum Beispiel:
DOCUMENT_EXPIRED- das Ablaufdatum des Ausweises ist verstrichen.MRZ_VALIDATION_FAILED- die Prüfsumme der maschinenlesbaren Zone stimmte nicht. Ein starkes Manipulationssignal.LOW_FACE_MATCH_SIMILARITY- Selfie und Dokumentfoto lagen unter Ihrer Schwelle.LIVENESS_FACE_ATTACK- während des Selfies wurde ein Präsentationsangriff erkannt.POSSIBLE_MATCH_FOUND- AML hat einen Kandidaten-Treffer gefunden, der geklärt werden muss.NFC_DATA_DOES_NOT_MATCH_OCR- Chip und gedruckte Daten stimmen nicht überein.IP_ADDRESS_IN_BLOCKLIST- die Verbindung kam von einer von Ihnen gesperrten Adresse.
Wenn Sie eine bestimmte Session untersuchen, gehen Sie direkt zu den Warnungen. Der Status nennt Ihnen das Fazit; die Warnungen liefern die Belege. Jeder Warnkatalog pro Funktion ist unter Kerntechnologie dokumentiert.
#Extrahierte Daten im Vergleich zu Ihren Erwartungen
Wenn Sie beim Erstellen der Session expected_details übergeben haben - einen Namen, ein Geburtsdatum, eine Dokumentnummer, die Sie bereits vorliegen haben -, sagt Ihnen das Ergebnis auch, ob das Dokument damit übereinstimmte. Eine Abweichung dort ist meist ein Dateneingabeproblem auf Ihrer Seite und kein betrügerisches Dokument, es lohnt sich also, das zu prüfen, bevor Sie jemanden ablehnen.
Extrahierte Namen können transliteriert sein. Ein Dokument in kyrillischer, arabischer oder griechischer Schrift erzeugt einen Namen in lateinischer Schrift, der auch bei derselben Person nicht zeichengenau mit Ihren Aufzeichnungen übereinstimmen muss. Vergleichen Sie zusätzlich die Dokumentnummer oder das Geburtsdatum, bevor Sie eine Namensabweichung als Betrug werten.
#Sandbox-Ergebnisse sehen etwas anders aus
In einer Sandbox-Session markiert die Konsole die Abschnitte mit extrahierten Daten mit einem Chip Simulated data. Die Medien wurden wirklich erfasst, aber die Felder und das Ergebnis stammten aus dem gewählten Szenario - lesen Sie also nichts in die Werte selbst hinein. Siehe Testen in der Sandbox.
#Dasselbe programmatisch erhalten
Die Webhook-Payload und GET /v3/session/{id}/decision/ tragen alle drei Ebenen in einem decision-Objekt. Behandeln Sie den Webhook als Ihre Quelle der Wahrheit und pollen Sie nur zum Abgleich - manche Ereignisse, wie von einem Prüfer vorgenommene Datenänderungen, kommen ausschließlich per Webhook an. Siehe Ergebnisse mit Webhooks erhalten.
#Eine Kopie für Ihre Unterlagen erhalten
Für Audits und behördliche Meldungen laden Sie die Session als PDF herunter - sie bündelt jeden Schritt, die extrahierten Daten, die biometrischen Scores, die AML-Ergebnisse und die endgültige Entscheidung. Siehe einen Verifizierungsbericht herunterladen.