KYC-Verifizierung: Was Endbenutzer sehen

Vollständiges Transkript von What Your Users Actually See in a KYC Verification (Full Walkthrough) - Didit-Academy-Video 2 von 10, 14:36. Auf YouTube ansehen. Jeder Absatz verlinkt auf die genaue Stelle im Video.

​

Was dieses Video behandelt

00:03 Wenn Sie einen Kunden zur Verifizierung zu Didit schicken, was sieht er eigentlich? Genau darum geht es in diesem Video. Wir gehen den gesamten Ablauf aus seiner Sicht durch. Die genauen Bildschirme, durch die eine echte Person tippt, nachdem sie auf Ihren Link geklickt hat. Ein Ablauf, den Sie vollständig in deren eigener Sprache und auf jedem Gerät mit Ihrer Marke versehen können, mit einer Reihe unsichtbarer Prüfungen im Hintergrund und dem echten Ergebnis, das in Ihrem System landet, sobald es vorliegt. Am besten bekommen Sie ein Gefühl dafür, wenn Sie selbst einen durchlaufen. Gehen Sie also auf didit.me, Sie können sich kostenlos registrieren und auf Ihrem eigenen Telefon in

​

Den Ablauf selbst öffnen

00:38 ein paar Minuten. Okay, der einfachste Weg, genau zu sehen, was Ihre Benutzer durchlaufen, ist, den Ablauf selbst zu öffnen. Genau das machen wir jetzt. Äh, wir gehen hier zu einem unserer Workflows. Wir kopieren den Link und fügen ihn im Browser ein. Nehmen wir also diesen einfachen KYC-Workflow. Wir kopieren diesen Link und fügen ihn hier ein. Genau hier ist der

​

Der erste Bildschirm, den Ihr Benutzer sieht

00:58 das Allererste, was Ihr Benutzer sieht, nachdem er auf einen Ihrer Links tippt. Das Erste, worauf Sie achten sollten: Äh, das hier ist eine Demo dafür. Hier sehen wir das Didit-Branding, aber Sie können das vollständig anpassen. Diese Liste hier zeigt jeden Schritt, den dieser konkrete Benutzer durchläuft. Wir haben also Ausweisverifizierung, Gesichtsverifizierung und zusätzliche Dokumente. Diese Liste ist nicht fest codiert. Der Workflow, dem diese Sitzung zugeordnet ist, legt tatsächlich fest, welche Schritte erscheinen und in welcher Reihenfolge. Dieser Ablauf rendert also einfach

​

Branding und warum es die Abschlussquote bestimmt

01:28 alles, was in diesem Workflow enthalten ist, sobald Sie ihn aktivieren. Auch das Logo und das Styling gehören Ihnen. Für den Benutzer fühlt sich das also weiterhin wie Ihr Produkt an. Das ist ziemlich wichtig, denn wie sehr es nach Ihnen und Ihrer Marke aussieht, ist der mit Abstand größte Hebel dafür, wie viele Menschen diesen Verifizierungsablauf tatsächlich abschließen. Unten gibt es ein kleines Zeichen mit dem Hinweis „Secured by Didit“, und selbst das lässt sich entfernen. Alles darüber können Sie selbst konfigurieren. Didit ist nur die Engine, die darunter läuft. Was Ihr Benutzer sieht, ist also genau der Workflow, den Sie eingerichtet haben, eingebettet in Ihre Marke. Also hier ist

​

Die Prüfungen, die nie einen Bildschirm zeigen

02:00 etwas, das die meisten überrascht. Nicht jede Prüfung, die Sie hier sehen, hat einen eigenen Bildschirm. Nur die Schritte, die tatsächlich eine Handlung des Benutzers erfordern, werden angezeigt. Also Dokument, Gesicht, Telefon, E-Mail, und während er diese Schritte durchläuft, läuft auf dem Server eine ganze Reihe weiterer Prüfungen, ohne dass der Benutzer irgendetwas berührt. Also Geräte- und IP-Analyse, AML-Screening, laufende AML-Überwachung, Datenbankvalidierung, all das passiert im Hintergrund. Der Benutzer sieht nie einen Schritt davon, und Sie erhalten trotzdem jedes Ergebnis in Ihrem Dashboard zurück. Genau so bleibt der Ablauf super kurz, während trotzdem eine Menge Arbeit geleistet wird. Einige der stärksten Prüfungen von Didit laufen ohne jede Reibung, weil sie den Benutzer nie betreffen. Wenn Sie also zurückgehen und sich einen dieser Workflows ansehen, sehen wir hier, dass wir all diese Hintergrundprüfungen haben. Wir haben Datenbankvalidierung. Äh, wir haben E-Mail-Verifizierung, Telefonverifizierung, AML-Screening, IP- und Risikoanalyse. Diese Prüfungen sind also nicht öffentlich sichtbar. Das sind alle Prüfungen, die

