Juan Carlos Sanabria
CEO y Presidente de Novacomp
Juan Carlos Sanabria
CEO y Presidente de Novacomp
Introducción
En los proyectos de detección de fraude que hemos acompañado en bancos y fintechs de la región, el patrón es el mismo. El modelo se implementa, funciona bien las primeras semanas, y después empieza a fallar sin que nadie note exactamente cuándo empezó el problema. El equipo de riesgo sigue confiando en las alertas que genera, pero esas alertas ya no reflejan cómo se comporta el fraude hoy.
Un estudio reciente de LexisNexis, con datos de bancos y financieras en Argentina, Brasil, Colombia y México, encontró que cada transacción fraudulenta cuesta 3.68 veces su valor inicial una vez que se suman investigación, costos regulatorios e impacto en la experiencia del cliente. Ese multiplicador solo baja cuando el modelo se mantiene alineado con la forma en que el fraude cambia, y ahí es donde la mayoría de los bancos pierde terreno.
El fraude cambia más rápido que los modelos que lo detectan
Un modelo de detección de fraude aprende de transacciones pasadas. El problema es que quien comete el fraude ajusta su comportamiento en cuanto detecta que un patrón específico empieza a generar alertas. En la práctica, esto significa que un modelo entrenado hace doce meses puede seguir funcionando técnicamente bien y, al mismo tiempo, dejar pasar exactamente el tipo de fraude que más le está costando al banco en este momento.
En los diagnósticos que hacemos con equipos de riesgo, encontramos con frecuencia modelos que nunca se recalibraron después del lanzamiento inicial.
Nadie desactivó el modelo ni reportó una falla. Simplemente dejó de estar sincronizado con la realidad que debía vigilar.
El costo oculto de los falsos positivos
Cada vez que un modelo bloquea una transacción legítima, el banco evita una pérdida que nunca iba a ocurrir, pero corre el riesgo de perder al cliente en ese mismo momento. Los equipos de riesgo miden su desempeño por cuánto fraude detectan, casi nunca por cuántas transacciones válidas terminan bloqueadas por error.
Esa asimetría en cómo se mide el éxito explica por qué el problema de los falsos positivos rara vez llega a la mesa donde se decide el presupuesto de un proyecto de IA.
El área de riesgo reporta menos fraude. El área comercial no siempre conecta esa caída en transacciones con el modelo que la está causando.
Integrar el modelo al core bancario es la parte que casi nadie resuelve bien
La mayoría de las conversaciones sobre IA para fraude se quedan en el modelo. Qué algoritmo usar, qué tan preciso es, qué tan rápido procesa transacciones. La parte que decide si ese modelo funciona en la práctica es otra. Depende de cómo se conecta con los sistemas core que ya procesan las transacciones del banco, con frecuencia sistemas que llevan más de una década en operación.
En esa integración aparecen los problemas que rara vez se anticipan. Latencia que retrasa la respuesta al cliente en el punto de venta, formatos de datos que no coinciden entre el sistema core y el modelo, y equipos de infraestructura que terminan sosteniendo una arquitectura paralela porque nadie diseñó la integración desde el inicio del proyecto.
Qué significa gobernar un modelo de fraude en producción
Un modelo de IA para fraude no se implementa una vez y queda listo. Necesita monitoreo constante para detectar cuándo su precisión empieza a caer, un proceso de reentrenamiento definido con datos actualizados, y trazabilidad sobre cada decisión que toma, sobre todo en un sector donde un regulador puede pedir esa explicación en cualquier momento.
En nuestra experiencia acompañando a equipos de riesgo y tecnología, este es el punto donde más proyectos pierden continuidad. El modelo se entrega, el equipo que lo construyó se mueve a otro proyecto, y nadie queda a cargo de vigilar si sigue funcionando como se esperaba seis meses después.
De la implementación a la operación continua
Sostener un modelo de detección de fraude en el tiempo requiere una combinación específica. Ingeniería que integre el modelo al core sin fricción, QA que valide su comportamiento antes y después de cada actualización, y un proceso de gobierno que documente por qué el modelo decide lo que decide.
Novacomp trabaja esta combinación desde AI-based Financial Services, con QA Factory para validar modelos críticos antes de cada actualización, modernización de aplicaciones para integrarlos a arquitecturas existentes, y AI Augmented Delivery para sostener el ciclo de mejora una vez el modelo está en producción.
Conclusión
El fraude bancario seguirá evolucionando, y ningún modelo de IA, sin importar qué tan bien esté entrenado el día del lanzamiento, se mantiene preciso sin trabajo continuo detrás. La pregunta que decide si un proyecto de detección de fraude genera valor a largo plazo tiene que ver con si el banco construyó la capacidad de mantener el modelo alineado con la forma en que el fraude cambia, más que con qué tan sofisticado es el modelo el día del lanzamiento.
Para un equipo de riesgo que evalúa su próxima inversión en IA contra el fraude, vale la pena preguntar quién en la organización va a monitorear el modelo dentro de seis meses, y qué proceso existe para actualizarlo cuando el comportamiento del fraude cambie antes que él.
Si su banco o fintech está evaluando cómo sostener un modelo de detección de fraude más allá del lanzamiento inicial, conversemos sobre cómo estructurar esa operación. Agende una sesión de diagnóstico con el equipo de AI-based Financial Services de Novacomp para revisar el estado actual de sus modelos en producción.
