Onboarding des plateformes d'échange de cryptomonnaies avec Claude : Séquence de décision de l'opérateur

Points clés à retenir

• Claude peut coordonner les décisions d'onboarding d'un échange de cryptomonnaies, mais le client effectue la capture de la vérification d'identité (KYC) dans l'interface utilisateur d'identification hébergée de Didit, et non dans le chat.
• didit_session_create nécessite un workflow_id existant. Il renvoie une URL que l'échange fournit au client.
• didit_transaction_screen_wallet ne renvoie que les résultats du contrôle. Il ne détient pas de fonds, ne crée pas de dossier et n'informe pas une équipe de conformité.
• didit_transaction_create nécessite transaction_id, transaction_category, transaction_details et subject au niveau supérieur. Les champs de transaction varient selon la catégorie.
• La valeur de l'opérateur réside dans la séquence de décision : collecter les bonnes preuves, les interpréter selon la politique de l'échange, enregistrer chaque décision et déclencher explicitement toute action de suivi.

Un échange de cryptomonnaies n'a pas une seule décision d'onboarding. Il a une chaîne de décisions : cette personne peut-elle commencer la vérification d'identité, la vérification hébergée est-elle terminée, un résultat de contrôle de nom nécessite-t-il un examen, que signifie un résultat de portefeuille selon la politique, et une transaction soumise doit-elle être acceptée pour surveillance ?

Le serveur du protocole de contexte de modèle (MCP) de Didit permet à Claude de coordonner ces étapes via une surface d'outil authentifiée unique. Il ne réduit pas l'expérience client à la conversation, et il ne transforme pas une réponse au risque en un système automatique de contrôle des fonds. Le modèle utile est un copilote opérateur avec des transferts et des actions explicites.

Cet article se concentre sur cette séquence opérationnelle. Les mécanismes ont déjà des guides dédiés pour le KYC via MCP, le contrôle de portefeuille via MCP et la surveillance des transactions via MCP.

Décision 0 : Établir la portée avant de contacter un client

Un opérateur commence par didit_context_get. L'outil liste les organisations et applications disponibles pour l'utilisateur authentifié, afin que Claude puisse confirmer le contexte opérationnel prévu au lieu de mélanger les clients ou les environnements.

L'échange a également besoin d'un flux de vérification existant. La conception du flux de travail a lieu avant le transfert au client et détermine les vérifications à effectuer. Pour un flux d'onboarding crypto courant, cela pourrait inclure la vérification d'identité, la détection de vivacité passive, la correspondance faciale et l'analyse IP. Le prix du bundle KYC complet publié pour ces vérifications est de 0,33 $.

L'appel MCP ne reçoit pas de « configuration de flux de travail ». didit_session_create reçoit un workflow_id qui existe déjà. Cette distinction rend la première question de l'opérateur concrète : quel flux de travail approuvé s'applique à ce client et à ce marché ?

Décision 1 : Envoyer le client vers le flux KYC hébergé

Claude crée la session avec le flux de travail sélectionné et une référence client stable. La réponse contient session_id, url et session_token.

Créez une session de vérification avec didit_session_create :
{
  "workflow_id": "<uuid-de-flux-de-travail-onboarding-crypto-existant>",
  "vendor_data": "customer_18427",
  "callback": "https://exchange.example/onboarding/complete",
  "language": "en"
}

Retournez l'URL au client et conservez le session_id pour la recherche de décision.

Le client ouvre cette URL et effectue la capture requise dans l'interface utilisateur hébergée de Didit. Les images des documents d'identité et le selfie y sont soumis. Ils ne restent pas dans le chat Claude.

Une fois que le client a terminé, Claude appelle didit_session_get_decision avec session_id. L'outil renvoie la décision de vérification complète et les données extraites pour le flux de travail configuré. L'opérateur peut alors appliquer la politique d'examen de l'échange à la réponse réelle. Il s'agit d'une boucle de transfert et de récupération, et non d'une affirmation selon laquelle Approuvé résout toutes les questions de conformité en aval.

Décision 2 : Séparer les preuves d'identité du risque de nom

La vérification d'identité et le contrôle anti-blanchiment d'argent (AML) répondent à des questions différentes. Après avoir lu les données d'identité vérifiées, Claude peut appeler didit_verify_aml avec le nom complet de la personne. Des entrées facultatives telles que la date de naissance et la nationalité peuvent améliorer la précision de la correspondance. Le contrôle AML coûte 0,20 $ par vérification sur plus de 1 300 listes.

La décision de l'opérateur n'est pas simplement « correspondance ou non ». Un résultat peut nécessiter une comparaison avec les données client vérifiées, une documentation du raisonnement ou un examen manuel selon la politique de l'échange. Si l'opérateur décide qu'un cas est nécessaire, didit_case_create est un appel d'outil explicite distinct. Rien dans la session KYC ne crée silencieusement ce cas.

Cette séparation maintient la piste d'audit lisible :

• Preuve KYC : ce que le flux de vérification hébergé a renvoyé.
• Preuve AML : ce que la réponse du contrôle de nom a renvoyé.
• Décision de l'opérateur : comment la politique de l'échange a mappé ces réponses pour approuver, examiner ou refuser.

Décision 3 : Contrôler le portefeuille, puis décider quoi faire

didit_transaction_screen_wallet accepte wallet_address, blockchain et une direction facultative. L'énumération blockchain est un identifiant mixte d'actif ou de chaîne : elle inclut des identifiants de chaîne tels que BTC, ETH, SOL et TRX, et des identifiants d'actif tels que USDT et USDC. USDT et USDC sont des actifs, pas des blockchains.