​

Anpassung: Farben, Logo, E-Mail, Domain

03:00 die Sie in einen Workflow einbauen können. Schauen wir uns also den Tab Anpassung an. Hier können Sie Ihr Branding, Ihre Farben, Ihre eigene E-Mail-Adresse, Ihre eigene Domain und all diese Dinge hinzufügen. Wie Sie hier sehen, können wir den Namen der App ändern. Wir können die Willkommensseite anzeigen oder ausschalten. Wir könnten den Fortschrittsbalken anzeigen oder ausschalten. Wir haben den Tab Branding, in dem wir all diese Farben hinzufügen können. Wir können das Logo und das Favicon hinzufügen und die Typografie ändern. Wir können eine eigene E-Mail-Adresse hinterlegen. 03:25 Also, wenn Sie hier nur einen Namen eintragen, können wir eine E-Mail-Adresse angeben und mit der Verifizierung fortfahren. Das führt dann zu dem Hinweis, dass das nicht funktioniert hat. Wenn wir aber eine echte, funktionierende Domain eintragen und auf Weiter zur Verifizierung klicken, bekommen wir die DNS-Einträge, äh, die wir hinzufügen können, und wir können eine eigene E-Mail-Adresse einrichten. Von dieser E-Mail-Adresse werden die Benachrichtigungen und alle Updates zum Verifizierungsstatus versendet. Für die Domain können wir außerdem eine eigene Domain hinzufügen. Also hatten wir zum Beispiel eine Subdomain. Und wenn Sie hier Ihre Subdomain eintragen, bekommen Sie wieder die Einträge, die Sie bei Ihrem Domain-Anbieter aktualisieren müssen. Sie sehen hier oben diesen Globus. Die

​

54 Sprachen, automatisch erkannt

04:04 Die Oberfläche ist in 54 verschiedenen Sprachen verfügbar, darunter auch Schriften von links nach rechts wie Arabisch. Standardmäßig erkennt dieser Ablauf automatisch die im Browser eingestellte Sprache und fällt auf Englisch zurück, wenn diese Sprache nicht unterstützt wird. Der Benutzer kann aber jederzeit diese durchsuchbare Liste öffnen und in jede Sprache wechseln, und alle Anweisungen werden von da an in der gewählten Sprache angezeigt. Und wenn Sie die Sprache eines Benutzers bereits im Voraus kennen, etwa aus Ihrer eigenen Datenbank, können Sie diese Sprache beim Erstellen der Sitzung festlegen. So öffnet sich der Ablauf in der richtigen Sprache, ganz ohne sich auf den Browser zu verlassen. Der Ablauf begegnet dem Benutzer also automatisch in seiner eigenen Sprache, mit 54 Sprachen zur Auswahl. Schauen wir uns also an

​

Mobil vs. Desktop und die QR-Übergabe

04:49 In dieser Vorschau sehen Sie, dass die meisten Nutzer ihre Verifizierung am Smartphone abschließen. Das ist naheliegend, oder? Die Kamera macht das Aufnehmen von Dokument und Selfie besonders einfach. Man richtet das Smartphone einfach auf diesen QR-Code und kann den Verifizierungsprozess direkt auf dem Gerät fortsetzen. Wenn jemand diese Seite am Desktop öffnet, sehen Sie hier, dass die Verifizierung auch dort fortgesetzt werden kann, das ist aber eine Option. Sie können festlegen, dass die Nutzer ausschließlich über das Smartphone verifizieren. Sie können aber auch den Desktop freigeben, damit die Nutzer die Verifizierung direkt am Computer abschließen. Beachten Sie dabei: Am Desktop wird die Liveness-Prüfung zwingend auf passiv gesetzt, weil die aktive Variante mit Computer-Webcams nicht gut funktioniert. Mit aktiv und passiv meine ich Folgendes: Bei der aktiven Variante muss der Nutzer vor der Kamera blinzeln. Das ist eine aktive Liveness-Prüfung. Passiv ist dagegen nur ein Foto.

