Verificación KYC con Claude: Ejecutando revisiones en el chat
Analistas de cumplimiento utilizan el servidor MCP de Didit en Claude para revisar sesiones KYC, corregir datos, aprobar o rechazar verificaciones y gestionar la cola de revisión, todo desde el chat.
Conclusiones clave
- Conecte Claude al servidor del Protocolo de Contexto del Modelo (MCP) de Didit a través de OAuth (Autorización Abierta) 2.1 con PKCE (Proof Key for Code Exchange) — no se necesita clave de interfaz de programación de aplicaciones (API), y su rol y permisos existentes de Didit se mantienen exactamente.
- 115 herramientas en 11 categorías le permiten buscar, inspeccionar, corregir, revisar, aprobar y rechazar sesiones de Conozca a su Cliente (KYC) completamente desde la ventana de chat de Claude.
- Un analista de cumplimiento puede trabajar toda la cola "En Revisión": inspeccionar decisiones, anular campos mal leídos, dejar notas de auditoría, aprobar o rechazar, y solicitar una reenvío parcial — todo sin abrir la Consola de Negocios.
- El MCP actúa como el usuario de Didit que ha iniciado sesión con el rol exacto de la organización de ese usuario — un analista no puede hacer nada en Claude que no pueda hacer en la consola. Esto responde directamente a la pregunta del oficial de cumplimiento: los permisos no se eluden.
- Didit atiende a más de 2,000 empresas en producción; la inferencia del modelo se ejecuta a menos de 2s p99. El paquete completo de KYC cuesta $0.33, y cada característica incluye 500 verificaciones gratuitas por mes.
La verificación KYC es un flujo de trabajo diario para los equipos de cumplimiento. Las sesiones llegan marcadas para revisión manual. Los documentos se escanean, los datos se extraen, y un porcentaje siempre recae en un revisor humano para solucionar. Ese revisor normalmente pasa su día alternando entre una Consola de Negocios y una herramienta de gestión de colas, haciendo clic sesión tras sesión.
Hay una forma más rápida. Con el servidor del Protocolo de Contexto del Modelo (MCP) de Didit conectado a Claude, un analista de cumplimiento puede trabajar toda la cola de revisión desde una única ventana de chat. Buscar sesiones en revisión, leer por qué cada una fue marcada, inspeccionar el objeto de decisión completo, corregir un apellido o fecha de nacimiento mal leídos, dejar una nota del revisor, aprobar o rechazar con un registro de auditoría completo, y solicitar la reenvío de solo los pasos fallidos — todo sin salir de la conversación.
Cómo funciona
La configuración del conector y el flujo de OAuth se cubren en la guía de instalación de Claude. Para la revisión diaria, el límite importante es simple: cada llamada a una herramienta se ejecuta con el rol de organización existente del usuario de Didit que ha iniciado sesión, por lo que Claude no puede aprobar o editar una sesión si ese usuario carece del permiso correspondiente.
Agregue el conector Didit a Claude. La implementación y el código de autoalojamiento están disponibles en el repositorio público de GitHub bajo la licencia MIT.
La cola de revisión KYC diaria en Claude
El servidor MCP expone 115 herramientas en 11 categorías. Para un analista de cumplimiento que revisa sesiones KYC, el flujo de trabajo relevante se ve así:
1. Descubra su espacio de trabajo
Comience con didit_context_get. Esta única llamada devuelve cada organización y aplicación a las que puede acceder, incluyendo cuál organización y aplicación son las predeterminadas. Reemplaza el patrón de descubrimiento de varios pasos más antiguo y le permite comenzar a trabajar de inmediato.
Llame a didit_context_get. Indique la organización y aplicación seleccionadas, y no lea ni cambie ninguna sesión todavía.
2. Encuentre sesiones que necesiten revisión
Ejecute didit_session_search con status: "In Review". Esto busca en todas sus aplicaciones y organizaciones en una sola llamada y devuelve sesiones etiquetadas con su organización y aplicación, las más nuevas primero. Puede filtrar por rango de fechas usando last_n_days o profundizar en un flujo de trabajo específico con workflow_id.
Encuentre sesiones con estado “In Review” usando last_n_days: 1. Indique los límites de date_from y date_to, luego devuelva session_id, workflow, created time y cualquier motivo de revisión observado. No llame a herramientas de escritura.
last_n_days es un atajo de fecha calendario: establece date_from y date_to. No es un filtro rodante de 24 horas. Pase fechas explícitas YYYY-MM-DD cuando su política de revisión requiera un límite diferente.
3. Inspeccione la decisión completa
Para cualquier sesión marcada, llame a didit_session_get_decision con su identificador de sesión. Esto devuelve la decisión completa y los datos extraídos producidos por el flujo de trabajo configurado de esa sesión. Dependiendo de los módulos en ese flujo de trabajo, la respuesta puede incluir campos de documentos de identidad, resultados de vivacidad y coincidencia facial, salida de detección de lavado de dinero (AML), señales de fraude y evidencia de revisión. No espere módulos que el flujo de trabajo no ejecutó.
Recupere la decisión completa para la sesión SESSION_UUID. Separe los campos observados, las comprobaciones fallidas, las pruebas contradictorias y los datos faltantes. No recomiende un estado todavía.
4. Corrija datos mal leídos
El OCR (Reconocimiento Óptico de Caracteres) puede leer mal un carácter — un "0" que debería ser una "O", una letra acentuada que el OCR aplana, una falta de coincidencia en el formato de fecha. Use didit_session_update_data para anular cualquier campo extraído: nombre, apellido, fecha de nacimiento, número de documento, estado emisor, dirección, género, nacionalidad, estado civil y campos adicionales específicos del documento. Envíe solo los campos que necesitan corrección; todo lo demás permanece como se extrajo.
Para la sesión SESSION_UUID, cambie solo last_name a “Muñoz”. Muestre la actualización de campo propuesta y espere mi aprobación antes de llamar a didit_session_update_data.
5. Deje una nota de auditoría
Use didit_session_add_review para adjuntar un comentario del revisor al registro de auditoría de la sesión. Opcionalmente, puede cambiar el estado de la sesión como parte de la misma llamada — por ejemplo, moverla a "En Revisión" si la está trabajando activamente, o a "Aprobada" si su inspección está completa. Cada nota y transición de estado se registra y se marca con la hora.
Agregue este comentario de revisión a la sesión SESSION_UUID sin cambiar su estado: “Apellido corregido después de la comparación con la zona visual del documento.”
6. Aprobar, rechazar o solicitar reenvío
Cuando la revisión sea concluyente, use didit_session_update_status para establecer el estado final en Approved o Declined, con un comentario opcional y notificación por correo electrónico. Use un mensaje que haga explícita la decisión autorizada:
Actualice la sesión SESSION_UUID a Approved con el comentario “Revisión manual completada bajo la política v4.2.” No cambie los datos de identidad extraídos.
El reenvío parcial es más estricto que una etiqueta conversacional. nodes_to_resubmit debe contener los identificadores de nodo fallidos exactos devueltos para esa sesión. Valores como liveness o blurred document page son descripciones, no identificadores de nodo ejecutables. Primero pregunte:
De la decisión para la sesión SESSION_UUID, enumere los identificadores de nodo fallidos exactos que son elegibles para reenvío. No cambie la sesión.
Después de revisar esos identificadores, úselos textualmente:
Establezca la sesión SESSION_UUID en Resubmitted y pase estos valores exactos de nodes_to_resubmit: ["EXACT_NODE_ID_1", "EXACT_NODE_ID_2"]. Agregue el comentario “Reintentar solo los pasos configurados fallidos.”
Todo el flujo de trabajo — buscar, inspeccionar, corregir, anotar, decidir — ocurre dentro de Claude. Las búsquedas y lecturas no crean entradas de auditoría del revisor. Las herramientas de escritura tienen efectos distintos: didit_session_update_data aplica una corrección, didit_session_add_review crea una nota del revisor y didit_session_update_status registra un cambio de estado con un comentario opcional en el registro de auditoría.
Los 10 estados de sesión y su significado
Al buscar o revisar sesiones, se filtra por estado. Didit rastrea 10 estados a lo largo del ciclo de vida de la sesión:
- Not Started (No iniciada) — La sesión fue creada y el enlace de verificación fue generado, pero el usuario aún no lo ha abierto.
- In Progress (En progreso) — El usuario abrió el flujo de verificación y está completando activamente los pasos.
- In Review (En revisión) — La sesión está actualmente en cola para revisión humana. Pudo haber llegado allí a través de la lógica de flujo de trabajo configurada o un cambio de estado manual de un revisor autorizado.
- Approved (Aprobada) — El estado de decisión actual de la sesión es aprobado. Ese estado puede provenir del flujo de trabajo configurado o de una anulación de estado manual de un revisor autorizado; no prueba que todas las comprobaciones posibles se ejecutaron o pasaron.
- Declined (Rechazada) — El estado de decisión actual de la sesión es rechazado. Puede reflejar la lógica de flujo de trabajo configurada o una anulación de estado manual de un revisor autorizado, así que lea la evidencia devuelta en lugar de tratar la etiqueta como una lista de comprobaciones fallidas.
- Expired (Expirada) — El tiempo límite de la sesión transcurrió antes de que el usuario completara la verificación.
- Abandoned (Abandonada) — El usuario inició pero no terminó el flujo.
- Kyc Expired (KYC Expirado) — Los datos KYC en sí caducaron (por ejemplo, se detectó un documento de identidad caducado después de la verificación).
- Resubmitted (Reenviada) — El analista solicitó un reenvío parcial, y se le pidió al usuario que repitiera solo los pasos fallidos.
- Awaiting User (Esperando usuario) — Una sesión principal de Know Your Business (KYB) está esperando mientras las partes KYC secundarias requeridas completan su verificación.
Permisos y seguridad
La objeción del oficial de cumplimiento a cualquier herramienta conectada a la inteligencia artificial (IA) es sencilla: ¿puede un agente hacer algo en el chat que a un revisor humano no se le permitiría hacer en la consola? Con el servidor MCP de Didit, la respuesta es no. El MCP se autentica como el usuario de Didit que ha iniciado sesión a través de OAuth 2.1 con PKCE — cada llamada a una herramienta hereda el rol de organización de ese usuario. La Consola de Negocios y el servidor MCP aplican las mismas comprobaciones de privilegios contra el mismo backend de permisos en service-didit-auth.
Un analista puede revisar sesiones, corregir datos y aprobar o rechazar solo dentro del alcance que su rol ya le otorga. Un desarrollador que conecta el MCP puede crear flujos de trabajo y gestionar webhooks si su rol lo permite. El propio MCP no introduce nuevos permisos. Es una interfaz diferente al mismo modelo de autorización.
Para quién es esto
Este flujo de trabajo está diseñado para analistas de cumplimiento que ya saben cómo revisar una sesión KYC. El MCP no automatiza el juicio del revisor, sino que elimina el cambio de contexto. En lugar de abrir un navegador, iniciar sesión en la consola, encontrar la página de sesión correcta, hacer clic en pestañas y escribir en formularios, el analista describe lo que quiere en lenguaje natural y Claude ejecuta la secuencia de herramientas.
También es útil para los líderes de cumplimiento que desean verificar rápidamente la cola de revisión desde su teléfono, y para la incorporación de nuevos analistas que pueden aprender el proceso de revisión observando a Claude recorrer los datos de decisión de una sesión e identificar patrones.
Cuándo usar la consola en su lugar
Algunas acciones permanecen en la Consola de Negocios. El servidor MCP en Claude maneja las acciones de revisión y gestión por sesión. Para operaciones masivas como instalar paquetes de reglas, probar cambios de reglas o presentar un Informe de Actividad Sospechosa (SAR), esas características se encuentran en las interfaces de Monitoreo de Transacciones y Gestión de Casos de la consola. Las herramientas de gestión de casos del MCP manejan el triaje — didit_case_manage admite asignar, comentar, escalar, reabrir, resolver y actualizar — pero la presentación de SAR y la configuración del motor de reglas son flujos de trabajo solo de consola.
Para empezar
Conecte Claude al servidor MCP de Didit desde la configuración del conector de Claude. El servidor es gratuito, el endpoint alojado no requiere instalación y la referencia completa de la herramienta está en docs.didit.me.
Si es nuevo en la configuración del MCP, comience con la guía de instalación o la página de desarrolladores de Didit MCP. Para una descripción general del ciclo de vida de la sesión y lo que sucede cuando se ejecuta una verificación, lea KYC con el servidor MCP de Didit. Para el catálogo de herramientas, consulte la referencia de herramientas MCP.
Didit es infraestructura para identidad y fraude. 115 herramientas MCP. $0.33 por un paquete KYC completo. 500 verificaciones gratuitas por mes para cada característica. Más de 2,000 empresas en producción. Conecte Claude, inicie sesión y comience a revisar.
Artículos relacionados
- La norma europea de deepfakes entra en vigor, impactando la herramienta, no el fraude
- La IA en el juego: un desafío en dos frentes para la verificación de identidad
- La regla de identidad de las stablecoins cubre emisión y canje, no lo que sigue
- Egipto asume el costo de una actualización KYC en lugar de pasárselo al cliente
- Unico y Didit se Asocian para Ampliar el Acceso a la Verificación de Identidad de Vanguardia para Pymes en Brasil
- Didit vs. Onfido: Cobertura, Precios, Automatización y Migración