Allgemeine Einstellungen
Score-Schwellenwerte
Score-Schwellenwerte bestimmen, wie der kumulierte Risiko-Score der übereinstimmenden Regeln einem Transaktionsstatus zugeordnet wird:
Transaktionen unterhalb der Prüfschwelle werden automatisch als
APPROVED eingestuft. Wenn eine Regel eine explizite change_status-Aktion besitzt, hat dieser Status Vorrang vor den Score-Schwellenwerten. DECLINED setzt sich dabei immer durch.
Eine Senkung der Prüfschwelle erhöht die Menge der Transaktionen, die zur manuellen Prüfung markiert werden. Passen Sie den Wert an die Kapazität Ihres Teams und Ihre Risikobereitschaft an.
Krypto-Überwachung
Aktivieren oder deaktivieren Sie das automatische Krypto-Screening für Kryptowährungstransaktionen. Bei Aktivierung screent Didit die Adressen von Wallets und Transaktions-Hashes bei Blockchain-Analyseanbietern für alle Transaktionen mitcurrency_kind: "crypto". Das Screening von Transaktions-Hashes erfordert sowohl den Hash als auch die zugehörige Adresse.
Anbieterpräferenzen
Wählen Sie Ihren bevorzugten Blockchain-Analyseanbieter aus und konfigurieren Sie ihn:
Wenn Sie Ihren eigenen Anbieterschlüssel verbinden, nutzen Sie Ihren bestehenden Vertrag mit dem Anbieter und zahlen die aufgeführte Infrastrukturgebühr pro Screening über Didit.
Die Überwachung des Lightning Network ist nur mit einer Elliptic- oder Chainalysis-BYOK-Verbindung verfügbar, die über Marketplace hinzugefügt wurde.
Wird
LIGHTNING übermittelt, während ein anderer Anbieter aktiv ist, oder bevor eine der beiden unterstützten Verbindungen hinzugefügt wurde, gibt die Screening-Anfrage 400 mit Hinweisen zur Einrichtung im Marketplace zurück.
Remediation-Workflow
Der Remediation-Workflow (remediation_workflow_id in der Settings-API) ist Ihr anwendungsweiter Standard für AWAITING_USER-Regelaktionen, die keinen eigenen Workflow angeben. In der Praxis betrifft das die integrierten Bibliotheksregeln, da benutzerdefinierte Regeln immer ihre eigene Auswahl enthalten, die Vorrang hat.
Das Feld akzeptiert beim Schreiben eine Workflow-ID (oder eine bestimmte Versions-UUID) und gibt beim Lesen immer die stabile Workflow-ID zurück. Sitzungen werden mit der neuesten veröffentlichten Version erstellt.
Wenn eine solche Regel eine Transaktion auf AWAITING_USER setzt, erstellt Didit die verknüpfte Verifizierungssitzung mit dem ersten gefundenen Workflow in dieser Reihenfolge:
- Der hier konfigurierte Remediation-Workflow.
- Der Workflow für Biometrische Authentifizierung Ihrer Anwendung, sofern die Person bereits ein gespeichertes Referenzgesicht hat.
- Der Standard-Workflow Ihrer Anwendung.
action_required und remediation der Transaktion sowie in beiden Transaktions-Webhooks zurückgegeben, sodass Sie den Benutzer zur Durchführung der erforderlichen Verifizierung weiterleiten können.
Sobald für diese Sitzung eine Entscheidung getroffen wurde, folgt der Transaktionsstatus dieser Entscheidung automatisch (genehmigt, abgelehnt oder in Prüfung), und ein transaction.status.updated-Webhook wird ausgelöst.
Ein Workflow für die Biometrische Authentifizierung ist hier die empfohlene Wahl: Der Benutzer weist seine Identität erneut mit einem Live-Selfie nach, das mit dem Gesicht aus dem ursprünglichen Onboarding abgeglichen wird.
Dafür muss die Person ein gespeichertes Referenzgesicht aus einer genehmigten Verifizierung haben. Benutzer ohne ein solches Referenzgesicht werden stattdessen gebeten, den Standard-Workflow Ihrer Anwendung abzuschließen, wobei auf der Transaktion ein Hinweis zu diesem Austausch vermerkt wird.
Wo Sie es finden
Navigieren Sie in der Business Console zu Transaktionen > Einstellungen, um diese Optionen zu konfigurieren. Einstellungen werden sofort für alle neuen Transaktionen wirksam.Nächste Schritte
Risiko-Scoring
Wie Score-Schwellenwerte Status zugeordnet werden.
Krypto-Screening
Wallet-Screening und Details zu den Anbietern.
IP-Anreicherung
Welche IP-Daten Regeln zur Verfügung stehen.