Voici une invite Claude exécutable avec la forme exacte de la charge utile MCP. Remplacez l'adresse d'exemple par le portefeuille du client :

Appelez didit_transaction_screen_wallet avec précisément cette charge utile :
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "deposit"
}

Retournez les champs de réponse risk_score, severity, sanctions_hit, et la source et la destination des fonds signalées.
Ne détenez pas de fonds, ne créez pas de dossier et n'informez personne.
Demandez une instruction de suivi explicite après avoir résumé le résultat du contrôle.

La forme de la réponse est un résultat de contrôle : risk_score, severity, sanctions_hit et des informations sur la source/destination des fonds. L'outil peut renvoyer une réponse 409 lorsque la configuration de contrôle de la surveillance des transactions n'est pas disponible.

Le contrôle de portefeuille, également appelé KYC des transactions (KYT) dans le catalogue de produits, coûte 0,15 $ par vérification. Le résultat ne déplace pas d'argent en soi. Une retenue, une libération, un cas, une escalade ou une notification relèvent de la politique propre à l'échange et nécessitent un système ou une action d'outil distinct. Par exemple, Claude ne peut appeler didit_case_create qu'après que l'opérateur ou une couche de politique autorisée ait explicitement choisi cette action.

Décision 4 : Soumettre une transaction avec le schéma réel

didit_transaction_create soumet une transaction pour surveillance et évaluation des règles. Ses champs de niveau supérieur requis sont :

• transaction_id : l'identifiant unique de la transaction de l'échange.
• transaction_category : l'une des valeurs de catégorie documentées, y compris finance, kyc, travel_rule et user_event.
• transaction_details : la charge utile de transaction spécifique à la catégorie.
• subject : la partie initiant la transaction.

Les objets de niveau supérieur facultatifs incluent counterparty, travel_rule_details, network_snapshot et custom_properties. L'outil ne définit pas le hachage de transaction, l'adresse source, l'adresse de destination, l'actif ou le montant comme champs de niveau supérieur universels. Si ces valeurs font partie des données d'une catégorie, elles appartiennent à l'objet spécifique à la catégorie pertinent.

Le contrat de niveau supérieur pour didit_transaction_create est :
{
  "transaction_id": "<id-transaction-unique-échange>",
  "transaction_category": "finance",
  "transaction_details": { "<champs-catégorie-finance>": "<valeurs>" },
  "subject": { "<champs-partie-initiante>": "<valeurs>" },
  "counterparty": { "<champs-autre-partie>": "<valeurs>" },
  "transaction_at": "<timestamp-ISO>"
}

Les espaces réservés sont délibérés. Le schéma MCP stipule que transaction_details et subject dépendent de transaction_category ; il ne publie pas une charge utile imbriquée universelle. Un opérateur doit utiliser les champs définis pour la catégorie configurée plutôt que de copier un schéma crypto inventé.

Pour travel_rule, le même contrat de niveau supérieur s'applique, avec des données de transfert spécifiques à la catégorie dans transaction_details, la partie initiatrice dans subject, l'autre partie dans counterparty, et les données de la règle de voyage dans travel_rule_details. Il n'y a pas de champ metadata sur cet outil. La sélection de travel_rule identifie la charge utile spécifique à la catégorie ; elle n'effectue pas automatiquement le contrôle du bénéficiaire ou ne débloque pas le transfert.

La transaction est évaluée lorsqu'elle est soumise. Il est inexact de décrire un seul enregistrement soumis comme étant continuellement réévalué indéfiniment. Claude peut récupérer la transaction surveillée et son résultat d'évaluation des règles avec didit_transaction_get.

Décision 5 : Conserver l'élaboration de la politique dans la console d'administration

Le générateur de règles de surveillance des transactions de la console d'administration est l'endroit où les équipes configurent les règles de surveillance et la logique de la politique. Ce n'est pas l'éditeur de flux de travail de vérification. L'interface MCP soumet les transactions, récupère les résultats, recherche les enregistrements et prend en charge les opérations de cas explicites ; elle ne remplace pas l'élaboration des règles.

Les actions de cas sont également limitées. didit_case_manage prend en charge assign, comment, escalate, reopen, resolve et update. Les flux de travail des rapports d'activités suspectes (SAR) restent des opérations de la console d'administration. Cette limite permet à un échange d'utiliser Claude pour la collecte de preuves et l'assistance de l'opérateur sans décrire l'agent comme une autorité de conformité autonome.

Connecter le copilote opérateur

Le point de terminaison MCP hébergé de Didit expose 115 outils via HTTP streamable et utilise OAuth 2.1 avec Proof Key for Code Exchange (PKCE). Le serveur MCP est gratuit ; les vérifications sous-jacentes suivent leurs prix publiés. Le niveau gratuit est de 500 vérifications gratuites par mois.

Connectez Claude hébergé avec le lien profond du connecteur Didit. Consultez la vue d'ensemble du MCP, le guide d'authentification et la référence de l'outil. L'implémentation est disponible dans le répertoire GitHub sous licence MIT, et la présentation du produit se trouve sur didit.me/developers/mcp.

Le modèle opérationnel durable est : preuves d'abord, politique ensuite, action en troisième. Claude rassemble la décision KYC, le résultat AML, le résultat du portefeuille et l'évaluation de la transaction. L'échange reste explicite quant à la réponse qui a provoqué quelle décision et quelle action distincte a suivi.