Arquitectura de informes regulatorios AML a escala
La metodología de arquitectura que SEYSO ha aplicado en programas plurianuales de informes regulatorios para bancos de primer nivel de Canadá y Estados Unidos, que abarcan las obligaciones FINTRAC EFTR, STR, CTR, KYC y CFT en plataformas nativas de la nube y basadas en eventos.
30+
Casos de uso de informes
M+
Transacciones diarias
200+
Sistemas de origen
24/7
Pipeline de procesamiento en streaming
Por qué los informes AML son el problema de datos más difícil de un banco
A primera vista, los informes regulatorios AML parecen un problema de datos. Un regulador —FINTRAC en Canadá, FinCEN en Estados Unidos— exige informar sobre ciertos patrones de transacciones: transferencias electrónicas de fondos que superan un umbral (EFTR), transacciones en efectivo que superan un umbral (CTR), comportamientos sospechosos (STR) y transacciones inusuales (UTR). Tomar los datos, darles formato y enviarlos.
En la práctica, la dificultad es que el regulador quiere la historia interconectada : quién originó los fondos, quién los recibió, quién controla la cuenta, qué nivel KYC tienen las partes, qué tramo de divisas pasó por qué intermediario y qué señales de ciberseguridad se activaron durante la sesión. Ese contexto está disperso entre cientos de sistemas de origen —sistemas bancarios centrales minoristas, mercados de capitales, préstamos comerciales, transferencias, divisas, tesorería, centros de datos de clientes y sistemas de identidad—, cada uno con su propio esquema, frecuencia de actualización y responsables.
El segundo paquete regulatorio de FINTRAC lo dejó claro: aproximadamente 30 casos de uso distintos, cada uno vinculando la transacción financiera con datos de divisas, clientes/cuentas y ciberseguridad, en las áreas de banca privada, minorista, mercados de capitales y banca comercial. Desde el punto de vista arquitectónico, no es un proyecto de informes. Es una plataforma de integración empresarial.
La arquitectura de referencia, de principio a fin
Las plataformas que hemos diseñado para bancos de primer nivel comparten una estructura común: cinco capas lógicas, cada una escalable y auditable de forma independiente:
- Ingesta desde los sistemas de origen. Captura de cambios en los datos de los sistemas bancarios centrales, Workday HR, centros de datos de clientes, motores de divisas y señales de ciberseguridad. Algunos sistemas publican eventos; los sistemas heredados ofrecen extracciones por lotes que encapsulamos en un cargador con validación de esquemas.
- Eje de transmisión de eventos. Flujos de eventos al estilo de Kafka que transportan transacciones financieras, actualizaciones KYC, coincidencias en listas de sanciones y eventos del ciclo de vida de las cuentas. Los temas se particionan por cliente o cuenta para preservar el orden por entidad.
- Vinculación y enriquecimiento. Los procesos de tratamiento de flujos vinculan el evento de transacción con datos maestros de clientes, jerarquías de cuentas, tramos de divisas, perfiles KYC y comportamiento histórico. El resultado es un registro reportable totalmente vinculado y estructurado según los requisitos del regulador.
- Detección y reglas. Actimize aloja los escenarios de detección AML para STR/UTR; las reglas deterministas de umbrales y los datos de referencia rigen EFTR/CTR. El resultado es un flujo de posibles envíos junto con sus evidencias.
- Envío y trazabilidad. Un servicio de envío da formato a las cargas EFTR/STR/CTR/UTR según los esquemas de FINTRAC, las firma y las transmite por el canal seguro. Cada registro lleva un identificador de trazabilidad que permite remontarse a sus eventos de origen.
La plataforma se ejecuta en Azure —AKS para servicios en contenedores, PostgreSQL para almacenar los envíos regulatorios, Azure Storage para los eventos sin procesar y Azure Monitor / Sentinel para seguridad y observabilidad. En implementaciones en los cinco grandes bancos de Canadá hemos ampliado Actimize en AKS con PostgreSQL específicamente para ofrecer capacidades CTR a escala.
Por qué usar transmisión de eventos en lugar de lotes nocturnos
Históricamente, los informes AML eran un proceso nocturno por lotes. Eso funcionaba cuando los plazos de las obligaciones de reporte se medían en días. Hoy, la expectativa de FINTRAC —y, francamente, la propia tolerancia al riesgo del banco— se acerca mucho más a trabajar casi en tiempo real. Los EFTR deben activarse de forma fiable independientemente de cuándo se liquide la transferencia subyacente. Los STR se benefician de vincular señales de comportamiento en vivo con la transacción.
La transmisión de eventos nos ofrece tres cosas que los lotes no pueden ofrecer. Primero, ingesta que tiene en cuenta la contrapresión: la lentitud de un sistema de origen no interrumpe el flujo regulatorio. Segundo, reprocesamiento: cuando cambia una regla, podemos volver a procesar el intervalo afectado sin tocar los sistemas de origen. Tercero, orden por entidad: al particionar por cliente o cuenta, garantizamos que una modificación de una transacción se procese después de la original, incluso cuando circulan diez mil eventos por segundo.
En cuanto a costos, AKS nos ofrece capacidad de cómputo elástica que escala con el volumen: los picos de cierre de mes, cierre de año y volatilidad cambiaria no requieren capacidad aprovisionada permanentemente.
El modelado de amenazas como elemento fundamental de la arquitectura
Los informes AML operan en un entorno hostil. Los actores maliciosos intentan activamente mantenerse por debajo de los umbrales, fraccionar transacciones o contaminar los datos KYC. Una buena plataforma AML no solo cumple la normativa: también tiene en cuenta a sus adversarios.
Cada arquitectura que entregamos en este ámbito incluye un modelo explícito de amenazas: STRIDE en cada límite entre componentes, clasificación de datos en cada almacén e identidades con privilegios mínimos para las llamadas entre servicios. Los secretos residen en Azure Key Vault; las identidades de servicio utilizan identidades administradas, no credenciales estáticas. Las cargas sensibles —documentos KYC e información personal identificable de los clientes— se cifran mediante claves de cifrado de sobre vinculadas al área de negocio.
En los envíos regulatorios, cada carga está firmada y la clave de firma está respaldada por hardware. Esto permite detectar un envío manipulado o reproducido tanto en FINTRAC como en nuestro propio flujo de auditoría.
KYC e incorporación de empresas de servicios monetarios
Los informes AML dependen de KYC. Si KYC es incorrecto, los informes también lo serán. Uno de los componentes tácticos más interesantes en los que hemos trabajado es el proceso de incorporación de empresas de servicios monetarios (MSB), una categoría de clientes que presenta un riesgo alto justificado y cuyos requisitos de debida diligencia KYC son considerables.
El patrón arquitectónico: un flujo de evaluación que incorpora registros de MSB, listas de sanciones y datos de beneficiarios finales a un grafo de enriquecimiento de clientes; una interfaz táctica de gestión de casos para el equipo de investigaciones AML; y un registro de auditoría que vincula cada decisión de incorporación con la evidencia que la sustentó. La solución táctica permite ganar tiempo mientras el centro estratégico de datos de clientes se pone al día, pero sus resultados tienen la misma estructura, de modo que la plataforma estratégica hereda los datos sin rehacer el trabajo.
Lecciones de la implementación en dos bancos de primer nivel
- Trata el esquema del regulador como un contrato. Desarrolla conforme a él desde el primer día. No permitas que las estructuras internas de datos se filtren a la capa de envío.
- La vinculación es el verdadero trabajo. Las reglas EFTR/STR son la parte fácil. Vincular correctamente 30 casos de uso de datos de clientes, cuentas, divisas y ciberseguridad consume el 80% del trabajo de ingeniería.
- La trazabilidad no es opcional. Cuando un regulador cuestiona un envío, debes poder mostrar cada evento que contribuyó a él en minutos, no en días.
- La aprobación del comité de revisión de arquitectura no es un mero trámite. Úsala para impulsar el rigor. Las revisiones por las que hemos pasado han detectado problemas de residencia de datos y gestión de claves que habrían sido muy costosos de resolver después.
- Nativo de la nube ≠ exclusivo de la nube. Algunos sistemas de origen seguirán en instalaciones locales durante años. La arquitectura debe reflejar con realismo la integración híbrida.
¿Tu banco o fintech necesita esto?
SEYSO ha diseñado plataformas AML y de informes regulatorios para varios bancos de primer nivel de Canadá y Estados Unidos, que abarcan las obligaciones LCTR, EFTR, STR, UTR, CTR, KYC y CFT. Si estás modernizando la tecnología contra los delitos financieros, migrando Actimize a otra plataforma o definiendo un nuevo programa regulatorio, nos encantará conversar. Trae las obligaciones regulatorias y la complejidad de los sistemas de origen; nosotros aportaremos la arquitectura.
¿Estás diseñando tu próximo programa regulatorio?
Habla con los arquitectos que han creado plataformas de informes FINTRAC en bancos de primer nivel.