​

Gehosteter Ablauf oder eigene Bildschirme

05:34 Der einfachste Einstieg ist der gehostete Ablauf. Wenn ich hier auf „Link kopieren“ klicke und ihn in meinem Browser öffne, sehen Sie, was passiert. Sie können dem Nutzer einen Link senden, und Didit übernimmt die schwierigen Teile für Sie: die Kameraberechtigungen, die Dokumentenerfassung, die Liveness-Prüfung und alle kniffligen Eigenheiten einzelner Geräte. Den gehosteten Ablauf können Sie über das SDK, ein iframe, eine Weiterleitung oder ein Pop-up in Ihre App einbinden. Wenn Sie lieber eigene Bildschirme von Grund auf entwickeln möchten, ist das ebenfalls möglich. Dann liegt aber die gesamte Umsetzung bei Ihnen. Die Integration behandeln wir in einem eigenen Video ausführlich. Für den Moment genügt es zu wissen, dass der Link, den Sie aus diesem Workflow erhalten und versenden, der gehostete Ablauf ist. Er ist darauf ausgelegt, dass Nutzer bis zum Ende durchkommen.

​

Erkennung des Ausstellungslandes

06:20 Zurück zum Flow. Wenn der Dokumentschritt wissen muss, aus welchem Land der Ausweis stammt, hat der Flow das meistens bereits ermittelt. Sobald die Seite geladen wird, wird der Nutzer anhand seiner IP-Adresse geolokalisiert, und das Ausstellungsland ist vorausgewählt. Hier sehen Sie, dass das bereits erkannt wurde. Wenn Ihr Workflow ohnehin nur ein Land zulässt, wird dieses automatisch ausgewählt, und die Auswahl wird dem Nutzer nie angezeigt. Dieses Beispiel ist ein KYC-Flow, für KYB oder jeden anderen Workflow, den Sie erstellen, gilt aber genau dasselbe. Die Engine führt einfach alle Schritte aus, die in Ihrem Workflow konfiguriert sind. Als Nächstes wählt der Nutzer in dieser Vorschau aus, welches amtliche Dokument er vorlegt.

​

Dokumenttyp auswählen

07:00 Didit erkennt sieben benannte Dokumenttypen. Das sind Reisepass, Personalausweis, Aufenthaltstitel, Führerschein, Krankenversichertenkarte, Steuerkarte und Sozialversicherungsausweis. Diese Liste wird jedoch auf die Typen gefiltert, die für das gerade erkannte Land tatsächlich gültig sind. Der Nutzer kann also nichts auswählen, was Didit nicht lesen kann. Auch hier gilt: Wenn Ihr Workflow nur einen einzigen Dokumenttyp zulässt, wird dieser gesamte Bildschirm übersprungen, und der Nutzer gelangt direkt zur Erfassungsseite.

​

Dokument erfassen

07:26 Wenn wir fortfahren, gelangen wir zur Erfassungsseite. Wie Sie in dieser Vorschau sehen, bin ich am Desktop, und deshalb kann ich eine Datei hochladen oder ein Foto aufnehmen. Sie können aber auch eine Live-Aufnahme erzwingen. Dann wird eine geführte Echtzeit-Aufnahme verwendet, und Uploads sind nicht erlaubt. Das ist Ihre stärkste Einstellung gegen manipulierte oder wiederverwendete Bilder. Beim Hochladen sind die üblichen Formate zulässig, also JPEG, PNG, PDF und einige weitere Dateitypen, jeweils unter 10 MB. Ist eine PDF-Datei passwortgeschützt, wird das Passwort abgefragt. Sie können also entweder Uploads zulassen oder eine Live-Aufnahme erzwingen. Alles lässt sich in den Workflow-Einstellungen konfigurieren. Wie Sie in dieser Vorschau sehen, prüft das Gerät beim Ausrichten des Dokuments Licht und Schärfe. Sobald die Aufnahme ausreichend gut ist, wird sie automatisch ausgelöst, damit die Analyse sofort beginnen kann. Dabei wird nicht nur der Text auf der Karte gelesen. Didit führt außerdem Echtheits- und Manipulationsprüfungen durch. Eine Dokument-Liveness-Prüfung erkennt Fälle wie ein Foto eines Bildschirms oder eine gedruckte Kopie. Zusätzlich werden Sicherheitsmerkmale geprüft und die MRZ-Validierung in mehr als 130 Dokumentsprachen durchgeführt. 08:37 Was dieses Verfahren wirklich auszeichnet, ist, dass alles in Echtzeit passiert. Der Nutzer erfährt sofort, wenn ein Dokument nicht funktioniert hat, und Sie erhalten genau dieselben Daten im selben Moment. Dadurch gewinnen am Ende alle an Geschwindigkeit. Für die

