KYC-Prüfungen in Claude per Chat durchführen

Wichtigste Erkenntnisse

• Verbinden Sie Claude über OAuth (Open Authorization) 2.1 mit PKCE (Proof Key for Code Exchange) mit Didits Model Context Protocol (MCP) Server – kein API-Schlüssel (Application Programming Interface) erforderlich, und Ihre bestehende Didit-Rolle und Berechtigungen werden exakt übernommen.
• 115 Tools in 11 Kategorien ermöglichen Ihnen das Suchen, Prüfen, Korrigieren, Überprüfen, Genehmigen und Ablehnen von Know Your Customer (KYC)-Sitzungen vollständig aus dem Claude-Chatfenster heraus.
• Ein Compliance-Analyst kann die gesamte „In Überprüfung“-Warteschlange bearbeiten: Entscheidungen prüfen, falsch gelesene Felder überschreiben, Notizen für den Audit-Trail hinterlassen, genehmigen oder ablehnen und eine teilweise erneute Übermittlung anfordern – alles ohne die Business Console zu öffnen.
• Das MCP agiert als der angemeldete Didit-Benutzer mit der genauen Organisationsrolle dieses Benutzers – ein Analyst kann in Claude nichts tun, was er nicht auch in der Konsole tun könnte. Dies beantwortet direkt die Frage des Compliance-Beauftragten: Berechtigungen werden nicht umgangen.
• Didit bedient über 2.000 Unternehmen in Produktion; die Modellausführung läuft mit sub-2s p99. Das vollständige KYC-Paket kostet 0,33 US-Dollar, und jede Funktion beinhaltet 500 kostenlose Verifizierungen pro Monat.

Die KYC-Verifizierung ist ein täglicher Arbeitsablauf für Compliance-Teams. Sitzungen werden zur manuellen Überprüfung markiert. Dokumente werden gescannt, Daten extrahiert, und ein gewisser Prozentsatz fällt immer an einen menschlichen Prüfer, der sie sortieren muss. Dieser Prüfer verbringt seinen Tag normalerweise damit, zwischen einer Business Console und einem Warteschlangenverwaltungstool hin- und herzuschalten und Sitzung für Sitzung durchzuklicken.

Es gibt einen schnelleren Weg. Mit Didits Model Context Protocol (MCP)-Server, der mit Claude verbunden ist, kann ein Compliance-Analyst die gesamte Überprüfungswarteschlange von einem einzigen Chatfenster aus bearbeiten. Suchen Sie nach Sitzungen, die sich in Überprüfung befinden, lesen Sie, warum jede markiert wurde, überprüfen Sie das vollständige Entscheidungsobjekt, korrigieren Sie einen falsch gelesenen Nachnamen oder ein Geburtsdatum, hinterlassen Sie eine Prüfernotiz, genehmigen oder lehnen Sie ab mit einem vollständigen Audit-Trail und fordern Sie die erneute Übermittlung nur der fehlgeschlagenen Schritte an – alles ohne die Konversation zu verlassen.

So funktioniert's

Die Einrichtung des Konnektors und der OAuth-Flow werden im Claude Installationshandbuch behandelt. Für die tägliche Überprüfung ist die wichtige Grenze einfach: Jeder Tool-Aufruf läuft mit der bestehenden Organisationsrolle des angemeldeten Didit-Benutzers, sodass Claude eine Sitzung nicht genehmigen oder bearbeiten kann, wenn dieser Benutzer die entsprechende Berechtigung nicht besitzt.

Fügen Sie den Didit-Konnektor zu Claude hinzu. Die Implementierung und der Self-Hosting-Code sind im öffentlichen GitHub-Repository unter der MIT-Lizenz verfügbar.

Die tägliche KYC-Überprüfungswarteschlange in Claude

Der MCP-Server stellt 115 Tools in 11 Kategorien zur Verfügung. Für einen Compliance-Analysten, der KYC-Sitzungen überprüft, sieht der relevante Arbeitsablauf wie folgt aus:

