Entscheidungsregeln und Schwellenwerte
Jede Prüfung erzeugt Warnungen, und Sie entscheiden, was jede Warnung auslöst - Bestehen, Review oder Ablehnung. Diese Zuordnung ist der Ort, an dem Ihre Risikobereitschaft tatsächlich lebt.
Jeder Schritt ordnet seine Warnungen einer Aktion zu: Bestehen, Review oder Ablehnung. Ein Schritt, der auf Ablehnung konfiguriert ist, stoppt den Workflow - spätere Schritte laufen nie, und Sie werden für sie nicht abgerechnet. Das macht die Reihenfolge der Regeln sowohl zu einer Risiko- als auch zu einer Kostenentscheidung.
#Wo Entscheidungen tatsächlich getroffen werden
Es liegt nahe, sich einen Workflow als "die Prüfungen, die ich ausführe" vorzustellen. Die Prüfungen sind nur die halbe Miete. Die andere Hälfte - und die Hälfte, die Ihre Genehmigungsquote bestimmt - ist, wozu die Warnungen jeder Prüfung konfiguriert sind.
- Jeder Feature-Knoten trägt seine eigenen Schwellenwerte und seine eigene Entscheidung.
- Eine Prüfung kann verpflichtend oder optional sein, was selbst eine Entscheidung darüber ist, wer durchkommt.
- Eine geänderte Regel erreicht neue Sessions, sobald der Workflow gespeichert wird.
Für jeden Schritt wird jede Warnung, die er auslösen kann, einer von drei Aktionen zugeordnet:
| Aktion | Wirkung |
|---|---|
| Approve (oder ignorieren) | Die Warnung wird protokolliert, ändert aber das Ergebnis nicht |
| Review | Die Session geht zu In Review, damit eine Person entscheidet |
| Decline | Die Session wird abgelehnt, und der Workflow stoppt |
Diese Zuordnung ist Ihre Richtlinie, ausgedrückt in Konfiguration.
#Eine Ablehnung stoppt den Workflow
Das ist das Verhalten, das die meisten überrascht, es lohnt sich also, es explizit zu sagen: wenn ein Schritt ablehnt, stoppt die Ausführung dort. Die darauffolgenden Schritte laufen nie.
Zwei Konsequenzen:
- Dem Ergebnis fehlen Prüfungen, die Sie erwartet haben. Sie sind nicht fehlgeschlagen - sie wurden nie ausgeführt. Eine bei der ID-Verifizierung abgelehnte Session hat keine Liveness-Prüfung, keinen Gesichtsabgleich, kein AML.
- Sie werden für sie nicht abgerechnet. Die Abrechnung erfolgt pro abgeschlossenem Feature, ein nie ausgeführter Schritt kostet also nichts.
#Die Reihenfolge der Regeln zur Kostensteuerung nutzen
Da eine Ablehnung den Ablauf stoppt, ist die Reihenfolge der Schritte ein Kostenhebel. Eine günstige Risikoprüfung vor ein teures Bündel zu setzen bedeutet, dass Traffic, der ohnehin nie durchgekommen wäre, stoppt, bevor Sie für den teuren Teil zahlen.
Geräte- und IP-Analyse zu 0,03 $ vor einem vollständigen KYC-Ablauf ist das Standardbeispiel: sie filtert den Traffic, den Sie ohnehin abgelehnt hätten, günstig heraus.
Der Kompromiss betrifft Nutzererlebnis und False Positives. Geräte- und IP-Signale sind die verrauschtesten Prüfungen, die Didit bietet - Unternehmensnetzwerke, Carrier-NAT und Cloud-Browser stellen echte Nutzer alle hinter gemeinsame Adressen. Einen gesamten Ablauf darauf zu gaten, blockiert echte Kunden. Leiten Sie sie deshalb zu review statt zu decline, solange Sie Ihren eigenen Traffic nicht gemessen haben.
#Regeln, die Urteilsvermögen statt Automatisierung brauchen
Manche Warnungen sind eindeutig und sollten ablehnen: eine fehlgeschlagene MRZ-Prüfsumme, ein Chip, dessen Signatur sich nicht bis zum Aussteller zurückverfolgen lässt, ein Gesicht auf Ihrer Blocklist. Das sind Integritätsfehler.
Andere sind fast immer besser als Review geeignet:
- Teilweise Adressübereinstimmungen bei Adressnachweisen - die Formate unterscheiden sich je nach Land.
- Teilweise Namensübereinstimmungen bei Database Validation - autoritative Quellen erfassen Namen unterschiedlich.
- AML-Kandidatentreffer mit niedriger Konfidenz - häufige Namen erzeugen sie ständig.
- Ein grenzwertiger Gesichtsabgleich - siehe Gesichtsabgleich-Scores und Schwellenwerte.
- Eine Duplicate-Face-Markierung - was bei einem neuen Konto Betrug bedeutet und bei einem wiederkehrenden Kunden normal ist.
Und manche sind Usability-Fehler, die einen Retry verdienen, kein Urteil: ein nicht gelesener NFC-Chip, eine unscharfe Aufnahme, ein verlorenes Kameraframe.
#Altersrichtlinien
Mindest- und Höchstalter werden pro Workflow konfiguriert, und die Aktion bei einem Verstoß liegt bei Ihnen. MINIMUM_AGE_NOT_MET kann direkt ablehnen, oder zu Review leiten, wenn Ihre Richtlinie eine Ausnahme mit Nachweis erlaubt. Beides ist legitim; wählen Sie bewusst.
#Eigene Regeln auf extrahierten Daten
Über die Zuordnung pro Warnung hinaus können Sie Regeln gegen die von einem Schritt extrahierten Daten schreiben - zum Beispiel eine Ablehnung, wenn ein extrahiertes Feld einen bestimmten Wert annimmt. Zwei Dinge, die Sie beachten sollten:
- Die Regel kann nur auf Daten wirken, die der Schritt tatsächlich erzeugt hat. Wenn OCR das Feld nicht extrahiert hat, hat die Regel nichts zu bewerten.
- Eine ablehnende Regel stoppt weiterhin den Workflow, mit denselben Konsequenzen wie oben.
Wenn Sie eine Regel bauen, die auf ein geschütztes Merkmal reagiert, behandeln Sie das als rechtliche Frage für Ihr Compliance-Team, bevor es eine technische wird.
#Testen Sie die Regeln, nicht nur die Schritte
Die Schritte eines Workflows lassen sich leicht mit bloßem Auge prüfen. Seine Regeln nicht - der einzige Weg zu wissen, dass eine Warnung dorthin führt, wo Sie es erwarten, ist, diese Warnung tatsächlich hervorzurufen.
Dafür gibt es die Sandbox. Jedes Szenario erzwingt genau eine bestimmte Warnung, sodass Sie die Aktion jeder Regel durchgängig bestätigen können: decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match und so weiter. Siehe Testen in der Sandbox.
Testen Sie den Review-Pfad genauso sorgfältig wie den Ablehnungspfad. Eine Regel, die zu Review leitet, ist nur nützlich, wenn jemand die Warteschlange tatsächlich bearbeitet, und der Weg herauszufinden, ob Ihr Review-Prozess funktioniert, ist, eine synthetische Session hindurchzuschicken, bevor ein echter Kunde wartet.
#Änderungen gelten für neue Sessions
Das Bearbeiten eines Workflows ändert bereits erstellte Sessions nicht rückwirkend. Eine Session trägt die Konfiguration, mit der sie erstellt wurde, testen Sie nach einer Regeländerung also mit einer neuen Session statt eine alte erneut zu prüfen.