Onboarding d'intercanvi de criptomonedes amb Claude: una seqüència de decisions de l'operador

Punts clau

• Claude pot coordinar les decisions d'onboarding d'un intercanvi de criptomonedes, però el client completa la captura de Know Your Customer (KYC) a la UI de verificació allotjada de Didit, no dins del xat.
• didit_session_create requereix un workflow_id existent. Retorna una URL que l'intercanvi proporciona al client.
• didit_transaction_screen_wallet només retorna els resultats de l'anàlisi. No reté fons, crea un cas ni notifica a un equip de compliment.
• didit_transaction_create requereix transaction_id, transaction_category, transaction_details i subject al nivell superior. Els camps de transacció varien segons la categoria.
• El valor de l'operador és la seqüència de decisions: recollir les proves correctes, interpretar-les segons la política de l'intercanvi, registrar cada decisió i activar explícitament qualsevol acció de seguiment.

Un intercanvi de criptomonedes no té una única decisió d'onboarding. Té una cadena de decisions: pot aquesta persona iniciar la verificació d'identitat, la comprovació allotjada es va completar, un resultat de cribratge de noms requereix revisió, què significa un resultat de cartera segons la política i s'ha d'acceptar una transacció enviada per a la monitorització?

El servidor del Protocol de Context del Model (MCP) de Didit permet a Claude coordinar aquests passos a través d'una única superfície d'eines autenticades. No redueix l'experiència del client a la conversa, i no converteix una resposta de risc en un sistema automàtic de control de fons. El patró útil és un copilot de l'operador amb transferències explícites i accions explícites.

Aquest article se centra en aquesta seqüència operativa. Els mecanismes ja tenen guies dedicades per a KYC mitjançant MCP, anàlisi de carteres mitjançant MCP, i monitorització de transaccions mitjançant MCP.

Decisió 0: establir l'abast abans de contactar amb un client

Un operador comença amb didit_context_get. L'eina enumera les organitzacions i aplicacions disponibles per a l'usuari autenticat, de manera que Claude pot confirmar el context operatiu previst en lloc de barrejar clients o entorns.

L'intercanvi també necessita un flux de treball de verificació existent. El disseny del flux de treball es fa abans de la transferència al client i determina quines comprovacions s'executen. Per a un flux d'onboarding de criptomonedes comú, això podria incloure verificació d'identitat, prova de vida passiva, coincidència facial i anàlisi d'IP. El preu publicat del paquet KYC complet per a aquestes comprovacions és de 0,33 $.

La crida MCP no rep una "configuració del flux de treball". didit_session_create rep un workflow_id que ja existeix. Aquesta distinció fa que la primera pregunta de l'operador sigui concreta: quin flux de treball aprovat s'aplica a aquest client i mercat?

Decisió 1: enviar el client al flux KYC allotjat

Claude crea la sessió amb el flux de treball seleccionat i una referència de client estable. La resposta conté session_id, url i session_token.

Crea una sessió de verificació amb didit_session_create:
{
  "workflow_id": "<uuid-de-flux-de-treball-onboarding-cripto-existent>",
  "vendor_data": "client_18427",
  "callback": "https://exchange.example/onboarding/complete",
  "language": "ca"
}

Retorna la url al client i conserva el session_id per a la cerca de decisions.

El client obre aquesta URL i completa la captura requerida a la UI allotjada de Didit. Les imatges del document d'identitat i el selfie s'envien allà. No romanen dins del xat de Claude.

Després que el client hagi acabat, Claude crida a didit_session_get_decision amb session_id. L'eina retorna la decisió de verificació completa i les dades extretes per al flux de treball configurat. L'operador pot llavors aplicar la política de revisió de l'intercanvi a la resposta real. Això és un bucle de transferència i recuperació, no una afirmació que Approved resolgui totes les qüestions de compliment posteriors.

Decisió 2: separar l'evidència d'identitat del risc de nom

La verificació d'identitat i el cribratge Anti-Money Laundering (AML) responen a preguntes diferents. Després de llegir les dades d'identitat verificades, Claude pot cridar didit_verify_aml amb el nom complet de la persona. Les entrades opcionals com la data de naixement i la nacionalitat poden millorar la precisió de la coincidència. El cribratge AML costa 0,20 $ per comprovació en més de 1.300 llistes.

La decisió de l'operador no és simplement "coincidència o no coincidència". Un resultat pot requerir una comparació amb les dades del client verificades, la documentació del raonament o una revisió manual segons la política de l'intercanvi. Si l'operador decideix que es necessita un cas, didit_case_create és una crida d'eina explícita separada. Res de la sessió KYC no crea aquest cas de forma silenciosa.

Aquesta separació manté el registre d'auditoria llegible:

• Evidència KYC: el que va retornar el flux de treball de verificació allotjat.
• Evidència AML: el que va retornar la resposta de cribratge de noms.
• Decisió de l'operador: com la política de l'intercanvi va mapar aquestes respostes per aprovar, revisar o denegar.

Decisió 3: analitzar la cartera i després decidir què fer

didit_transaction_screen_wallet accepta wallet_address, blockchain i una direction opcional. L'enumeració blockchain és un identificador mixt d'actiu o cadena: inclou identificadors de cadena com BTC, ETH, SOL i TRX, i identificadors d'actiu com USDT i USDC. USDT i USDC són actius, no blockchains.