1. Arbeitsbereich entdecken

Beginnen Sie mit didit_context_get. Dieser einzelne Aufruf gibt jede Organisation und Anwendung zurück, auf die Sie zugreifen können, einschließlich der Standardorganisation und -anwendung. Er ersetzt das ältere mehrstufige Erkennungsmuster und ermöglicht Ihnen, sofort mit der Arbeit zu beginnen.

Call didit_context_get. State the selected organization and application, and do not read or change any session yet.

2. Überprüfungsbedürftige Sitzungen finden

Führen Sie didit_session_search mit status: "In Review" aus. Dies durchsucht alle Ihre Apps und Organisationen in einem Aufruf und gibt Sitzungen zurück, die mit ihrer Organisation und App gekennzeichnet sind, die neuesten zuerst. Sie können nach Datumsbereich mit last_n_days filtern oder in einen bestimmten Workflow mit workflow_id eintauchen.

Find sessions with status “In Review” using last_n_days: 1. State the date_from and date_to boundaries, then return session_id, workflow, created time, and any observed review reason. Do not call write tools.

last_n_days ist eine Abkürzung für Kalenderdaten: Es legt date_from und date_to fest. Es ist kein rollierender 24-Stunden-Filter. Übergeben Sie explizite JJJJ-MM-TT-Daten, wenn Ihre Überprüfungsrichtlinie eine andere Grenze erfordert.

3. Die vollständige Entscheidung prüfen

Rufen Sie für jede markierte Sitzung didit_session_get_decision mit ihrer Sitzungs-ID auf. Dies gibt die vollständige Entscheidung und die extrahierten Daten zurück, die vom konfigurierten Workflow dieser Sitzung erzeugt wurden. Abhängig von den Modulen in diesem Workflow kann die Antwort Identitätsdokumentenfelder, Liveness- und Face-Match-Ergebnisse, AML-Screening-Ausgabe (Anti-Money Laundering), Betrugssignale und Überprüfungsnachweise enthalten. Erwarten Sie keine Module, die der Workflow nicht ausgeführt hat.

Retrieve the full decision for session SESSION_UUID. Separate observed fields, failed checks, conflicting evidence, and missing data. Do not recommend a status yet.

4. Falsch gelesene Daten korrigieren

OCR (Optical Character Recognition) kann ein Zeichen falsch lesen – eine „0“, die ein „O“ sein sollte, ein akzentuierter Buchstabe, den OCR abflacht, eine nicht übereinstimmende Datumsformatierung. Verwenden Sie didit_session_update_data, um jedes extrahierte Feld zu überschreiben: Vorname, Nachname, Geburtsdatum, Dokumentennummer, Ausstellungsstaat, Adresse, Geschlecht, Nationalität, Familienstand und dokumentspezifische Zusatzfelder. Senden Sie nur die Felder, die korrigiert werden müssen; alles andere bleibt wie extrahiert.

For session SESSION_UUID, change only last_name to “Muñoz”. Show the proposed field update and wait for my approval before calling didit_session_update_data.

5. Eine Audit-Trail-Notiz hinterlassen

Verwenden Sie didit_session_add_review, um einen Prüferkommentar zum Audit-Trail der Sitzung hinzuzufügen. Sie können optional den Sitzungsstatus als Teil desselben Aufrufs ändern – zum Beispiel, verschieben Sie ihn auf „In Überprüfung“, wenn Sie aktiv daran arbeiten, oder auf „Genehmigt“, wenn Ihre Prüfung abgeschlossen ist. Jede Notiz und jeder Statusübergang wird protokolliert und mit einem Zeitstempel versehen.

Add this review comment to session SESSION_UUID without changing its status: “Surname corrected after comparison with the document visual zone.”

6. Genehmigen, ablehnen oder erneute Übermittlung anfordern

