Betrugssignale und Gesichtsabgleich

Was passiert hier?

Jede Verifizierung führt eine Reihe von Betrugserkennungen aus. Wenn eine davon anschlägt, fügt sie der Anfrage ein Betrugssignal hinzu. Signale erscheinen auf der Karte Betrugssignale der Detailseite der Anfrage und auf der Karte Prüfung erforderlich. Außerdem sind sie Teil der API-Antwort (fraudSignals) und des JSON-Exports der Ergebnisse.

Jedes Signal hat einen Schweregrad:

• Hoch — starke Hinweise auf Betrug. Einige hohe Signale schicken die Anfrage automatisch zur manuellen Prüfung.
• Mittel — einen Blick wert. Wird dem Prüfer angezeigt, erzwingt aber keine Entscheidung.
• Niedrig — nur zur Information.

Gesichtsabgleich

Wenn das Ausweisfoto oder das Selfie eines Antragstellers verarbeitet wird, berechnet Certivant eine Gesichtsvorlage. Das ist eine Liste von Zahlen, die das Gesicht beschreibt. Sie stammt nur aus dem erkannten, zugeschnittenen Gesicht, nie aus der ganzen Karte. Die Vorlage wird mit den Vorlagen früherer Verifizierungen in allen Organisationen verglichen, die Certivant nutzen, nicht nur in Ihrer. So fällt ein Betrüger auf, der dasselbe Gesicht mit einem neuen Namen bei einem anderen Unternehmen wiederverwendet.

Die vier Gesichtssignale

Was Sie sehen und was Sie nie sehen

Übereinstimmung bei einer anderen Organisation. Die Karte sagt zum Beispiel: „Dieses Gesicht wurde bereits bei einer anderen Organisation unter einem anderen Namen und Geburtsdatum verifiziert.“ Mehr erfahren Sie nicht. Sie sehen nie den Namen der anderen Organisation, deren Anfrage, den Namen oder das Bild des Antragstellers dort. Der Server entfernt diese Angaben, bevor etwas Ihren Browser, Ihren API-Schlüssel, Ihre Webhooks oder Ihre Exporte erreicht. Ihre Antragsteller sind ebenso geschützt, wenn die Übereinstimmung bei einer Anfrage einer anderen Organisation gefunden wird.

Übereinstimmung innerhalb Ihrer Organisation. Die Karte verlinkt die andere Anfrage über deren 8-stellige ID („Dasselbe Gesicht wie Anfrage ABCD1234“). Wenn Sie beide Dokumente öffnen dürfen, werden die beiden Gesichter nebeneinander angezeigt. Gehört die andere Anfrage zu einem Team, auf das Sie keinen Zugriff haben, sagt die Karte dies, ohne das Team zu nennen.

Jede Karte zeigt außerdem, was sich unterscheidet (Name, Geburtsdatum, Dokumentnummer), die Ähnlichkeit und ob ein zweiter Vergleich die Übereinstimmung bestätigt hat.

Gesichtsübereinstimmung prüfen

1. Öffnen Sie die Anfrage und lesen Sie den Block Gesichtsabgleich in der Karte Betrugssignale.
2. Bei einer Übereinstimmung innerhalb Ihrer Organisation öffnen Sie die verlinkte Anfrage und vergleichen Sie die Dokumente und die Antragsteller.
3. Bei einer Übereinstimmung bei einer anderen Organisation behandeln Sie sie als starken Grund, die Dokumente, das Selfie und die Daten dieses Antragstellers genauer anzusehen, und entscheiden Sie dann. Bitten Sie den Antragsteller um weitere Nachweise oder planen Sie eine Live-ID-Verifizierung, wenn Sie unsicher sind.
4. Genehmigen oder lehnen Sie wie gewohnt im Prüfbereich ab. Ihre Entscheidung und das Signal werden beide im Audit-Protokoll gespeichert.

Einwilligung