​

Das Liveness-Selfie

08:50 Liveness-Prüfung kann der Nutzer ein Selfie aufnehmen. Er muss sein Gesicht einfach in das Oval zentrieren, das in diesem Schritt auf dem Bildschirm erscheint, wie Sie hier sehen. Hinter dieser einfachen Oberfläche läuft eine Liveness-Prüfung, die bestätigt, dass tatsächlich ein realer Mensch vor der Kamera steht. Dadurch kann Didit das Gesicht außerdem mit dem Dokument abgleichen, das gerade eingereicht wurde. Sie können hier auswählen, welche Liveness-Methode ausgeführt wird. Und Sie können sie pro Workflow-Knoten festlegen, darauf kommen wir in anderen

​

Passiv, 3D-Flash und 3D-Aktion

09:17 Videos noch genauer ein. Es gibt drei verschiedene Einstellungen. Bei Passiv muss der Nutzer nichts tun. Bei 3D-Flash bauen farbige Lichter eine Tiefenkarte auf, und der Nutzer muss weiterhin nichts tun. Bei 3D-Aktion kommen zu den Lichtern noch eine zufällige kleine Aktion wie Blinzeln oder Kopfdrehen hinzu. Es ist also ein einziger Selfie-Schritt mit drei Liveness-Stufen, zwischen denen Sie wählen können. Also

​

Das Liveness-Video und die Scores

09:41 Schauen wir uns an, was der Liveness-Schritt Ihnen liefert. Er nimmt ein kurzes Video der Person auf und bewertet es. Wenn wir jetzt zu den Benutzerverifizierungen gehen, nach unten scrollen und einen der Benutzer auswählen, können wir uns dessen Profil ansehen. Keine Sorge, auf alles, was in dieser Verifizierungsprüfung steckt, gehen wir in einem anderen Video ein. Um Ihnen aber zu zeigen, was die Liveness-Prüfung tatsächlich leistet und was Sie in Ihrem Profil sehen, ist ein kurzes Video, das Sie hier sehen. 10:08 Wir können das Video also abspielen. Das ist zwar nur ein Demovideo zu Demonstrationszwecken, aber genau das wird bei jedem Ihrer Benutzer im Verifizierungsschritt angezeigt. Hier sehen Sie einen Liveness-Score in Prozent. Darauf gehe ich in einem anderen Video ein. Jede der Methoden, die passive wie die aktive, gibt einen Liveness-Score von 1 bis 100 aus. Zusätzlich läuft eine Erkennung von Präsentationsangriffen und Deepfakes. 10:30 Das Video wird zusammen mit dem Score gespeichert. Sie können es jederzeit erneut abspielen und jeden Score direkt hier in der Verifizierungsprüfung ablesen, ebenso im Profil des Benutzers. Sie erhalten also das Selfie-Video zusammen mit dem Liveness-Score und den Deepfake-Scores

​

Was passiert, wenn ein Schritt fehlschlägt

10:45 jederzeit abrufbar, wann immer Sie sie brauchen. Was passiert also, wenn ein Schritt fehlschlägt? Der Benutzer läuft nicht in eine Sackgasse. Er bekommt einen gezielten, geführten Wiederholungsversuch. In den Einstellungen Ihrer Workflows legen Sie die maximale Anzahl der Wiederholungsversuche und das Wiederholungsfenster fest. Auf weitere Einstellungen und die Funktionsweise der Workflows gehen wir in einem anderen Video ein. Wenn der Benutzer eine Wiederholungsmeldung sieht, ist sie präzise, etwa: Das Dokument ist abgelaufen, oder: Nehmen Sie das Dokument bei besserem Licht erneut auf. Keine vage, allgemeine Fehlermeldung. So weiß er genau, was er korrigieren muss. Wie viele Versuche er bekommt, lässt sich im Workflow konfigurieren, wie ich eben gezeigt habe. Standardmäßig lässt der Ablauf ihn so lange weiterversuchen, bis er es schafft, denn das Ziel ist, ihn abzuschließen und nicht auszusperren. Die Versuche sind also anpassbar, und der Standard ist

