KYC/CDD document intelligence

KYC/CDD document intelligence procesa el flujo entrante de documentos de clientes y lo convierte en datos estructurados con un veredicto de revisión. El resultado son campos completados en el CRM, indicadores para el compliance officer y un registro de decisiones que se puede presentar al regulador. Esto cubre la parte más laboriosa del KYC/CDD: la lectura de escaneos, la copia de campos al sistema y el recorrido por el checklist.

El proceso típico es el siguiente:

1. El cliente o el Relationship Manager carga el paquete de documentos en el File storage: la carpeta del expediente del cliente o una carpeta de carga temporal.
2. La automatización recoge los archivos por evento y clasifica cada uno: pasaporte, proof of address, documentos constitutivos, extractos, declaración UBO, estructura corporativa, etc.
3. De cada tipo se extraen los campos relevantes: nombre completo, fecha de nacimiento, número de documento, dirección, fecha de emisión, vigencia, datos de registro de la empresa.
4. Los datos extraídos se contrastan con lo indicado por el cliente en el formulario o con lo existente en el CRM: las discrepancias (mismatches) se marcan indicando la fuente.
5. Los documentos pasan por QA según el rubric: legibilidad del escaneo, validez de fechas, vigencia, presencia de firma y sello, presencia de campos obligatorios, correspondencia con el tipo declarado.
6. El resultado es un registro estructurado del cliente en el CRM con todos los campos extraídos, enlaces a los archivos originales e indicadores del rubric, listo para revisión.
7. Los casos simples (todo coincide, rubric passed) avanzan automáticamente por el workflow; los complejos se enrutan al compliance officer con los puntos problemáticos resaltados y un veredicto propuesto.
8. Cada decisión —por qué el documento fue aceptado, rechazado o enviado a revisión— se registra en el audit trail con versionado del modelo y del rubric.

El resultado para el equipo: las horas de analista se redistribuyen de la verificación rutinaria a casos realmente complejos: jurisdicciones no estándar, paquetes de documentos incompletos, indicios de falsificación, estructuras corporativas complejas.

Lo que la automatización NO hace:

• No toma la decisión definitiva sobre el onboarding del cliente. El veredicto final corresponde al compliance officer, especialmente para los segmentos de high-risk y las estructuras corporativas complejas.
• No reemplaza el screening de listas de sanciones, adverse media y bases PEP: son fuentes de datos y verificaciones independientes que se integran de forma complementaria, pero no forman parte del document intelligence.
• No funciona «listo para usar» para jurisdicciones exóticas y tipos de documentos poco frecuentes sin reentrenamiento del pipeline con muestras locales ni adición de reglas manuales en el rubric.

Glosario: rubric — lista de verificación formal de criterios de aceptación/rechazo de documentos; CDD — customer due diligence, verificación ampliada del cliente; UBO — ultimate beneficial owner, beneficiario final; HITL — human-in-the-loop, revisión por persona dentro del proceso automatizado.

La arquitectura técnica de KYC/CDD document intelligence se compone de cuatro capas: ingestion (recepción de documentos), classification + extraction (comprensión del contenido), QA rubric (reglas de compliance), orchestration + human-in-the-loop (enrutamiento y revisión).

Flujo de datos:

1. Recepción de archivos desde File storage por evento (nuevo archivo en la carpeta) o por programación. Los formatos admitidos son PDF, JPEG, PNG, TIFF; los documentos de varias páginas se dividen página por página.
2. La capa OCR convierte la imagen en texto con coordenadas (bounding boxes). Para documentos impresos — motores estándar; para escritura manuscrita o escaneos de baja calidad — modelos especializados.
3. El clasificador determina el tipo de documento: un modelo ML sobre embeddings o un prompt a un LLM con descripción de tipos. El tipo de documento define la plantilla de extracción en el siguiente paso.
4. El Extractor extrae campos según la plantilla. Para documentos estructurados (pasaportes, tarjetas ID) — regex y reglas posicionales; para los no estructurados (extractos, documentos constitutivos) — LLM con esquema JSON de respuesta y validación.
5. El motor Rubric aplica un checklist: ¿el documento es legible? ¿las fechas son válidas? ¿la vigencia no ha expirado? ¿los campos coinciden con el CRM? ¿el formato cumple los requisitos de la jurisdicción?
6. El objeto final se escribe en el CRM (o en una tabla intermedia) junto con los enlaces a los archivos originales y la decisión del rubric por cada punto.
7. El orquestador enruta el caso: auto-approved → siguiente paso del workflow; se requiere revisión → cola del compliance officer; rechazado → devolución al Relationship Manager con el motivo.

