Krypto-Börsen-Onboarding mit Claude: Eine Entscheidungssequenz für Betreiber

Wichtigste Erkenntnisse

• Claude kann die Onboarding-Entscheidungen einer Krypto-Börse koordinieren, aber der Kunde schließt die KYC-Erfassung in der von Didit gehosteten Verifizierungs-UI ab, nicht im Chat.
• didit_session_create erfordert eine vorhandene workflow_id. Es gibt eine URL zurück, die die Börse dem Kunden gibt.
• didit_transaction_screen_wallet gibt nur Screening-Ergebnisse zurück. Es hält keine Gelder zurück, erstellt keinen Fall und benachrichtigt kein Compliance-Team.
• didit_transaction_create erfordert transaction_id, transaction_category, transaction_details und subject auf oberster Ebene. Transaktionsfelder variieren je nach Kategorie.
• Der Wert des Betreibers liegt in der Entscheidungssequenz: die richtigen Beweise sammeln, sie gemäß der Börsenrichtlinie interpretieren, jede Entscheidung aufzeichnen und explizite Folgemaßnahmen auslösen.

Eine Krypto-Börse hat nicht nur eine Onboarding-Entscheidung. Sie hat eine Kette von Entscheidungen: Kann diese Person mit der Identitätsprüfung beginnen, wurde die gehostete Prüfung abgeschlossen, erfordert ein Name-Screening-Ergebnis eine Überprüfung, was bedeutet ein Wallet-Ergebnis gemäß der Richtlinie, und sollte eine übermittelte Transaktion zur Überwachung akzeptiert werden?

Der Didit Model Context Protocol (MCP)-Server ermöglicht es Claude, diese Schritte über eine authentifizierte Tool-Oberfläche zu koordinieren. Er fasst das Kundenerlebnis nicht in die Konversation zusammen und verwandelt eine Risikoreaktion nicht in ein automatisches Geldkontrollsystem. Das nützliche Muster ist ein Operator-Copilot mit expliziten Übergaben und expliziten Aktionen.

Dieser Artikel konzentriert sich auf diese Betriebssequenz. Die Mechanik hat bereits spezielle Anleitungen für KYC über MCP, Wallet-Screening über MCP und Transaktionsüberwachung über MCP.

Entscheidung 0: Umfang festlegen, bevor ein Kunde angesprochen wird

Ein Betreiber beginnt mit didit_context_get. Das Tool listet die Organisationen und Anwendungen auf, die dem authentifizierten Benutzer zur Verfügung stehen, sodass Claude den beabsichtigten Betriebskontext bestätigen kann, anstatt Kunden oder Umgebungen zu vermischen.

Die Börse benötigt auch einen bestehenden Verifizierungs-Workflow. Das Workflow-Design erfolgt vor der Kundenübergabe und bestimmt, welche Prüfungen durchgeführt werden. Für einen gängigen Krypto-Onboarding-Flow könnte dies eine ID-Verifizierung, passive Liveness, Face Match und IP-Analyse umfassen. Der veröffentlichte Preis für das vollständige KYC-Bundle für diese Prüfungen beträgt 0,33 $.

Der MCP-Aufruf empfängt keine „Workflow-Konfiguration“. didit_session_create empfängt eine workflow_id, die bereits existiert. Diese Unterscheidung macht die erste Frage des Betreibers konkret: Welcher genehmigte Workflow gilt für diesen Kunden und Markt?

Entscheidung 1: Kunden zum gehosteten KYC-Flow senden

Claude erstellt die Sitzung mit dem ausgewählten Workflow und einer stabilen Kundenreferenz. Die Antwort enthält session_id, url und session_token.

Erstellen Sie eine Verifizierungssitzung mit didit_session_create:
{
  "workflow_id": "<existing-crypto-onboarding-workflow-uuid>",
  "vendor_data": "customer_18427",
  "callback": "https://exchange.example/onboarding/complete",
  "language": "en"
}

Geben Sie die URL an den Kunden zurück und behalten Sie die session_id für die Entscheidungsabfrage bei.

Der Kunde öffnet diese URL und schließt die erforderliche Erfassung in der von Didit gehosteten Benutzeroberfläche ab. Identitätsdokumentbilder und das Selfie werden dort eingereicht. Sie verbleiben nicht im Claude-Chat.