​

Der Bildschirm Genehmigt

11:30 so angelegt, dass der Benutzer immer ans Ende kommt. Wenn alle erforderlichen Prüfungen bestanden sind, landet er hier: ein grünes Häkchen und eine verständliche Meldung. Sie wurden verifiziert. Der Benutzer sieht, dass er nichts weiter tun muss, und kann zurück in Ihre App gehen. Und hier kommt der Teil, den er nicht sieht: Ihre App hat das Ergebnis bereits in Echtzeit erhalten, noch bevor er die Seite verlässt. Genehmigt ist also dieser grüne, beruhigende Endbildschirm und

​

Der Bildschirm In Prüfung

11:54 Ihr Backend hat die Ergebnisse bereits. Manchmal gibt eine automatische Prüfung eine Warnung aus, statt eindeutig zu bestehen oder zu scheitern. In diesem Fall sieht der Benutzer eine orangefarbene Uhr statt dieses grünen Häkchens, darunter den Text: Ihre Einreichung wird geprüft. Auf Ihrer Seite erscheint die Verifizierung dann hier unter In Prüfung. Es liegt an Ihnen oder jemandem in Ihrem Team, sie durchzulassen, ihren Antrag zu genehmigen, abzulehnen oder den Benutzer aufzufordern, mit weiteren Informationen erneut einzureichen. Das Schöne daran: Der Benutzer erhält eine E-Mail, sobald sich der Status seiner

​

Der Bildschirm Abgelehnt

12:30 Verifizierungsanfrage ändert. Wenn eine Prüfung tatsächlich fehlschlägt, sieht der Benutzer einen klaren Status Abgelehnt: ein rotes Symbol mit dem Text „Wir konnten Ihre Angaben zurzeit nicht verifizieren“. Das erklärt das Ergebnis, ohne Ihre Betrugslogik preiszugeben. Was danach passiert, bestimmt allein Ihr Workflow. Sie können ihn innerhalb des von Ihnen festgelegten Versuchsbudgets erneut einreichen lassen oder ihn in Ihrer eigenen App in einen Supportablauf leiten. Abgelehnt ist also ein klarer, nicht-technischer Endbildschirm, und

​

Weiterleitung oder Webhook: Welchem sollten Sie vertrauen?

12:58 Bildschirm, und Sie entscheiden, ob das erneutes Einreichen oder Support bedeutet. Am Ende dieses Workflows passieren zwei Dinge, und es lohnt sich zu wissen, welchem davon Sie vertrauen sollten. Zuerst wird der Browser des Benutzers zurück in Ihre App geleitet. Er landet also genau dort, wo er gestartet ist, aber dieser Teil ist für ihn nur eine Übergabe. Worauf Sie sich tatsächlich verlassen, ist das Ergebnis, das Ihr Server im selben Moment erhält: Es wird direkt an Ihr Backend gesendet, sobald die Entscheidung getroffen ist. Auf dieser Version sollten Sie Ihre Logik aufbauen. Verlassen Sie sich nie auf das, was nur im Browser liegt. Die technischen Details der Anbindung sind ein eigenes Video, deshalb heben wir sie uns für später auf. Die Kernaussage ist einfach: Der Benutzer kehrt in Ihre App zurück, und Ihr System hat das echte, vertrauenswürdige Ergebnis bereits

​

Die Sitzung in Ihrem Dashboard finden

13:41 Ergebnisse vorliegen. Jede Verifizierung erscheint im Tab Benutzerverifizierungen. Dort stehen die Filter zur Verfügung. Wir sehen genehmigt, in Prüfung und abgelehnt. Je nach Ergebnis der Verifizierung und dem durchlaufenen Workflow aktualisiert sich der Status entsprechend. Die Fälle in Prüfung verdienen natürlich die größte Aufmerksamkeit. Wir können also danach filtern und alle diese Fälle zur manuellen Prüfung anzeigen lassen. Bei jeder dieser Verifizierungsprüfungen können wir hineinklicken und jeden Nachweis sehen, auf dem das Ergebnis beruht. Und dieser Wert hier unten, die Anbieterdaten, ist die ID, die Ihr eigenes System beim Erstellen der Sitzung übermittelt hat. Sie ist Ihre dauerhafte Referenz für diese Person. 14:25 Und gruppiert Didit jede Sitzung, die dieselbe Anbieterdaten-ID verwendet, unter einem Profil?