Eine Risikorichtlinie entwerfen

Was passiert hier?

Mit dem Workflow-Richtlinien-Designer legen Sie fest, wie eine Verifizierung genehmigt, abgelehnt oder zur manuellen Prüfung geschickt wird. Das geschieht visuell und ohne Code. Sie ziehen Regelblöcke auf eine Arbeitsfläche, legen Bedingungen auf die Signale fest, die jede Verifizierung erzeugt (Vertrauenswert, Sanktionstreffer, Dokumentprüfungen, Land des Antragstellers, Netzwerkrisiko, Nachweis der Live-Kamera und mehr), und verbinden sie mit den Ergebnissen Genehmigen, Ablehnen, Eskalieren oder Live-Verifizierung verlangen.

Jede Organisation startet mit einer eingebauten Standardrichtlinie. Sie bildet den Standard-Entscheid von Certivant mit 17 Faktoren für den Vertrauenswert exakt nach. Das Einschalten der Funktion ändert daher nichts, solange Sie nicht selbst anpassen. Ihre bisherigen Ergebnisse bleiben identisch.

Bevor Sie beginnen

• Ihr Tarif muss den Workflow-Richtlinien-Designer enthalten (Pro oder höher). Zeigt der Eintrag Workflow-Richtlinien im Menü Entwickler das Badge „Erfordert Pro“, bitten Sie Ihren Kontoinhaber um ein Upgrade. Siehe Abrechnung & Guthaben.
• Sie sollten verstehen, wie eine Verifizierung bewertet wird, damit Sie wissen, auf welche Signale Sie Regeln schreiben können. Siehe KYC- und KYB-Verifizierungsanfragen prüfen.
• Das Veröffentlichen einer Richtlinie ändert, wie künftige Verifizierungen für Ihre gesamte Organisation entschieden werden. Vergangene Anfragen werden dadurch nicht neu entschieden.

Zentrale Begriffe

• Knoten — die Blöcke auf der Arbeitsfläche. Ein Start-Knoten beginnt den Ablauf. Bedingungs-Knoten enthalten die Regeln. Ende-Knoten sind die Ergebnisse (Genehmigt / Abgelehnt / Eskaliert / Manuelle Prüfung / Live-Verifizierung verlangen / An eine andere Richtlinie übergeben). Aktionsknoten (Formular, ID-Validierung, E-Mail, SMS, Webhook, Live-Konferenz) dokumentieren Orchestrierungsschritte rund um die Entscheidung. Um Schritte auszuführen, verwenden Sie die Automatisierungs-Workflows.
• Bedingungen — ein Bedingungsknoten prüft die Signale der Verifizierung, z. B. overallScore >= 75, sanctions.isMatch = true, applicant.country IN ["IR","KP","SY"] oder redFlags CONTAINS "network_vpn_detected". Sie können Prüfungen mit UND / ODER / NICHT kombinieren und Gruppen verschachteln, auch Bedingungen, die auf der Arbeitsfläche hinter anderen Bedingungen hängen.
• Der erste Treffer gewinnt — Regeln werden von oben nach unten ab dem Start ausgewertet. Die erste Bedingung, deren Prüfung wahr ist, liefert die Entscheidung. Ein abschließender Auffangzweig erfasst alles andere. Er endet sicher bei Eskalieren, niemals bei einer stillen Genehmigung.
• Begründungen — geben Sie einer Bedingung eine Begründung (z. B. „Hochrisikoland“). Sie wird mit der Entscheidung gespeichert. Ein Prüfer sieht dann warum eine Anfrage eskaliert wurde und nicht nur, welche Regel gegriffen hat.
• Versionen — jede gespeicherte Richtlinie ist ein Entwurf, bis Sie sie veröffentlichen. Beim Veröffentlichen wird diese Version eingefroren (unveränderlich) und aktiv. Die bisher aktive Version dieser Richtlinie wird archiviert. Um eine veröffentlichte Richtlinie zu ändern, klicken Sie auf Neue Version. So haben Sie immer eine vollständige, prüfbare Historie.
• Anwendungsbereich — eine veröffentlichte Richtlinie entscheidet über die Anfragen jedes Formulars, das sie anheftet. Machen Sie eine Richtlinie zum Organisations-Standard, damit sie auch alle anderen Anfragen entscheidet, einschließlich der über die API angelegten. Ohne beides entscheidet die eingebaute Standardrichtlinie von Certivant.

