Was geprüft wird
Wenn Ihr Team das Element zuerst entscheidet, endet der Durchlauf des Investigators ohne Entscheidung.
Der Bericht
Jeder Bericht enthält:- eine Empfehlung: genehmigen, ablehnen, weitere Informationen anfordern (erneute Einreichung bei einer Verifizierung, Warten auf den Benutzer bei einer Transaktion) oder eskalieren,
- eine Konfidenz: hoch, mittel oder niedrig,
- eine Zusammenfassung und die Begründung,
- Belege: Jeder Punkt ist als unbedenklich, als Risiko, als einen Blick wert, als erläutert oder als Kontext markiert und nennt seine Quellen,
- bei Screening-Treffern, ob jeder Treffer dieselbe Person betrifft, nicht dieselbe Person betrifft oder unklar ist,
- vorgeschlagene nächste Schritte, etwa das Öffnen eines verknüpften Datensatzes oder eines Falls.
Angegebene Quellen
Der Investigator liest dieselben Daten, die Ihre Prüfer in der Konsole und in der API sehen: die Entscheidung zur Verifizierung, die Entscheidung zur Unternehmensverifizierung, die Transaktionsdetails oder die Falldetails. Er kann außerdem verknüpfte Sitzungen, Transaktionen und Fälle öffnen. Jeder Belegpunkt nennt den Abschnitt des Datensatzes, den er gelesen hat, oder den verknüpften Datensatz, den er geöffnet hat. Der Bericht zeigt außerdem Was ich geprüft habe: die Übersicht, die Abschnitte und die Datensätze, die er in dieser Reihenfolge gelesen hat. Er arbeitet nur mit diesem Datensatz. Bevor der Datensatz das Modell erreicht, entfernt Didit Medien, Links und interne Kennungen und maskiert geschützte Merkmale. Der Investigator kann keine Daten ändern. Er schreibt nur seinen Bericht.Phasen
Führen Sie den Beobachtungsmodus 7, 14 (Standard) oder 30 Tage lang durch, bevor Sie live gehen. Einrichtung, Beobachtungsmodus und Backtests werden nie berechnet.
Autonomiestufen
Legen Sie für jede Warteschlange eine Autonomiestufe fest:
Der Investigator entscheidet nur dann selbstständig, wenn alle der folgenden Bedingungen erfüllt sind:
- die Anwendung ist live, die Warteschlange steht auf Automatisch oder Vollautomatisch und ist nicht pausiert,
- Ihre Teamrichtlinie deckt das Element ab und sieht vor, die empfohlene Aktion auszuführen,
- keine Leitplanke hält das Element zurück,
- seine Übereinstimmung mit den bisherigen Entscheidungen Ihres Teams erreicht den Schwellenwert, und zwar über mindestens 20 Entscheidungen in den letzten 90 Tagen,
- das Element wird nicht für die Qualitätsstichprobe ausgewählt, liegt innerhalb des Rollout-Anteils, und das tägliche Limit ist nicht erreicht.
Um eine Warteschlange auf Automatisch oder Vollautomatisch zu stellen, führen Sie zuerst einen Backtest mit früheren Entscheidungen durch und bestätigen das Ergebnis. Die Warteschlangen Fälle und AML werden nie stapelweise angenommen, und eskalierte Fälle oder Fälle, die auf einen zweiten Prüfer warten, werden nie automatisch entschieden.
Leitplanken
Diese Regeln sind immer aktiv und können nicht geändert werden:- Sanktionstreffer gehen immer an eine Person.
- Betrugs- und AML-Gründe erreichen nie Endbenutzer.
- Keine Entscheidung beruht auf geschützten Merkmalen.
- Der Investigator reicht nie eine regulatorische Meldung ein.
- Jede Entscheidung wird protokolliert und kann überstimmt werden.
Einen Bericht prüfen
Auf der Stufe Vorschlagen kann ein Prüfer:- die Empfehlung Akzeptieren,
- sie Bearbeiten und annehmen,
- sie Überstimmen, mit einer Kategorie (fehlender Kontext, benötigt Informationen, Richtlinie weicht ab, Beleg falsch gelesen, anderes) und einer Begründung von 10 bis 500 Zeichen,
- Stapelweise annehmen für bis zu 50 Elemente mit dem Status Bereit zur Annahme nutzen.
Teamrichtlinie
Jede Warteschlange hat eine Teamrichtlinie: Ihre Regeln dafür, was genehmigt, abgelehnt oder eskaliert wird. Der Investigator folgt ihr, und er entscheidet nur dort selbstständig, wo die Richtlinie das Element abdeckt. Richtlinien werden versioniert. Auf der Registerkarte Fragen werden Punkte gesammelt, die Ihr Team für den Investigator klären soll.Audit-Trail
Der Tab Aktivität erfasst jeden Bericht, jede Annahme, jede Bearbeitung, jede Überschreibung, jede automatisierte Entscheidung, jede Zurückhaltung durch Guardrails und jede Änderung der Einstellungen, jeweils mit Angabe des Urhebers: der Ermittler, eine Person, ein API-Schlüssel oder das System. Einträge können nicht bearbeitet werden. Sie können bis zu 10.000 Einträge als CSV exportieren. Jede Entscheidung, die der Ermittler selbstständig trifft, wird außerdem im Audit-Log Ihrer Organisation festgehalten, unter Der Ermittler und mit dem zugehörigen Bericht verknüpft, neben den Aktionen Ihrer Mitglieder und API-Schlüssel.Preise
Der Ermittler hat einen einzigen Preis: $0.20 pro geprüfter Verifizierung (KYC, KYB oder AML-Treffer), Transaktions-Alert oder Fall. Dafür liest er den Datensatz, erstellt einen mit Quellen belegten Bericht mit seiner Empfehlung und übergibt ihn entweder an Ihren Prüfer oder entscheidet innerhalb Ihrer Richtlinie selbstständig.
Sie werden pro Vorgang einmal belastet, und zwar nur, wenn die Anwendung live ist und der Bericht angenommen oder bearbeitet und anschließend angenommen wird oder wenn der Ermittler selbstständig entscheidet. Überschreibungen, Vorgänge, die Ihr Team an anderer Stelle entschieden hat, fehlgeschlagene Läufe, Schattenmodus, Einrichtung und Backtests sind kostenlos. Tarifrabatte gelten.
Legen Sie optional unter Einstellungen ein monatliches Ausgabenlimit fest. Ist das Limit erreicht, gelangen neue Vorgänge ohne Bericht zu Ihren Prüfern.
API und Webhooks
Die Investigator-API ist unterhttps://verification.didit.me/v3/investigator/ erreichbar und verwendet den API-Schlüssel Ihrer Anwendung (x-api-key).
Ein eingeschränkter API-Schlüssel benötigt den Scope
decisions, um Berichte zu lesen und Aktionen für sie auszuführen, und den Scope applications, um Einstellungen zu lesen oder zu ändern. Transaktionsberichte benötigen außerdem den Scope transactions. Schlüssel, die auf einzelne Workflows oder auf genehmigte Sitzungen beschränkt sind, werden abgelehnt, weil die Warteschlange alle Workflows umfasst. Die vollständigen Anfrage- und Antwortschemas finden Sie in openapi-25.json unter dem Tag Investigator.
Es gibt keinen eigenen Investigator-Webhook. Das decision in einem status.updated-Webhook und in GET /v3/session/{id}/decision/ enthält einen investigator-Block mit status, recommendation, confidence, summary, ready_to_accept, automated und decided_by (investigator oder member) des Laufs.
Verwandte Seiten
Manuelle Prüfung
So prüft Ihr Team Verifizierungssitzungen.
Fälle
Fallmanagement für Alerts und Ermittlungen.