La arquitectura tecnológica de cumplimiento

Ninguna empresa de criptoactivos puede ejecutar su programa de forma manual: las transferencias se liquidan en minutos, los clientes se incorporan a distancia y la evidencia se encuentra en registros públicos y en los sistemas de los socios. Por tanto, la arquitectura tecnológica es el marco de control llevado a la práctica, y sus debilidades se convierten en fallos de cumplimiento. Esta lección explica sus componentes, cómo elegirlos e integrarlos sin favorecer a ningún proveedor y cómo mantener bajo control sus datos y modelos.

Los componentes básicos

Una arquitectura típica tiene seis componentes. Algunas empresas compran cada uno de ellos; otras combinan herramientas adquiridas con desarrollos internos.

Las reglas de monitoreo de transacciones suelen ejecutarse en la plataforma de datos o dentro de la herramienta de análisis o de gestión de casos; dondequiera que se ejecuten, dependen de los mismos datos. El informe del FATF Oportunidades y desafíos de las nuevas tecnologías para la prevención del lavado de activos y el financiamiento del terrorismo (julio de 2021) y su Guía sobre identidad digital (marzo de 2020) describen los beneficios y las condiciones: gobernanza, explicabilidad y supervisión humana.

Desarrollar, comprar o combinar

Pocas empresas lo desarrollan todo o lo compran todo. La elección depende de algunas preguntas:

Un patrón habitual consiste en comprar la verificación de identidad, los datos de listas, la atribución del análisis y la conectividad de Travel Rule, y desarrollar la plataforma de datos, los escenarios de monitoreo que dependen de los datos propios de la empresa y la lógica de decisión que combina todas las señales. Todo lo que se desarrolle internamente necesita la misma documentación, pruebas y control de cambios que una herramienta de un proveedor.

Selección de herramientas

La selección debe partir de la evaluación de riesgos y del marco de control, no de una demostración. Documente qué controles debe ejecutar la herramienta y, después, puntúe las candidatas según criterios como:

• cobertura: cadenas, tokens y puentes que admite o prevé admitir; fuentes de listas; países y tipos de documentos;
• precisión: tasas de falsos positivos y falsos negativos medidas con sus propios datos;
• explicabilidad: si cada puntuación o coincidencia incluye el motivo y la fuente que la sustentan;
• latencia y disponibilidad: tiempos de respuesta compatibles con las comprobaciones previas a la transacción y niveles de servicio;
• capacidad de configuración: umbrales, reglas y flujos de trabajo que puede modificar bajo su propio control de cambios;
• pista de auditoría: historial completo de entradas, versiones, decisiones y acciones de los usuarios;
• seguridad y protección de datos: informes de aseguramiento independiente, certificaciones como ISO/IEC 27001, ubicación de los datos, cifrado;
• salida: exportación de todos los datos y del historial en un formato utilizable si deja de utilizar el servicio.

Una prueba de concepto con sus propios datos es la evidencia más sólida. Proporcione a una herramienta de cotejo entradas conocidas de listas con variantes ortográficas y compruebe qué encuentra. Proporcione a dos fuentes de análisis las mismas 500 direcciones, incluidos sus propios depósitos de prueba, y mida en qué discrepan; las discrepancias son habituales e indican dónde se necesita una segunda fuente o una revisión manual (sobre por qué varía la atribución, consulte la lección de IDFE-CF Evaluación de la calidad de los clústeres).

Debida diligencia de proveedores y contratos

Una herramienta que ejecuta un control en su nombre constituye un acuerdo con un tercero, y se aplican las reglas de la lección Creación de la función de cumplimiento: la empresa conserva la responsabilidad. La debida diligencia abarca la estructura de propiedad y la solidez financiera del proveedor, su seguridad y resiliencia, su propio cumplimiento de las normas sobre sanciones y protección de datos, sus subcontratistas y la procedencia de sus datos. En cuanto a los datos de análisis y cotejo, pregunte cómo se obtienen las etiquetas y las entradas de listas, con qué frecuencia se actualizan y cómo se corrigen los errores.

El contrato debe otorgar derechos de auditoría e información, establecer niveles de servicio con medidas de subsanación, exigir avisos de cambios sustanciales en modelos o fuentes de datos y notificaciones de incidentes de seguridad, definir la titularidad y devolución de los datos e incluir un plan de salida probado. La concentración también importa: si una sola interrupción detiene a la vez la incorporación de clientes, el cotejo y el monitoreo, planifique una alternativa.

Integración y ruta de decisión

El punto del proceso en el que se sitúa un control determina si previene o simplemente detecta. El cotejo de billeteras y las comprobaciones de Travel Rule previos a la transacción deben ejecutarse antes de que se firme y difunda un retiro; una vez que una transferencia está en la cadena, no puede recuperarse. Cada control preventivo necesita un modo de fallo definido: bloqueo ante fallos (retener la transacción cuando la herramienta no está disponible) para las comprobaciones de alto riesgo, o apertura ante fallos con revisión posterior solo cuando la evaluación de riesgos lo acepte. Otras reglas de integración son: un único identificador de cliente compartido por todos los sistemas, relojes sincronizados en UTC y reintentos que nunca generen alertas o mensajes duplicados. Los cambios en la arquitectura, desde una nueva cadena hasta una actualización del modelo de un proveedor, pasan por pruebas en un entorno no productivo y por la aprobación del área de cumplimiento antes de su puesta en producción, porque una integración defectuosa puede desactivar un control sin que nadie lo advierta.