In öffentlichen Formularen und auf der gehosteten Prüfseite bittet der Einwilligungsbereich den Antragsteller, der Gesichtsprüfung zuzustimmen, bevor er etwas hochlädt. Standardmäßig ist sie erforderlich: Der Antragsteller kreuzt das Kästchen an, um fortzufahren, und Selfie, Liveness-Prüfung und Gesichtsabgleich laufen ab. Siehe Die Erfahrung der Antragsteller.

Manche Gesetze verlangen eine nicht biometrische Alternative (zum Beispiel in Québec). Nur dort schalten Sie im Formular Antragstellern erlauben, die Gesichtsprüfung abzulehnen ein (Formular-Editor → Optionen zur Aufnahmesicherheit, standardmäßig aus) oder senden beim Erstellen der Anfrage über die API faceCheckSkippable: true. Das Kästchen der Gesichtsprüfung trägt dann den Hinweis „Optional“, und im Einwilligungsbereich steht: „Wenn Sie nicht zustimmen, wird kein Selfie aufgenommen: [Organisation] prüft Ihre Identität gemeinsam mit Ihnen in einem Live-Videoanruf.“ Für Prüflinks, die ohne Formular gesendet werden, gilt stattdessen die Einstellung der Organisation in den Verifizierungseinstellungen (standardmäßig aus). Es gewinnt die erste Übereinstimmung: faceCheckSkippable in der API, wenn es gesendet wird (true oder false), dann der Schalter des Formulars, dann die Einstellung der Organisation.

Wenn der Antragsteller ablehnt (nur möglich, wenn die Alternative eingeschaltet ist):

• Das Selfie sowie die Schritte der Gesichts- und Liveness-Prüfung werden übersprungen. Die Ausweisdokumente werden weiterhin erfasst.
• Es läuft kein Gesichtsabgleich, keine Liveness-Prüfung und kein Gesichts-Fingerabdruck, sodass das Gesicht des Antragstellers nicht in den Betrugsindex aufgenommen wird.
• Die Anfrage geht in die manuelle Prüfung. Sie wird nie automatisch genehmigt und wegen der Ablehnung auch nie abgelehnt.
• Der Prüfgrund Gesichtsprüfung abgelehnt – im Live-Anruf prüfen (biometric_consent_refused) wird hinzugefügt, und die Anfrageseite zeigt eine Karte „Gesichtsprüfung abgelehnt – Live-Verifizierung empfohlen“ mit der Schaltfläche Live-Verifizierung planen.

Sie können den Code in Richtlinien und Workflows verwenden, zum Beispiel reviewTriggers CONTAINS 'biometric_consent_refused'.

Bei Live-ID-Verifizierungen ist die Gesichtsprüfung im Einwilligungsfenster ebenfalls ein erforderlicher Zweck. Sie wird nicht angezeigt, wenn die planende Person den vollständigen Einwilligungsbildschirm ausgeschaltet hat: Dann wird nur die Videoaufzeichnung abgefragt. Ist die Alternative eingeschaltet (festgelegt durch die API, das Formular der Anfrage oder die Einstellung der Organisation, in dieser Reihenfolge), ist die Gesichtsprüfung optional. Ein Antragsteller, der sie ablehnt, wird nicht blockiert, und der Anruf wird nicht abgebrochen. Stattdessen wird diese Live-Sitzung zur nicht biometrischen Alternative: Der Host vergleicht das Gesicht der Person visuell über die Kamera mit dem Ausweis. Das Aufbewahren eines Ausweisbilds, damit ein Mensch es ansieht, ist nicht biometrisch; der Antragsteller kann daher weiterhin Ausweisdokumente senden, nur das Selfie und die Gesichtsprüfung sind abgeschaltet. Siehe Ohne Gesichtsprüfung.

In beiden Fällen wird die Antwort als Nachweis mit der Verifizierung gespeichert: der Zweck biometric_fraud_check, die Version des Wortlauts, der Zeitpunkt der Antwort sowie die IP-Adresse und der Browser des Antragstellers. Außerdem wird ein Ereignis request.consent_recorded im Audit-Protokoll geschrieben.

