Onboarding de Intercambio de Criptomonedas con Claude: Secuencia de Decisiones Operativas (ES)

Conclusiones clave

• Claude puede coordinar las decisiones de onboarding de un intercambio de criptomonedas, pero el cliente completa la captura de Conozca a su Cliente (KYC) en la interfaz de verificación alojada de Didit, no dentro del chat.
• didit_session_create requiere un workflow_id existente. Devuelve una URL que el intercambio proporciona al cliente.
• didit_transaction_screen_wallet solo devuelve los resultados del escaneo. No retiene fondos, crea un caso ni notifica a un equipo de cumplimiento.
• didit_transaction_create requiere transaction_id, transaction_category, transaction_details y subject en el nivel superior. Los campos de transacción varían según la categoría.
• El valor del operador es la secuencia de decisiones: recopilar la evidencia correcta, interpretarla bajo la política del intercambio, registrar cada decisión y activar explícitamente cualquier acción de seguimiento.

Un intercambio de criptomonedas no tiene una única decisión de onboarding. Tiene una cadena de decisiones: ¿puede esta persona iniciar la verificación de identidad, se completó la verificación alojada, un resultado de escaneo de nombres requiere revisión, qué significa un resultado de billetera bajo la política y debería aceptarse una transacción enviada para monitoreo?

El servidor del Protocolo de Contexto del Modelo (MCP) de Didit permite a Claude coordinar esos pasos a través de una superficie de herramienta autenticada. No reduce la experiencia del cliente a la conversación, y no convierte una respuesta de riesgo en un sistema automático de control de fondos. El patrón útil es un copiloto de operador con traspasos y acciones explícitas.

Este artículo se centra en esa secuencia operativa. La mecánica ya tiene guías dedicadas para KYC sobre MCP, escaneo de billeteras sobre MCP, y monitoreo de transacciones sobre MCP.

Decisión 0: establecer el alcance antes de contactar a un cliente

Un operador comienza con didit_context_get. La herramienta enumera las organizaciones y aplicaciones disponibles para el usuario autenticado, para que Claude pueda confirmar el contexto operativo previsto en lugar de mezclar clientes o entornos.

El intercambio también necesita un flujo de trabajo de verificación existente. El diseño del flujo de trabajo se realiza antes del traspaso al cliente y determina qué verificaciones se ejecutan. Para un flujo común de onboarding de criptomonedas, eso podría incluir Verificación de Identidad, Prueba de Vida Pasiva, Coincidencia Facial y Análisis de IP. El precio publicado del paquete completo de KYC para esas verificaciones es de $0.33.

La llamada de MCP no recibe una “configuración de flujo de trabajo”. didit_session_create recibe un workflow_id que ya existe. Esa distinción hace que la primera pregunta del operador sea concreta: ¿qué flujo de trabajo aprobado se aplica a este cliente y mercado?

Decisión 1: enviar al cliente al flujo KYC alojado

Claude crea la sesión con el flujo de trabajo seleccionado y una referencia de cliente estable. La respuesta contiene session_id, url y session_token.

Crear una sesión de verificación con didit_session_create:
{
  "workflow_id": "<uuid-de-flujo-de-trabajo-de-onboarding-cripto-existente>",
  "vendor_data": "cliente_18427",
  "callback": "https://exchange.example/onboarding/complete",
  "language": "es"
}

Devuelva la url al cliente y conserve el session_id para la búsqueda de decisiones.

El cliente abre esa URL y completa la captura requerida en la interfaz de usuario alojada de Didit. Las imágenes del documento de identidad y la selfie se envían allí. No permanecen dentro del chat de Claude.

Una vez que el cliente termina, Claude llama a didit_session_get_decision con session_id. La herramienta devuelve la decisión de verificación completa y los datos extraídos para el flujo de trabajo configurado. El operador puede entonces aplicar la política de revisión del intercambio a la respuesta real. Esto es un ciclo de traspaso y recuperación, no una afirmación de que “Aprobado” resuelve todas las preguntas de cumplimiento posteriores.

Decisión 2: separar la evidencia de identidad del riesgo de nombres

La verificación de identidad y el escaneo Antilavado de Dinero (AML) responden a preguntas diferentes. Después de leer los datos de identidad verificados, Claude puede llamar a didit_verify_aml con el nombre completo de la persona. Entradas opcionales como la fecha de nacimiento y la nacionalidad pueden mejorar la precisión de la coincidencia. El escaneo AML cuesta $0.20 por verificación en más de 1,300 listas.

La decisión del operador no es simplemente “coincidencia o no coincidencia”. Un resultado puede requerir comparación con los datos del cliente verificado, documentación del razonamiento o revisión manual bajo la política del intercambio. Si el operador decide que se necesita un caso, didit_case_create es una llamada explícita de herramienta separada. Nada sobre la sesión de KYC crea silenciosamente ese caso.

Esta separación mantiene el rastro de auditoría legible:

• Evidencia KYC: lo que devolvió el flujo de trabajo de verificación alojado.
• Evidencia AML: lo que devolvió la respuesta de escaneo de nombres.
• Decisión del operador: cómo la política del intercambio mapeó esas respuestas para aprobar, revisar o rechazar.

Decisión 3: escanear la billetera, luego decidir qué hacer