Implementation steps para la implementación:

1. Recopilar 200-500 muestras de documentos de cada tipo del flujo de producción. Etiquetar: tipo, valores correctos de campos, veredicto final de compliance por cada punto del rubric.
2. Formalizar el rubric en forma de documento: qué campos son obligatorios para cada tipo, qué situaciones son hard fail y cuáles son soft warning con revisión humana.
3. Elegir una solución vertical SaaS para KYC/CDD o construir un pipeline personalizado. El vertical SaaS cubre ingestion, OCR, clasificación y los principales tipos de documentos de serie — esa es la razón para optar por una solución lista.
4. Configurar los conectores para File storage y CRM. Para el CRM — mapeo de campos (documento → ficha de cliente) y modelo de estados (qué estados del caso corresponden a qué resultados de la automatización).
5. Realizar una ejecución paralela: una o dos semanas en las que los documentos pasen tanto por personas como por la automatización. Comparar veredictos, medir precision/recall por cada punto del rubric.
6. Lanzamiento en un segmento piloto de clientes (una jurisdicción o un producto), con expansión gradual a segmentos adyacentes a medida que se estabilizan las métricas.
7. Integrar la interfaz HITL: una pantalla de revisión donde el officer ve el documento, los campos extraídos, los flags del rubric y toma la decisión final con un clic.

Componentes del sistema:

La calidad se mide en dos dimensiones: precision/recall de la extracción de campos (para que los datos en el CRM sean correctos) y precision/recall de las decisiones del rubric (para que los casos no estándar no pasen a auto-approve y los estándar no se bloqueen innecesariamente).

Una capa separada es la de seguridad y compliance. Los documentos contienen datos personales, por lo que el almacenamiento se cifra, el acceso se realiza a través de una cuenta de servicio con permisos limitados, y la política de retention coincide con la política del banco. El audit trail almacena todos los veredictos del modelo y del officer con marcas de tiempo y versiones del rubric — esto es necesario para las revisiones regulatorias y las auditorías internas.

Antes de lanzar KYC/CDD document intelligence se necesitarán tres cosas: datos para entrenamiento y validación, accesos a los sistemas y disposición del equipo.

Datos y documentos:

• 200-500 muestras etiquetadas de documentos de cada tipo que se procesarán (pasaporte, proof of address, extracto, documentos constitutivos, etc.).
• El rubric de compliance actual en formato formalizado: qué verifica el oficial actualmente, qué criterios son hard fail y cuáles soft warning.
• Historial de decisiones de los compliance officers durante los últimos 3-6 meses: se necesitará para la validación del modelo en edge cases reales.

Accesos e integraciones:

• File storage con estructura de carpetas para expedientes de clientes y permisos de lectura/escritura para la cuenta de servicio.
• CRM con API o webhooks para registrar datos estructurados del cliente y estados del expediente.
• Entornos dedicados (test → staging → prod) y sandbox de CRM para un piloto seguro.
• Cumplimiento de los requisitos de almacenamiento de datos personales de clientes: data residency, cifrado, política de retention, registro de accesos.

Equipo:

• Compliance officer o KYC analyst dispuesto a dedicar 4-8 horas por semana a la formalización del rubric y al etiquetado de muestras.
• Product owner o KYC lead para las decisiones de scope: qué tipos de documentos, qué jurisdicciones, por dónde empezar.
• Ingeniero o integrador del lado del banco para la configuración de conectores y accesos.

Timeline: 6-10 semanas desde el inicio hasta el lanzamiento piloto. Las primeras 2 semanas: etiquetado y formalización del rubric; las siguientes 3-4: configuración del pipeline y ejecución en paralelo; las restantes: piloto en un segmento limitado y expansión a productos adyacentes.