Löschung

Die Gesichtsvorlage folgt den Dokumenten, aus denen sie stammt. Wird ein Dokument oder eine Anfrage gelöscht (manuell, durch Ihre Aufbewahrungseinstellungen, nach einer Entscheidung, durch eine Löschung oder einen Antrag auf Datenlöschung), wird auch deren Gesichtsvorlage gelöscht.

Prüfung der Führerscheinnummer

An manchen Orten bildet die ausstellende Behörde die Führerscheinnummer aus dem Nachnamen und dem Geburtsdatum des Inhabers. Passt die Nummer auf einem Führerschein nicht zum Nachnamen und Geburtsdatum, die Certivant auf derselben Karte liest, ist das ein starkes Zeichen für Fälschung oder Verwechslung. Certivant prüft dies bei jedem gelesenen Führerschein. Kann die Nummer nicht zum Inhaber gehören, wird der Prüfauslöser Führerscheinnummer passt nicht zu Name oder Geburtsdatum (dl_number_mismatch) hinzugefügt.

Andere Regionen sowie die übrigen kanadischen Provinzen, andere US-Bundesstaaten, Nordirland und Minnesota werden nicht geprüft, weil deren Nummern weder Nachnamen noch Geburtsdatum enthalten. Die Prüfung ist bewusst tolerant: Sie akzeptiert den Monat wie geschrieben oder mit dem Versatz, den manche Behörden für Frauen verwenden. Sie erzwingt nicht das Geschlecht, das eine Nummer nahelegt. Daher markiert sie nur eine Nummer, die eindeutig nicht passt.

Eine Abweichung geht immer an einen Menschen und führt nie allein zur Ablehnung. Ein Inhaber, der nach der Heirat den Nachnamen geändert hat, darf rechtmäßig eine Nummer behalten, die aus dem alten Namen gebildet wurde. Der Prüfer sieht den Auslöser in den Prüfgründen der Verifizierung. Der Antragsteller sieht den verständlichen Satz „Eine Person wird es prüfen“. Richtlinien und Workflows können ihn als document.dlNumberMismatch (wahr/falsch) auslesen. Siehe den Richtlinien-Editor.

Weitere Betrugssignale

• Häufigkeit — viele Einreichungen desselben Antragstellers in kurzer Zeit.
• Wiederverwendung von Dokumenten — dieselbe Dokumentnummer auf einem anderen Profil Ihrer Organisation.
• Dokumentenkonflikt — die Dokumente einer Anfrage widersprechen sich bei Name oder Geburtsdatum.
• Wiederverwendung des Geräts — dasselbe Gerät wird von mehreren Identitäten genutzt. Die Anzahl der Personen, der Rückblickzeitraum und die Aktion legen Sie fest.
• IP-Häufigkeit — viele Antragsteller von derselben IP-Adresse.
• IP-Adresse von mehreren Personen genutzt — dieselbe IP-Adresse steht innerhalb Ihres Zeitfensters hinter mehreren verschiedenen Identitäten.
• Telefonnummer / E-Mail-Adresse von einer anderen Person genutzt — siehe Sperrliste und Erkennung von Duplikaten.
• Treffer auf der Sperrliste — die Verifizierung entspricht einem Eintrag Ihrer Sperrliste. Die Karte zeigt die Art des Treffers (Gesicht, Dokumentnummer, Telefon, E-Mail, IP, Gerät), nie den Wert.
• Land des Anbieters stimmt nicht — eine Bank oder ein Versorgungsunternehmen aus einem anderen Land als der Antragsteller.

Verwandte Themen

• KYC- und KYB-Anfragen prüfen — die Detailseite, auf der die Signale erscheinen.
• Die Erfahrung der Antragsteller — der Einwilligungsbereich.
• Richtlinien-Editor — Betrugssignale in Ihren eigenen Regeln verwenden.
• Webhooks — Signalarten in den Webhook-Nutzlasten.