Nachdem der Kunde fertig ist, ruft Claude didit_session_get_decision mit session_id auf. Das Tool gibt die vollständige Verifizierungsentscheidung und die extrahierten Daten für den konfigurierten Workflow zurück. Der Betreiber kann dann die Überprüfungsrichtlinie der Börse auf die tatsächliche Antwort anwenden. Dies ist ein Übergabe- und Abruf-Loop, keine Behauptung, dass Approved jede nachgeschaltete Compliance-Frage löst.

Entscheidung 2: Identitätsnachweise vom Namensrisiko trennen

Identitätsprüfung und Anti-Geldwäsche (AML)-Screening beantworten unterschiedliche Fragen. Nach dem Lesen der verifizierten Identitätsdaten kann Claude didit_verify_aml mit dem vollständigen Namen der Person aufrufen. Optionale Eingaben wie Geburtsdatum und Nationalität können die Treffergenauigkeit verbessern. AML-Screening kostet 0,20 $ pro Prüfung über 1.300+ Listen.

Die Entscheidung des Betreibers ist nicht einfach „Treffer oder kein Treffer“. Ein Ergebnis kann einen Vergleich mit den verifizierten Kundendaten, eine Dokumentation der Begründung oder eine manuelle Überprüfung gemäß der Richtlinie der Börse erfordern. Wenn der Betreiber entscheidet, dass ein Fall erforderlich ist, ist didit_case_create ein separater expliziter Tool-Aufruf. Nichts an der KYC-Sitzung erstellt diesen Fall stillschweigend.

Diese Trennung hält den Audit-Trail lesbar:

• KYC-Nachweis: was der gehostete Verifizierungs-Workflow zurückgegeben hat.
• AML-Nachweis: was die Namens-Screening-Antwort zurückgegeben hat.
• Betreiberentscheidung: wie die Richtlinie der Börse diese Antworten zu Genehmigung, Überprüfung oder Ablehnung zugeordnet hat.

Entscheidung 3: Wallet prüfen, dann entscheiden, was zu tun ist

didit_transaction_screen_wallet akzeptiert wallet_address, blockchain und eine optionale direction. Der blockchain-Enum ist ein gemischter Asset- oder Kettenbezeichner: Er enthält Kettenbezeichner wie BTC, ETH, SOL und TRX sowie Asset-Bezeichner wie USDT und USDC. USDT und USDC sind Assets, keine Blockchains.

Das Folgende ist eine ausführbare Claude-Eingabeaufforderung mit der genauen MCP-Payload-Form. Ersetzen Sie die Beispieladresse durch die Wallet des Kunden:

Rufen Sie didit_transaction_screen_wallet mit genau dieser Payload auf:
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "deposit"
}

Geben Sie die Antwortfelder risk_score, severity, sanctions_hit sowie die gemeldete
Herkunft und das Ziel der Gelder zurück. Halten Sie keine Gelder zurück, erstellen Sie keinen Fall und benachrichtigen Sie niemanden.
Bitten Sie nach der Zusammenfassung des Screening-Ergebnisses um eine explizite Anweisung zur Nachverfolgung.

Die Antwortform ist ein Screening-Ergebnis: risk_score, severity, sanctions_hit und Informationen zur Herkunft/Ziel der Gelder. Das Tool kann eine 409-Antwort zurückgeben, wenn die Screening-Konfiguration der Transaktionsüberwachung nicht verfügbar ist.

Wallet-Screening, auch bekannt als Know Your Transaction (KYT) im Produktkatalog, kostet 0,15 $ pro Prüfung. Das Ergebnis selbst bewegt kein Geld. Eine Sperrung, Freigabe, ein Fall, eine Eskalation oder Benachrichtigung gehört zur eigenen Richtlinie der Börse und erfordert ein separates System oder eine Tool-Aktion. Zum Beispiel kann Claude didit_case_create nur aufrufen, nachdem der Betreiber oder eine autorisierte Richtlinienebene diese Aktion explizit ausgewählt hat.

Entscheidung 4: Eine Transaktion mit dem realen Schema übermitteln

didit_transaction_create übermittelt eine Transaktion zur Überwachung und Regelauswertung. Die erforderlichen Top-Level-Felder sind:

• transaction_id: die eindeutige Transaktionskennung der Börse.
• transaction_category: einer der dokumentierten Kategoriewerte, einschließlich finance, kyc, travel_rule und user_event.
• transaction_details: die kategoriespezifische Transaktions-Payload.
• subject: die Partei, die die Transaktion initiiert.

Optionale Top-Level-Objekte umfassen counterparty, travel_rule_details, network_snapshot und custom_properties. Das Tool definiert Transaktions-Hash, Quelladresse, Zieladresse, Asset oder Betrag nicht als universelle Top-Level-Felder. Wenn diese Werte Teil der Daten einer Kategorie sind, gehören sie in das entsprechende kategoriespezifische Objekt.

Der Top-Level-Vertrag für didit_transaction_create lautet:
{
  "transaction_id": "<exchange-unique-transaction-id>",
  "transaction_category": "finance",
  "transaction_details": { "<finance-category fields>": "<values>" },
  "subject": { "<initiating-party fields>": "<values>" },
  "counterparty": { "<other-party fields>": "<values>" },
  "transaction_at": "<ISO timestamp>"
}

Die Platzhalter sind beabsichtigt. Das MCP-Schema besagt, dass transaction_details und subject von transaction_category abhängen; es veröffentlicht keine universelle verschachtelte Payload. Ein Betreiber sollte die für die konfigurierte Kategorie definierten Felder verwenden, anstatt ein erfundenes Krypto-Schema zu kopieren.

Für travel_rule gilt derselbe Top-Level-Vertrag, mit kategoriespezifischen Übertragungsdaten in transaction_details, der initiierenden Partei in subject, der anderen Partei in counterparty und Travel Rule-Daten in travel_rule_details. Es gibt kein metadata-Feld in diesem Tool. Die Auswahl von travel_rule identifiziert die kategoriespezifische Payload; es führt nicht automatisch eine Überprüfung des Begünstigten durch oder klärt die Übertragung.

Die Transaktion wird bei der Übermittlung ausgewertet. Es ist ungenau, einen einzelnen übermittelten Datensatz als kontinuierlich und für immer neu bewertet zu beschreiben. Claude kann die überwachte Transaktion und ihr Regelauswertungsergebnis mit didit_transaction_get abrufen.

Entscheidung 5: Richtlinienerstellung in der Business Console belassen

Der Regel-Builder für die Transaktionsüberwachung der Business Console ist der Ort, an dem Teams Überwachungsregeln und Richtlinienlogik konfigurieren. Es ist nicht der Editor für Verifizierungs-Workflows. Die MCP-Oberfläche übermittelt Transaktionen, ruft Ergebnisse ab, durchsucht Datensätze und unterstützt explizite Falloperationen; sie ersetzt nicht die Regelerstellung.

Fallaktionen sind ebenfalls begrenzt. didit_case_manage unterstützt assign, comment, escalate, reopen, resolve und update. Workflows für Verdachtsmeldungen (SAR) bleiben Operationen der Business Console. Diese Grenze ermöglicht es einer Börse, Claude für die Beweissammlung und die Unterstützung des Betreibers zu nutzen, ohne den Agenten als autonome Compliance-Behörde zu beschreiben.

Den Operator-Copilot verbinden

Didits gehosteter MCP-Endpunkt stellt 115 Tools über Streamable HTTP bereit und verwendet OAuth 2.1 mit Proof Key for Code Exchange (PKCE). Der MCP-Server ist kostenlos; die zugrunde liegenden Prüfungen folgen ihren veröffentlichten Preisen. Die kostenlose Stufe umfasst 500 kostenlose Verifizierungen pro Monat.

Verbinden Sie das gehostete Claude mit dem Didit Connector Deep Link. Überprüfen Sie die MCP-Übersicht, die Authentifizierungsanleitung und die Tool-Referenz. Die Implementierung ist im MIT-lizenzierten GitHub-Repository verfügbar, und die Produktübersicht finden Sie unter didit.me/developers/mcp.

Das dauerhafte Betriebsmuster ist: zuerst der Beweis, zweitens die Richtlinie, drittens die Aktion. Claude sammelt die KYC-Entscheidung, das AML-Ergebnis, das Wallet-Ergebnis und die Transaktionsbewertung. Die Börse bleibt explizit darüber, welche Antwort welche Entscheidung verursacht hat und welche separate Aktion folgte.