Automatización de Due Diligence del Cliente: Arquitectura para CDD Consciente de Jurisdicción

---

Un cliente de alto riesgo en Alemania requiere Enhanced Due Diligence bajo AMLD5 Art. 18. El mismo perfil de riesgo en España requiere verificaciones adicionales bajo Ley 10/2010 Art. 11. El mismo cliente expandiéndose a los Países Bajos necesita evaluación bajo Wwft Art. 3. Cada jurisdicción requiere verificaciones ligeramente diferentes, umbrales diferentes y profundidad de documentación diferente.

La mayoría de los sistemas manejan esto con sentencias if:

if jurisdiction == "DE" and risk_level == "high":
    run_enhanced_checks_germany()
elif jurisdiction == "ES" and risk_level == "high":
    run_enhanced_checks_spain()
elif jurisdiction == "NL" and risk_level == "high":
    run_enhanced_checks_netherlands()

Esto funciona para un mercado. Falla al expandirse. Cada nueva jurisdicción requiere un nuevo bloque de código, un nuevo ciclo de testing, un nuevo deployment. Los cambios regulatorios (una nueva directiva, un umbral revisado, un tipo de verificación adicional) requieren modificación de código. El equipo de compliance depende de ingeniería para cada ajuste de regla. El backlog de ingeniería se convierte en un cuello de botella regulatorio.

La alternativa es un modelo basado en políticas: las reglas CDD almacenadas como datos, no como código. Las decisiones de compliance se derivan de la combinación (Jurisdicción, Nivel de Riesgo, Tipo de Verificación, Profundidad). Añadir una nueva jurisdicción es un registro de configuración, no un cambio de código.

Reglas CDD como Datos

Una política CDD define: para esta combinación de jurisdicción, nivel de riesgo y tipo de verificación, ¿qué profundidad de verificación se requiere?

La tabla es la política. No hay sentencia if. El motor consulta: "Para jurisdicción=DE, risk_level=high, check_type=identity, ¿cuál es la profundidad requerida?" La respuesta es un valor de datos, no una rama de código.

Esto no elimina la complejidad. Los requisitos regulatorios SON complejos. Lo que elimina es la acoplación entre complejidad regulatoria y complejidad de código. El equipo de compliance puede definir y actualizar políticas. Ingeniería mantiene el motor que las ejecuta. Las dos preocupaciones evolucionan independientemente.

Ciclo de Vida de Políticas: Borrador → Activa → Archivada

Las políticas CDD no son estáticas. Los reguladores actualizan las directivas. Los umbrales de riesgo cambian. Nuevas jurisdicciones se añaden. Las políticas necesitan versionado.

Tres estados:

La activación reemplaza la política activa actual para la misma combinación (Jurisdicción, Nivel de Riesgo, Tipo de Verificación). La política previa se archiva automáticamente. Un auditor puede reconstruir qué política estaba activa en cualquier momento: consultar las políticas archivadas por rango de timestamp.

Esto satisface AMLD Art. 8 (medidas internas documentadas) y DORA Art. 11 (trazabilidad ICT). El historial de políticas no es un documento escrito en un wiki. Es un registro de datos con timestamps, versionado y transiciones de estado, consultable, auditable y a prueba de manipulación.

Abstracción de Proveedores

Las verificaciones CDD son ejecutadas por proveedores externos: Identomat para verificación de identidad, ComplyAdvantage para screening PEP/sanciones, un proveedor local para prueba de dirección en ciertas jurisdicciones. Cada proveedor tiene una API diferente, un formato de respuesta diferente y un modelo de precios diferente.

El motor CDD no llama a los proveedores directamente. Llama a una interfaz de proveedor:

interface CddCheckProvider {
  executeCheck(customer, checkType, depth) → CddCheckResult
  getStatus(sessionId) → CheckStatus
}

La política especifica qué verificación ejecutar. La configuración de proveedor especifica quién la ejecuta. Cambiar de Identomat a Onfido para verificación de identidad en Alemania es un cambio de configuración, no un cambio de código, no un cambio de política, no un ciclo de testing del pipeline CDD.

Esta separación importa cuando los proveedores fallan. Si Identomat tiene una caída, el sistema puede enrutar verificaciones de identidad a un proveedor de respaldo, sin cambiar la política CDD, sin cambiar el flujo de onboarding, sin un deployment de emergencia. El proveedor es una preocupación de infraestructura. La política es una preocupación de compliance. Los dos fallan independientemente y se recuperan independientemente.