Schritte

Was die Richtlinie startet

Eine Workflow-Richtlinie läuft automatisch. Es gibt keine Schaltfläche „Ausführen“, und Sie lösen sie nicht von Hand aus. Zwei Dinge aktivieren und starten sie:

1. Das Veröffentlichen aktiviert sie. Wenn Sie eine Richtlinie veröffentlichen, wird diese Version aktiv. Pro Richtlinie gibt es genau eine aktive Version. Beim Veröffentlichen wird die vorherige archiviert. Die Richtlinie entscheidet über die Anfragen jedes Formulars, das sie anheftet, und nach dem Festlegen als Organisations-Standard über alle anderen Anfragen.
2. Jede neue Verifizierung löst sie aus. Immer dann, wenn eine Verifizierung läuft (ein Antragsteller reicht Dokumente ein, Sie senden eine Verifizierungsanfrage oder ein Prüfer klickt auf Erneut verifizieren), führt Certivant die vollständige Prüfkette aus (OCR, Biometrie, Sanktionen, Betrug, Netzwerk- und Aufnahmeprüfungen, der Vertrauenswert mit 17 Faktoren). Danach übergibt Certivant die Ergebnisse an die entscheidende Richtlinie. Das Urteil der Richtlinie (Genehmigen / Ablehnen / Eskalieren / Live-Verifizierung verlangen) wird zum endgültigen Status der Anfrage.

Welche Richtlinie eine Anfrage entscheidet, folgt dieser Reihenfolge:

1. die Richtlinie, die ihr Formular anheftet;
2. sonst die Organisations-Standardrichtlinie;
3. sonst die eingebaute Standardrichtlinie von Certivant.

Hat eine angeheftete oder Standardrichtlinie keine aktive Version (etwa weil Sie sie archiviert haben), greift die eingebaute Standardrichtlinie. Niemals greift eine andere Richtlinie.

flowchart LR
    A[Applicant submits<br/>verification] --> B[Checks run:<br/>OCR · biometrics ·<br/>sanctions · fraud]
    B --> C[17-factor<br/>trust score]
    C --> D{Active policy<br/>evaluates the<br/>score + signals}
    D -->|first matching rule| E[Approve]
    D --> F[Reject]
    D --> G[Escalate to<br/>manual review]

Wie sich Ihre Verifizierungen dadurch ändern

Nach dem Veröffentlichen entscheidet Ihre aktive Richtlinie jede neue Verifizierung anstelle der eingebauten Standardrichtlinie. Für jede Anfrage erfasst Certivant:

• die ID, den Namen und die Version der Richtlinie, die entschieden hat, und
• die Liste der ausgelösten Regeln.

Beides steht im Audit-Protokoll der Anfrage und im Webhook-Payload (data.policy bei kyc.request.approved / rejected / escalated). So sehen Ihre nachgelagerten Systeme, welche Richtlinie und welche Regeln jede Entscheidung bestimmt haben. Siehe Webhooks.

Ändert eine spätere Sicherung das Ergebnis der Richtlinie (etwa eine KYB-Anfrage, die noch auf ihre Registerprüfung wartet, oder eine Anfrage im Testmodus), erfasst das Audit-Protokoll diese Überschreibung und den endgültigen Status. So zeigt die Historie nie eine Entscheidung, die nicht Bestand hatte.

Live-Verifizierung verlangen

Wählen Sie Live-Verifizierung verlangen als Ergebnis eines Ende-Knotens. Dann wird eine Anfrage zu einem Videoanruf geschickt, statt allein anhand der Dokumente entschieden zu werden. Das ist sinnvoll, wenn der Wert grenzwertig ist, der Antragsteller ein VPN nutzt oder das Selfie nicht nachweislich von der Live-Kamera stammt:

overallScore >= 60 AND overallScore < 80 → Require live verification
network.vpn = true OR capture.tokenMismatch = true → Require live verification

Die Anfrage geht in den Status Eskaliert. Ihre Seite zeigt den Banner Live-ID-Verifizierung erforderlich mit der Begründung der Regel, damit Ihr Team weiß, dass ein Anruf gebucht werden muss. Der Webhook enthält data.policy.decision = "live_verification" und liveVerificationRequired: true.