Toda decisión automatizada debe dejar un registro que se explique por sí mismo:

{
  "event": "withdrawal_decision",
  "withdrawal_id": "WD-2026-0918-00417",
  "customer_id": "C-88213",
  "asset": "USDC", "amount": "12500.00", "destination": "0xA1b2…9F",
  "screening": { "list_match": false, "list_version": "2026-09-18T06:00Z" },
  "analytics": { "entity_type": "VASP", "risk_score": 22,
                 "source": "provider-1", "label_date": "2026-09-02" },
  "travel_rule": { "required": true, "protocol": "TRP",
                   "status": "ACCEPTED", "payload_hash": "e91c…40ab" },
  "decision": "RELEASE", "rule_set": "WD-POLICY v4.2",
  "decided_at": "2026-09-18T10:42:07Z"
}

El registro almacena las entradas y sus versiones, no solo el resultado: qué versión de la lista se utilizó para el cotejo, qué fuente de análisis etiquetó el destino y cuándo, si se aceptó el mensaje de Travel Rule y qué conjunto de reglas tomó la decisión. Con él, un investigador o examinador puede reconstruir meses después por qué se autorizó la transferencia, incluso después de que hayan cambiado las listas, las etiquetas y las reglas. El hash demuestra qué mensaje se envió sin copiar datos personales en cada registro.

Plataforma de datos y linaje

El monitoreo, la información para la dirección y los informes a las autoridades solo son tan fiables como los datos en los que se basan. El linaje de datos documenta de dónde procede cada cifra y cada transformación a lo largo del recorrido. Los Principios para una eficaz agregación de datos sobre riesgos y presentación de informes de riesgos del Comité de Basilea (BCBS 239, enero de 2013), redactados para grandes bancos, establecen expectativas adecuadas para cualquier plataforma de datos de cumplimiento: precisión, integridad, puntualidad y adaptabilidad, bajo una gobernanza clara.

Los controles prácticos incluyen:

• conciliaciones de integridad, por ejemplo, comparar el número de retiros en el registro contable con el número de retiros cotejados y monitoreados cada día;
• monitoreo de los flujos de datos, con alertas cuando una fuente se detiene o su volumen cae bruscamente;
• un diccionario de datos y responsables para cada campo crítico;
• acceso basado en roles, registro de quién consultó o modificó los registros y conservación durante al menos cinco años;
• almacenamiento que permita detectar alteraciones en las decisiones y la evidencia.

Un escenario de monitoreo que omitió silenciosamente una nueva cadena durante tres meses es un hallazgo típico; la conciliación es el control que lo habría detectado.

Riesgo de modelo

Muchos componentes de la arquitectura son modelos: algoritmos de coincidencia aproximada, puntuaciones de riesgo de clientes, puntuaciones de riesgo del análisis y priorización de alertas mediante aprendizaje automático. Cada uno puede equivocarse, quedar desactualizado o utilizarse indebidamente. Mantenga un inventario de modelos con responsable, finalidad, entradas, versión y última validación; valídelos antes de usarlos y periódicamente; y controle cada cambio. Cuando un investigador discrepe de una etiqueta o puntuación de un proveedor, la anulación manual debe registrarse con su motivo y evidencia, comunicarse al proveedor y contabilizarse: un aumento de la tasa de anulaciones manuales es una señal temprana de que un modelo ya no se ajusta a su negocio. Los modelos de los proveedores siguen siendo modelos de su empresa: necesita documentación y resultados de pruebas suficientes para explicar sus resultados a un supervisor. Marcos como el Marco de Gestión de Riesgos de Inteligencia Artificial del NIST (AI RMF 1.0, enero de 2023) e ISO/IEC 42001:2023 sobre sistemas de gestión de IA ayudan a estructurar la gobernanza. Los métodos de ajuste y validación se tratan en la lección Ajuste, métricas y gobernanza de modelos.

Enfoque del examen: los seis componentes de la arquitectura y el fallo típico de cada uno; los criterios de selección (cobertura, precisión, explicabilidad, latencia, capacidad de configuración, pista de auditoría, seguridad, salida) y su evaluación mediante una prueba de concepto con datos propios; la debida diligencia de proveedores y las condiciones contractuales, con la responsabilidad en manos de la empresa; por qué los controles previos a la transacción deben ejecutarse antes de la difusión, y el bloqueo frente a la apertura ante fallos; qué contiene un registro de decisión que se explica por sí mismo; el linaje de datos, las conciliaciones de integridad y los principios de BCBS 239; el inventario y la validación de modelos, incluidos los modelos de proveedores.