Sistema de monitoreo de transacciones AML

Un sistema fiable necesita todo lo siguiente:

• Datos limpios desde el inicio. La mayoría de los fallos de monitoreo empiezan aquí. Un escenario no puede detectar lo que nunca recibió, por lo que la integridad y el mapeo de los datos importan más que lo sofisticada que sea la detección.
• Una configuración que refleje su riesgo. Escenarios, umbrales y segmentos de clientes definidos según su propia evaluación de riesgo y no según valores predeterminados del proveedor, con control de cambios y aprobación independiente de cada modificación.
• Detección que vaya más allá de las transacciones individuales. Reglas para tipologías conocidas, analítica conductual para patrones que las reglas no pueden expresar y análisis de redes para descubrir vínculos entre cuentas. Las alertas también pueden provenir de fuera del sistema, por ejemplo, cuando un resultado de screening obliga a revisar la actividad pasada. Sea cual sea el método, debe poder explicar por qué se activó una alerta.
• Gestión de casos. Se genera una alerta y después se investiga. La sospecha es la conclusión de una investigación, no su detonante.
• Una ruta clara de escalación. El personal debe saber cómo elevar una preocupación, y su MLRO u oficial de cumplimiento debe ser quien decida si se informa a las autoridades.
• Reportes adaptados a sus mercados. Cada unidad de inteligencia financiera tiene su propio formato, portal y plazo. Algunos regímenes requieren autorización antes de continuar con una transacción que ya ha sido reportada. Y en todas partes está prohibido informar al cliente de que se presentó un reporte, al tiempo que usted queda protegido frente a responsabilidad cuando reporta de buena fe.
• Una pista de auditoría y medios para afinar. Qué escenario se activó, con qué datos, quién lo revisó, qué decidió y por qué, y quién aprobó cada cambio. Además de la capacidad de probar por encima y por debajo de sus umbrales para demostrar que su calibración funciona.

No existe un único mejor software. Las reglas están diseñadas con un enfoque basado en el riesgo, por lo que el sistema adecuado depende de lo que vende, a quién vende, dónde opera y qué volumen maneja. Lo que funciona para un emisor de dinero electrónico en un solo mercado no se adapta a un negocio de pagos multijurisdiccional, y lo que utiliza un banco global sepultaría a una plataforma de trading más pequeña.

Lo que tienen en común los buenos sistemas es lo siguiente:

• Detección alineada con sus tipologías, en lugar de una plantilla genérica
• Alertas explicables, para que su analista pueda decir por qué se activó una y su investigador pueda redactar algo que resista una revisión
• Ajustes demostrables, incluidos datos de precisión de alertas y un método documentado para cambiar umbrales
• Una pista de auditoría que pueda reproducir meses después: la regla, los datos, el revisor, la justificación, las aprobaciones
• Un momento adecuado para cada control. El screening de sanciones se realiza antes de que salga un pago. El monitoreo conductual suele ejecutarse en batch o casi en tiempo real, porque los patrones relevantes se construyen durante días y a través de múltiples cuentas. La toma de decisiones en tiempo real tiene sentido cuando necesita retener fondos antes de la liquidación en rails instantáneos, pero eso es una decisión comercial y de apetito de riesgo. Lo que exigen los reguladores es reportar con prontitud una vez que se forma la sospecha.
• Reportes que se ajusten a cada mercado en el que presenta informes. Los plazos varían mucho. Algunos regímenes exigen un reporte dentro de un día desde que se forma la sospecha y limitan cuánto puede durar la revisión interna que conduce a ese punto. Otros permiten un mes o más desde el momento de la detección. Algunos supervisores añaden una ventana esperada desde la alerta hasta la presentación además del deber legal de reportar sin demora. Una única configuración global por defecto incumplirá los requisitos más estrictos.

Evalúe a los proveedores según lo siguiente:

• Cobertura y configurabilidad. ¿Qué tipologías cubre para su sector y sus mercados? Busque una biblioteca de escenarios desde la que pueda partir y luego ajustar a su propia evaluación de riesgo.
• Explicabilidad y supervisión humana. ¿Puede un analista ver por qué se activó una alerta? Cuando interviene el machine learning, ¿puede explicarse el resultado a un regulador? El sistema prioriza el trabajo. Las decisiones las toman personas.
• Calidad de las alertas. Pida datos de precisión, no cifras de rendimiento. Su verdadera limitación es el volumen de alertas frente a la capacidad de sus analistas, no las transacciones procesadas.
• Pruebas antes de entrar en producción. ¿Puede hacer backtesting de nuevos escenarios con datos históricos y simular el volumen de alertas que produciría un cambio de umbral? Eso es lo que convierte el ajuste en algo demostrable.
• Lo que sabe sobre sus clientes. El monitoreo funciona mucho mejor cuando se basa en los datos de onboarding y de riesgo del cliente, para que la actividad se evalúe frente a lo que ya sabe y no de forma aislada.
• Operación mult mercado. Flujos de reporte y plazos configurables por mercado, soporte para formatos y portales locales, gestión de idiomas locales y diferentes conjuntos de reglas para distintas entidades sin operar sistemas separados.
• Residencia y retención de datos. ¿Dónde se procesan y almacenan los datos, y eso satisface los requisitos locales de protección y localización de datos en cada mercado? La base del FATF es de cinco años para los registros de transacciones y clientes, y varias jurisdicciones exigen más, por lo que la retención debe ser configurable y no fija.
• Controles previos a la transacción, descritos con precisión. Los controles en tiempo real pueden retener o rechazar un pago. No pueden evitar la sospecha, que es una valoración humana. Cuando retiene un pago por motivos de lavado de dinero, la ley local decide qué ocurre después, y en varias jurisdicciones necesita autorización antes de continuar. Las restricciones sobre lo que puede comunicar al cliente se aplican en todo momento. Una herramienta debe respaldar ese flujo de trabajo, no afirmar que lo elimina.
• Puesta en marcha. Plazos de implementación, migración desde su sistema actual y si puede operar ambos en paralelo el tiempo suficiente para comparar resultados antes de cambiar.
• El propio proveedor. Viabilidad, modelo de soporte, niveles de servicio y hacia dónde se dirige el producto. Está comprando una relación que debe sobrevivir a sus próximas auditorías, no solo una pieza de software.