Um den Anruf automatisch zu buchen, fügen Sie einen Automatisierungs-Workflow mit dem Auslöser Live-Verifizierung erforderlich und der Aktion Live-ID-Verifizierung planen hinzu. Sobald der Gastgeber im Anruf eine Entscheidung erfasst, wird die Anfrage genehmigt oder abgelehnt, und die üblichen Ereignisse genehmigt / abgelehnt werden ausgelöst. Bei einer erneuten Verifizierung danach kann die Richtlinie das Ergebnis des Anrufs auslesen, z. B. liveVerification.hostDecision = "approved". So kann eine Regel eine Anfrage genehmigen, die die Live-Prüfung bestanden hat.

Testbare Signale

Neben dem Vertrauenswert und den Ergebnissen je Prüfung (checks.*, sanctions.*, document.*, applicant.*) kann eine Bedingung folgende Werte lesen:

Ein Feld, das die Anfrage nicht hat (kein Anruf stattgefunden, kein Barcode gelesen …), trifft nie zu, auch nicht bei !=, NOT IN oder NOT CONTAINS. Daher ist document.issuingCountry != "US" falsch, wenn kein Dokument gelesen wurde, und nicht stillschweigend wahr.

Optionen und Felder

Fehlerbehebung

Ich sehe „Workflow-Richtlinien“ nicht im Menü

Der Eintrag liegt im Menü Entwickler und ist ein Pro-Merkmal. Zeigt der Eintrag Workflow-Richtlinien das Badge „Erfordert Pro“, enthält Ihr Tarif ihn nicht. Bitten Sie Ihren Eigentümer um ein Upgrade in Abrechnung & Guthaben. Fehlt das Menü Entwickler ganz, sind Sie möglicherweise kein Admin oder Eigentümer. Ist der Eintrag einfach verschwunden, laden Sie die Seite neu. Die Tarifprüfung wird einige Minuten zwischengespeichert.

Ich kann eine Richtlinie nicht bearbeiten, die Felder sind gesperrt

Veröffentlichte Versionen sind absichtlich unveränderlich. Öffnen Sie die Version und klicken Sie in der Werkzeugleiste auf Neue Version. Das kopiert die Richtlinie in den nächsten bearbeitbaren Entwurf. Nehmen Sie Ihre Änderungen vor und veröffentlichen Sie. Bis dahin entscheidet die bisherige Version weiter.

Die Schaltfläche Simulieren ist deaktiviert

Simulieren setzt voraus, dass die Richtlinie einmal gespeichert wurde. Klicken Sie auf Entwurf speichern. Danach simuliert die Funktion, was auf der Arbeitsfläche steht, auch mit nicht gespeicherten Änderungen.

Meine veröffentlichte Richtlinie entscheidet nichts

Eine veröffentlichte Richtlinie entscheidet nur über die Anfragen von Formularen, die sie anheften. Heften Sie sie im Formular an (Formulareinstellungen → Entscheidungsrichtlinie), oder klicken Sie im Editor auf Für alle Anfragen verwenden, um sie zum Organisations-Standard zu machen.

Eine Anfrage wurde mit „Live-ID-Verifizierung erforderlich“ eskaliert

Ihre Richtlinie hat eine Regel Live-Verifizierung verlangen getroffen. Der Banner auf der Anfrage zeigt die Begründung der Regel. Buchen Sie einen Live-Anruf von der Anfrageseite aus oder automatisieren Sie ihn mit einem Workflow (siehe Live-Verifizierung verlangen).

Eine Bedingung zeigt ein rotes Badge „ungültig“

Der Ausdruck konnte nicht gelesen werden. Öffnen Sie die Bedingung, prüfen Sie den Feldnamen und den Operator und stellen Sie sicher, dass Werte in Listen durch Kommas getrennt sind. Der Reiter Raw DSL zeigt die genaue Meldung des Parsers.

Wie löse ich meinen Workflow aus, und wann läuft er?

Sie lösen ihn nicht von Hand aus. Sobald er veröffentlicht und auf einem Formular angeheftet (oder zum Organisations-Standard gemacht) ist, läuft er automatisch bei jeder neuen Verifizierung, die er abdeckt. Das passiert, wenn ein Antragsteller Dokumente einreicht, wenn Sie eine Verifizierungsanfrage senden oder wenn ein Prüfer auf Erneut verifizieren klickt. Siehe Was die Richtlinie startet.