Wenn die Überprüfung schlüssig ist, verwenden Sie didit_session_update_status, um den endgültigen Status auf Approved oder Declined zu setzen, mit einem optionalen Kommentar und einer E-Mail-Benachrichtigung. Verwenden Sie eine Aufforderung, die die autorisierte Entscheidung explizit macht:

Update session SESSION_UUID to Approved with the comment “Manual review completed under policy v4.2.” Do not change extracted identity data.

Die teilweise erneute Übermittlung ist strenger als eine konversationelle Bezeichnung. nodes_to_resubmit muss die genauen fehlgeschlagenen Knoten-IDs enthalten, die für diese Sitzung zurückgegeben wurden. Werte wie liveness oder blurred document page sind Beschreibungen, keine ausführbaren Knoten-IDs. Fragen Sie zuerst:

From the decision for session SESSION_UUID, list the exact failed node identifiers that are eligible for resubmission. Do not change the session.

Nachdem Sie diese Bezeichner überprüft haben, verwenden Sie sie wörtlich:

Set session SESSION_UUID to Resubmitted and pass these exact nodes_to_resubmit values: ["EXACT_NODE_ID_1", "EXACT_NODE_ID_2"]. Add the comment “Retry only the failed configured steps.”

Der gesamte Arbeitsablauf – finden, prüfen, korrigieren, notieren, entscheiden – findet in Claude statt. Suchen und Lesen erzeugen keine Prüfer-Audit-Einträge. Die Schreib-Tools haben unterschiedliche Effekte: didit_session_update_data wendet eine Korrektur an, didit_session_add_review erstellt eine Prüfernotiz und didit_session_update_status protokolliert eine Statusänderung mit einem optionalen Audit-Trail-Kommentar.

Die 10 Sitzungsstatus und ihre Bedeutung

Beim Suchen oder Überprüfen von Sitzungen filtern Sie nach Status. Didit verfolgt 10 Status im Laufe des Sitzungslebenszyklus:

• Nicht gestartet – Die Sitzung wurde erstellt und der Verifizierungslink generiert, aber der Benutzer hat ihn noch nicht geöffnet.
• In Bearbeitung – Der Benutzer hat den Verifizierungsfluss geöffnet und führt aktiv Schritte aus.
• In Überprüfung – Die Sitzung befindet sich derzeit in der Warteschlange für die menschliche Überprüfung. Sie kann dorthin durch konfigurierte Workflow-Logik oder eine manuelle Statusänderung eines autorisierten Prüfers gelangt sein.
• Genehmigt – Der aktuelle Entscheidungsstatus der Sitzung ist genehmigt. Dieser Status kann vom konfigurierten Workflow oder von einer manuellen Statusüberschreibung eines autorisierten Prüfers stammen; er beweist nicht, dass jede mögliche Prüfung durchgeführt oder bestanden wurde.
• Abgelehnt – Der aktuelle Entscheidungsstatus der Sitzung ist abgelehnt. Er kann die konfigurierte Workflow-Logik oder eine manuelle Statusüberschreibung eines autorisierten Prüfers widerspiegeln, lesen Sie daher die zurückgegebenen Beweise, anstatt das Label als Liste der fehlgeschlagenen Prüfungen zu behandeln.
• Abgelaufen – Das Zeitfenster der Sitzung ist abgelaufen, bevor der Benutzer die Verifizierung abgeschlossen hat.
• Abgebrochen – Der Benutzer hat den Ablauf gestartet, aber nicht beendet.
• Kyc abgelaufen – Die KYC-Daten selbst sind veraltet (z. B. wurde nach der Verifizierung ein abgelaufenes Ausweisdokument erkannt).
• Erneut eingereicht – Der Analyst hat eine teilweise erneute Einreichung angefordert, und der Benutzer wurde aufgefordert, nur die fehlgeschlagenen Schritte erneut durchzuführen.
• Wartet auf Benutzer – Eine Know Your Business (KYB)-Hauptsitzung wartet, während die erforderlichen untergeordneten KYC-Parteien ihre Verifizierung abschließen.

Berechtigungen und Sicherheit