A continuació es mostra un missatge de Claude executable amb la forma exacta de la càrrega útil de MCP. Substitueix l'adreça d'exemple per la cartera del client:

Crida didit_transaction_screen_wallet amb exactament aquesta càrrega útil:
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "dipòsit"
}

Retorna els camps de resposta risk_score, severity, sanctions_hit, i l'origen i destinació dels fons informats. No retenguis fons, creis un cas ni notifiquis a ningú.
Demana una instrucció de seguiment explícita després de resumir el resultat de l'anàlisi.

La forma de la resposta és un resultat de cribratge: risk_score, severity, sanctions_hit i informació sobre l'origen/destinació dels fons. L'eina pot retornar una resposta 409 quan la configuració de cribratge de la monitorització de transaccions no està disponible.

L'anàlisi de carteres, també anomenat know your transaction (KYT) al catàleg de productes, costa 0,15 $ per comprovació. El resultat per si mateix no mou diners. Una retenció, alliberament, cas, escalada o notificació pertany a la política pròpia de l'intercanvi i requereix un sistema separat o una acció de l'eina. Per exemple, Claude pot cridar didit_case_create només després que l'operador o una capa de política autoritzada triïn explícitament aquesta acció.

Decisió 4: enviar una transacció amb l'esquema real

didit_transaction_create envia una transacció per a la monitorització i l'avaluació de regles. Els seus camps de nivell superior requerits són:

• transaction_id: l'identificador de transacció únic de l'intercanvi.
• transaction_category: un dels valors de categoria documentats, inclosos finance, kyc, travel_rule i user_event.
• transaction_details: la càrrega útil de transacció específica de la categoria.
• subject: la part que inicia la transacció.

Els objectes de nivell superior opcionals inclouen counterparty, travel_rule_details, network_snapshot i custom_properties. L'eina no defineix el hash de la transacció, l'adreça d'origen, l'adreça de destinació, l'actiu o l'import com a camps universals de nivell superior. Si aquests valors formen part de les dades d'una categoria, pertanyen a l'objecte específic de la categoria pertinent.

El contracte de nivell superior per a didit_transaction_create és:
{
  "transaction_id": "<id-de-transacció-únic-de-l'intercanvi>",
  "transaction_category": "finances",
  "transaction_details": { "<camps-de-categoria-finances>": "<valors>" },
  "subject": { "<camps-de-part-iniciadora>": "<valors>" },
  "counterparty": { "<camps-d'altres-parts>": "<valors>" },
  "transaction_at": "<timestamp-ISO>"
}

Els marcadors de posició són deliberats. L'esquema MCP estableix que transaction_details i subject depenen de transaction_category; no publica una càrrega útil anidada universal. Un operador hauria d'utilitzar els camps definits per a la categoria configurada en lloc de copiar un esquema cripto inventat.

Per a travel_rule, s'aplica el mateix contracte de nivell superior, amb dades de transferència específiques de la categoria a transaction_details, la part iniciadora a subject, l'altra part a counterparty i les dades de la Regla de Viatge a travel_rule_details. No hi ha cap camp metadata en aquesta eina. La selecció de travel_rule identifica la càrrega útil específica de la categoria; no realitza automàticament la verificació del beneficiari ni autoritza la transferència.

La transacció s'avalua quan s'envia. És inexacte descriure un únic registre enviat com a reavaluat contínuament per sempre. Claude pot recuperar la transacció monitoritzada i el seu resultat d'avaluació de regles amb didit_transaction_get.

Decisió 5: mantenir l'autoria de polítiques a la Business Console

El constructor de regles de monitorització de transaccions de la Business Console és on els equips configuren les regles de monitorització i la lògica de la política. No és l'editor de flux de treball de verificació. La superfície de MCP envia transaccions, recupera resultats, cerca registres i admet operacions explícites de casos; no substitueix l'autoria de regles.

Les accions de cas també estan limitades. didit_case_manage admet assign, comment, escalate, reopen, resolve i update. Els fluxos de treball d'Informes d'activitat sospitosa (SAR) continuen sent operacions de la Business Console. Aquest límit permet que un intercanvi utilitzi Claude per a la recollida de proves i l'assistència de l'operador sense descriure l'agent com una autoritat de compliment autònoma.

Connecta el copilot de l'operador

L'endpoint MCP allotjat de Didit exposa 115 eines a través de HTTP transmissible i utilitza OAuth 2.1 amb Proof Key for Code Exchange (PKCE). El servidor MCP és gratuït; les comprovacions subjacents segueixen els seus preus publicats. El nivell gratuït és de 500 verificacions gratuïtes al mes.

Connecta Claude allotjat amb el enllaç profund del connector de Didit. Revisa la descripció general de MCP, la guia d'autenticació i la referència de les eines. La implementació està disponible al repositori de GitHub amb llicència MIT, i la descripció general del producte es troba a didit.me/developers/mcp.

El patró operatiu durador és primer l'evidència, segon la política, tercer l'acció. Claude recopila la decisió KYC, el resultat AML, el resultat de la cartera i l'avaluació de la transacció. L'intercanvi roman explícit sobre quina resposta va causar quina decisió i quina acció separada va seguir.