Ich habe veröffentlicht, aber es passiert nichts

Es gibt drei häufige Ursachen. Erstens entscheidet eine Richtlinie nur Verifizierungen, die nach ihrer Aktivierung laufen. Bereits abgeschlossene Anfragen bleiben unberührt (siehe unten). Starten Sie eine neue Verifizierung oder verwenden Sie Erneut verifizieren bei einer bestehenden, um zu sehen, wie Ihre Richtlinie sie entscheidet. Zweitens prüfen Sie, dass die Version, die Sie bearbeitet haben, im Dashboard tatsächlich den Status aktiv zeigt. Ein gespeicherter Entwurf wird nicht aktiviert. Dafür müssen Sie Veröffentlichen klicken. Drittens prüfen Sie, ob das Formular der Anfrage die Richtlinie anheftet oder ob die Richtlinie der Organisations-Standard ist.

Veröffentlichen hat bei einer laufenden Anfrage nichts geändert

Richtlinien entscheiden nur neue Verifizierungen. Eine bereits eingereichte Anfrage behält die Entscheidung der damals aktiven Richtlinie. Führen Sie sie nur dann erneut aus, wenn Sie sie neu entscheiden möchten. Öffnen Sie die Anfrage und verwenden Sie Erneut verifizieren.

Versionshistorie, Wiederherstellung und A/B-Tests

Jedes Speichern einer veröffentlichten Richtlinie beginnt eine neue Entwurfsversion. Veröffentlichen friert sie als unveränderliche Version ein und archiviert die Version, die sie ersetzt. Jede Entscheidung erfasst die genaue ID und Version der Richtlinie, die sie getroffen hat (in der Anfrage, im Audit-Protokoll und im Block policy des Webhook-Payloads). So sehen Sie jederzeit, welche Version eine Verifizierung entschieden hat.

Klicken Sie im Kopfbereich des Editors auf Versionen & A/B-Test, um:

• jede Version der Richtlinie zu sehen (Entwurf, aktiv und archiviert) und jede davon schreibgeschützt zu öffnen.
• Als neuen Entwurf wiederherstellen — kopiert eine ältere Version in einen neuen Entwurf mit demselben Namen. Veröffentlichen Sie ihn, wenn er live gehen soll. Veröffentlichte Versionen werden nie verändert.
• Einen A/B-Test ausführen — vergleicht die aktive Version (Variante A) mit einem Herausforderer (Variante B, ein Entwurf oder eine ältere Version derselben Richtlinie). Wählen Sie den Anteil der neuen Verifizierungen, der an B geht (0–100 %). Der Rest bleibt bei A. Die Aufteilung ist automatisch und stabil. Eine Verifizierung landet immer in derselben Variante, auch wenn sie erneut ausgeführt wird.

Während ein Test läuft, ist der Entwurf des Herausforderers eingefroren. Eine Bearbeitung würde den Vergleich ungültig machen. Die Tabelle Ergebnisse zeigt je Variante, wie viele Verifizierungen zugewiesen wurden, den Anteil genehmigter, abgelehnter und eskalierter Fälle sowie wie viele zu einer Entscheidung kamen. Der Vergleich der Genehmigungsquoten gilt erst als aussagekräftig, wenn jede Variante mindestens 30 entschiedene Verifizierungen hat. Um B zu übernehmen, veröffentlichen Sie den Herausforderer. Der Test endet dann automatisch. Um ihn abzubrechen, klicken Sie auf Test beenden. Jede neue Verifizierung geht dann zurück zur aktiven Version.

Verwandte Themen

• KYC- und KYB-Verifizierungsanfragen prüfen — hier stammen die Signale her, die Ihre Regeln prüfen.
• Webhooks — der Block policy bei Entscheidungsereignissen.
• Automatisierungs-Workflows — auf die Entscheidung reagieren: Live-Anruf buchen, benachrichtigen, weiterleiten.
• Live-ID-Verifizierung — der Videoanruf, den eine Regel Live-Verifizierung verlangen anfordert.
• Abrechnung & Guthaben — Upgrade, um den Workflow-Richtlinien-Designer freizuschalten.