didit_transaction_screen_wallet acepta wallet_address, blockchain y una direction opcional. El enumerador blockchain es un identificador mixto de activo o cadena: incluye identificadores de cadena como BTC, ETH, SOL y TRX, e identificadores de activo como USDT y USDC. USDT y USDC son activos, no blockchains.

El siguiente es un prompt de Claude ejecutable con la forma exacta de carga útil de MCP. Reemplace la dirección de ejemplo con la billetera del cliente:

Llama a didit_transaction_screen_wallet con exactamente esta carga útil:
{
  "wallet_address": "0x0000000000000000000000000000000000000000",
  "blockchain": "ETH",
  "direction": "deposit"
}

Devuelve los campos de respuesta risk_score, severity, sanctions_hit, y la fuente y el destino de los fondos reportados.
No retengas fondos, crees un caso ni notifiques a nadie.
Pide una instrucción de seguimiento explícita después de resumir el resultado del escaneo.

La forma de la respuesta es un resultado de escaneo: risk_score, severity, sanctions_hit e información de origen/destino de fondos. La herramienta puede devolver una respuesta 409 cuando la configuración de escaneo del monitoreo de transacciones no está disponible.

El escaneo de billeteras, también llamado conozca su transacción (KYT) en el catálogo de productos, cuesta $0.15 por verificación. El resultado no mueve dinero por sí mismo. Una retención, liberación, caso, escalada o notificación pertenece a la política propia del intercambio y requiere un sistema o acción de herramienta separada. Por ejemplo, Claude puede llamar a didit_case_create solo después de que el operador o una capa de política autorizada elija explícitamente esa acción.

Decisión 4: enviar una transacción con el esquema real

didit_transaction_create envía una transacción para monitoreo y evaluación de reglas. Sus campos de nivel superior requeridos son:

• transaction_id: el identificador único de transacción del intercambio.
• transaction_category: uno de los valores de categoría documentados, incluyendo finance, kyc, travel_rule y user_event.
• transaction_details: la carga útil de la transacción específica de la categoría.
• subject: la parte que inicia la transacción.

Los objetos opcionales de nivel superior incluyen counterparty, travel_rule_details, network_snapshot y custom_properties. La herramienta no define el hash de la transacción, la dirección de origen, la dirección de destino, el activo o la cantidad como campos universales de nivel superior. Si esos valores forman parte de los datos de una categoría, pertenecen al objeto específico de la categoría relevante.

El contrato de nivel superior para didit_transaction_create es:
{
  "transaction_id": "<id-de-transacción-único-del-intercambio>",
  "transaction_category": "finance",
  "transaction_details": { "<campos-de-categoría-financiera>": "<valores>" },
  "subject": { "<campos-de-parte-iniciadora>": "<valores>" },
  "counterparty": { "<campos-de-otra-parte>": "<valores>" },
  "transaction_at": "<marca-de-tiempo-ISO>"
}

Los marcadores de posición son deliberados. El esquema de MCP establece que transaction_details y subject dependen de transaction_category; no publica una carga útil anidada universal. Un operador debe usar los campos definidos para la categoría configurada en lugar de copiar un esquema cripto inventado.

Para travel_rule, se aplica el mismo contrato de nivel superior, con datos de transferencia específicos de la categoría en transaction_details, la parte iniciadora en subject, la otra parte en counterparty y los datos de la Regla de Viaje en travel_rule_details. No hay un campo metadata en esta herramienta. Seleccionar travel_rule identifica la carga útil específica de la categoría; no realiza automáticamente la investigación del beneficiario ni autoriza la transferencia.

La transacción se evalúa cuando se envía. Es inexacto describir un único registro enviado como si se reevaluara continuamente para siempre. Claude puede recuperar la transacción monitoreada y su resultado de evaluación de reglas con didit_transaction_get.

Decisión 5: mantener la autoría de políticas en la Consola de Negocios

El constructor de reglas de Monitoreo de Transacciones de la Consola de Negocios es donde los equipos configuran las reglas de monitoreo y la lógica de las políticas. No es el editor de flujo de trabajo de verificación. La superficie de MCP envía transacciones, recupera resultados, busca registros y admite operaciones de casos explícitas; no reemplaza la autoría de reglas.

Las acciones de casos también están limitadas. didit_case_manage admite assign, comment, escalate, reopen, resolve y update. Los flujos de trabajo de Informes de Actividades Sospechosas (SAR) siguen siendo operaciones de la Consola de Negocios. Ese límite permite que un intercambio use Claude para la recopilación de evidencia y la asistencia al operador sin describir al agente como una autoridad de cumplimiento autónoma.

Conectar el copiloto del operador

El endpoint MCP alojado de Didit expone 115 herramientas a través de HTTP Streamable y utiliza OAuth 2.1 con Proof Key for Code Exchange (PKCE). El servidor MCP es gratuito; las verificaciones subyacentes siguen sus precios publicados. El nivel gratuito incluye 500 verificaciones gratuitas por mes.

Conecte Claude alojado con el enlace profundo del conector de Didit. Revise la descripción general de MCP, la guía de autenticación y la referencia de herramientas. La implementación está disponible en el repositorio de GitHub con licencia MIT, y la descripción general del producto se encuentra en didit.me/developers/mcp.

El patrón operativo duradero es primero la evidencia, segundo la política, tercero la acción. Claude recopila la decisión de KYC, el resultado de AML, el resultado de la billetera y la evaluación de la transacción. El intercambio sigue siendo explícito sobre qué respuesta causó qué decisión y qué acción separada siguió.