Der Einwand des Compliance-Beauftragten gegen jedes KI-verbundene Tool (Künstliche Intelligenz) ist einfach: Kann ein Agent im Chat etwas tun, was einem menschlichen Prüfer in der Konsole nicht erlaubt wäre? Mit Didits MCP-Server lautet die Antwort nein. Das MCP authentifiziert sich als der angemeldete Didit-Benutzer über OAuth 2.1 mit PKCE – jeder Tool-Aufruf erbt die Organisationsrolle dieses Benutzers. Die Business Console und der MCP-Server erzwingen die gleichen Privilegienprüfungen gegenüber demselben Berechtigungs-Backend in service-didit-auth.

Ein Analyst kann Sitzungen überprüfen, Daten korrigieren und genehmigen oder ablehnen, nur im Rahmen der Berechtigungen, die seine Rolle bereits gewährt. Ein Entwickler, der das MCP verbindet, kann Workflows erstellen und Webhooks verwalten, wenn seine Rolle dies zulässt. Das MCP selbst führt keine neuen Berechtigungen ein. Es ist eine andere Schnittstelle zum selben Autorisierungsmodell.

Für wen ist das gedacht

Dieser Workflow wurde für Compliance-Analysten entwickelt, die bereits wissen, wie man eine KYC-Sitzung überprüft. Das MCP automatisiert nicht das Urteilsvermögen des Prüfers – es eliminiert den Kontextwechsel. Anstatt einen Browser zu öffnen, sich in der Konsole anzumelden, die richtige Sitzungsseite zu finden, durch Tabs zu klicken und in Formulare zu tippen, beschreibt der Analyst in natürlicher Sprache, was er möchte, und Claude führt die Abfolge der Tools aus.

Es ist auch nützlich für Compliance-Leiter, die die Überprüfungswarteschlange von ihrem Telefon aus überprüfen möchten, und für die Einarbeitung neuer Analysten, die den Überprüfungsprozess lernen können, indem sie Claude dabei zusehen, wie es die Entscheidungsdaten einer Sitzung durchgeht und Muster markiert.

Wann stattdessen die Konsole verwenden

Einige Aktionen verbleiben in der Business Console. Der MCP-Server in Claude verwaltet sitzungsbezogene Überprüfungs- und Verwaltungsaktionen. Für Massenvorgänge wie die Installation von Regelpaketen, das Testen von Regeländerungen oder das Einreichen eines Berichts über verdächtige Aktivitäten (SAR) befinden sich diese Funktionen in den Benutzeroberflächen für Transaktionsüberwachung und Fallmanagement der Konsole. Die Fallmanagement-Tools des MCP kümmern sich um die Triage – didit_case_manage unterstützt Zuweisen, Kommentieren, Eskalieren, Wiedereröffnen, Lösen und Aktualisieren – aber die SAR-Einreichung und die Konfiguration der Regel-Engine sind reine Konsolen-Workflows.

Erste Schritte

Verbinden Sie Claude mit Didits MCP-Server über Ihre Claude-Konnektoreinstellungen. Der Server ist kostenlos, der gehostete Endpunkt erfordert keine Installation, und die vollständige Tool-Referenz finden Sie unter docs.didit.me.

Wenn Sie neu in der MCP-Einrichtung sind, beginnen Sie mit dem Installationshandbuch oder der Didit MCP-Entwicklerseite. Für einen Überblick über den Sitzungslebenszyklus und was passiert, wenn eine Verifizierung läuft, lesen Sie KYC mit dem Didit MCP-Server. Den Tool-Katalog finden Sie in der MCP-Tool-Referenz.

Didit ist Infrastruktur für Identität und Betrug. 115 MCP-Tools. 0,33 US-Dollar für ein komplettes KYC-Paket. 500 kostenlose Verifizierungen pro Monat für jede Funktion. Über 2.000 Unternehmen in Produktion. Verbinden Sie Claude, melden Sie sich an und beginnen Sie mit der Überprüfung.