Perfiles de Jurisdicción

Cada jurisdicción trae parámetros regulatorios más allá de las políticas CDD: calendarios de festivos (para cálculos de días hábiles), límites de transacciones (PSD2 Art. 87 requisitos de fecha valor varían por esquema), períodos de retención para documentos de compliance (GoBD: 10 años en Alemania, Ley 10/2010: 10 años en España).

Un perfil de jurisdicción consolida estos parámetros:

{
  "jurisdiction": "DE",
  "regulatoryFramework": ["AMLD5", "KWG", "GwG", "GoBD"],
  "holidays": "TARGET2 + DE national",
  "retentionPeriod": "10 years (GoBD §147)",
  "transactionLimits": {
    "sctInstant": { "max": 100000, "currency": "EUR" }
  },
  "cddRequirements": {
    "documentTypes": ["passport", "nationalId", "residencePermit"],
    "addressProof": "required for high-risk",
    "sourceOfFunds": "required for high-risk"
  }
}

Expandirse a una nueva jurisdicción significa: crear el perfil de jurisdicción, definir las políticas CDD, configurar las asignaciones de proveedores. Cero cambios de código. Cero deployments (a menos que el nuevo perfil requiera un nuevo tipo de verificación que no exista aún, ese es el caso donde se necesita un cambio de código).

El Impacto Operativo

Tres capacidades que las sentencias if codificadas no pueden proporcionar:

Expansión de mercado sin ingeniería. El equipo de compliance define las políticas CDD para Portugal. El equipo de operaciones configura la asignación de proveedores. El equipo de producto habilita la jurisdicción en la interfaz de onboarding. Ningún ingeniero escribió una sentencia if. Ningún deployment requirió cycle de testing del motor CDD. La plataforma soporta un nuevo mercado a través de configuración.

Cambios de reglas sin deployments. El regulador alemán actualiza los umbrales de EDD. El equipo de compliance crea una nueva versión de la política CDD (Borrador), la revisa, la activa. La versión previa se archiva automáticamente. El cambio es efectivo inmediatamente. El registro de auditoría muestra cuándo ocurrió el cambio y qué política se reemplazó.

Preparación para examen regulatorio. Un auditor pregunta: "Muéstreme sus procedimientos CDD para clientes de alto riesgo en España a fecha de junio 2025." El sistema consulta las políticas archivadas: Jurisdicción=ES, NivelDeRiesgo=alto, con validez a esa fecha. La respuesta es una consulta a la base de datos, no un ejercicio de búsqueda de documentos.

Cinco Preguntas para Evaluar Su CDD

1. ¿Puede su equipo de compliance cambiar umbrales CDD sin un ticket de ingeniería? Si no: las reglas CDD están codificadas. Cada cambio regulatorio requiere un ciclo de desarrollo.

2. ¿Puede expandirse a una nueva jurisdicción sin un release de código? Si no: los requisitos de jurisdicción están codificados. La expansión está limitada por la capacidad de ingeniería.

3. ¿Puede reconstruir qué política CDD estaba activa en una fecha específica? Si no: las políticas no están versionadas. Los auditores no pueden verificar el cumplimiento histórico.

4. ¿Puede cambiar de proveedor KYC sin modificar su flujo de onboarding? Si no: proveedor y flujo están acoplados. Los fallos de proveedor son fallos de plataforma.

5. ¿Son sus registros de decisiones CDD consultables por jurisdicción, nivel de riesgo y período de tiempo? Si no: la preparación para auditoría depende de la agregación manual de datos.

---

Leer más: Compliance, Infraestructura de Compliance | Seguridad y Compliance

---

Fuentes:

• AMLD5, Directiva (UE) 2018/843, Art. 8 (medidas internas), Art. 13 (CDD estándar), Art. 18 (EDD)
• DORA, Reglamento (UE) 2022/2554, Art. 11 (trazabilidad ICT)
• GwG (Alemania), Geldwäschegesetz, §10-15 (obligaciones CDD)
• Ley 10/2010 (España), Prevención del blanqueo de capitales, Art. 3-11 (obligaciones de due diligence)
• Wwft (Países Bajos), Wet ter voorkoming van witwassen, Art. 3 (obligaciones CDD)