Banca y IA: detección de fraude en tiempo real

47 milisegundos para decidir

Ese es el presupuesto de tiempo. Un cliente pasa su tarjeta en un comercio y el sistema de detección de fraude tiene 47 milisegundos de media para decidir si la transacción es legítima o fraudulenta. Demasiado lento y la experiencia de compra se degrada. Demasiada agresividad y bloqueas transacciones legítimas, perdiendo clientes. Demasiada permisividad y el fraude se come los márgenes.

El fraude con tarjetas de pago en Europa alcanzó los 1.550 millones de euros en 2023, según el BCE. España concentra el 11% de ese fraude, unos 170 millones de euros. Las entidades financieras españolas han invertido fuertemente en sistemas de detección basados en inteligencia artificial, y los resultados son medibles: BBVA reporta una reducción del 60% en fraude no detectado desde que desplegaron su sistema actual. CaixaBank identifica el 97% de las transacciones fraudulentas. Santander mantiene una tasa de falsos positivos por debajo del 0,3%.

Cómo funcionan estos sistemas?

Feature engineering: el trabajo invisible

El modelo de ML no ve “una transacción.” Ve un vector de 150-300 features derivadas de la transacción, el histórico del cliente, y patrones globales. La calidad de esas features es lo que separa un sistema que detecta el 80% del fraude de uno que detecta el 97%.

Features transaccionales. Las obvias: importe, tipo de comercio, país, hora del día, canal (presencial, online, contactless). Las menos obvias: distancia respecto a la transacción anterior, tiempo transcurrido desde la última transacción, ratio del importe respecto al gasto medio del cliente, desviación del patrón de gasto por día de la semana.

Features de perfil de cliente. Patrón de gasto histórico (media, desviación típica, percentiles), comercios habituales, países habituales, horarios habituales, métodos de pago preferidos. Un cliente que siempre compra en supermercados de Madrid entre lunes y viernes y de repente tiene una transacción en un casino de Macao a las 3 de la madrugada genera un vector de features que grita anomalía.

Features de red. Aquí está la ventaja competitiva real. Las transacciones no ocurren aisladas. Un comercio que en la última hora ha procesado 15 transacciones de tarjetas comprometidas es un punto de compromiso (POS compromise). Un grupo de tarjetas que comparten la misma dirección de envío en compras online es un patrón de fraude organizado. Estas features de red (graph features) son las más potentes y las más difíciles de calcular en tiempo real.

Features de velocidad. Número de transacciones en los últimos 5 minutos, 1 hora, 24 horas. Número de comercios distintos en la última hora. Número de países distintos en las últimas 24 horas. Un cliente que tiene transacciones en tres países en 4 horas no está viajando; está siendo víctima de fraude.

Arquitectura de modelos

Los sistemas de detección de fraude en producción no usan un único modelo. Usan una cascada:

Capa 1: Reglas deterministas. Rápidas, interpretables, inamovibles. “Toda transacción superior a 10.000 euros requiere autorización manual.” “Toda transacción desde un país en lista de riesgo con tarjeta no presente pasa a revisión.” Las reglas capturan el fraude obvio y reducen la carga del modelo.

Capa 2: Modelo de scoring. Típicamente un gradient boosted tree (XGBoost o LightGBM) entrenado sobre millones de transacciones históricas etiquetadas. El modelo asigna un score de 0 a 1000 a cada transacción. Por encima de un umbral (digamos 800), se bloquea. Por debajo de otro (digamos 200), se aprueba. En la zona gris intermedia, se aplican reglas adicionales o se escala a revisión manual.

Por qué gradient boosting y no deep learning? Porque es rápido (inferencia en 2-5ms), interpretable (puedes explicar por qué una transacción se bloqueo, requisito regulatorio de PSD2), y funciona extraordinariamente bien con features tabulares. Los modelos de deep learning son superiores en texto e imagen, pero para datos tabulares estructurados, XGBoost sigue siendo el rey.

Capa 3: Modelos de anomalía. Isolation Forest o autoencoders que detectan patrones que no estaban en los datos de entrenamiento. El fraude evoluciona. Cada seis meses aparecen técnicas nuevas que los modelos supervisados no han visto. Los modelos de anomalía no saben qué es fraude, pero saben que algo es diferente. Esa señal se combina con el score de la capa 2. Para profundizar en cómo llevar estos modelos a producción con las métricas correctas, consulta nuestro artículo sobre MLOps: del notebook al pipeline de producción. Si quieres ver cómo se combina esta cascada de modelos en una arquitectura de extremo a extremo, la guía de arquitectura para detección de fraude en tiempo real cubre el diseño completo del sistema.

Scoring en tiempo real

Los 47 milisegundos incluyen llamada de red, extracción de features, inferencia del modelo, y respuesta. La arquitectura típica:

1. La transacción llega al gateway de pagos.
2. Un servicio de enrichment extrae las features del cliente desde una cache en memoria (Redis o similar). Las features de perfil se precalculan cada hora. Las features de velocidad se actualizan en streaming.
3. El modelo de scoring recibe el vector de features y devuelve un score. El modelo está desplegado como un servicio gRPC con carga en memoria.
4. Un motor de decisión aplica el score junto con las reglas de negocio y devuelve la decisión: aprobar, rechazar, o escalar.

El cuello de botella no es el modelo (que tarda 2-5ms) sino la extracción de features. Las features de red (cuántas transacciones fraudulentas ha tenido este comercio esta semana?) requieren consultas a grafos que pueden ser lentas. La solución es precomputar y cachear. Se pierde frescura (la feature puede tener 5 minutos de retraso) pero se gana latencia.

La guerra de los falsos positivos

Un sistema que bloquea el 100% del fraude pero también bloquea el 5% de las transacciones legítimas es un desastre comercial. Un banco grande procesa 50 millones de transacciones al mes. El 5% son 2,5 millones de clientes frustrados, llamadas al call center, y potencialmente clientes perdidos.

La métrica clave es la precisión al nivel de recall objetivo. Si tu objetivo es detectar el 95% del fraude (recall), la pregunta es: cuántas transacciones legítimas bloqueas para conseguirlo? Un sistema bueno mantiene la tasa de falsos positivos por debajo del 0,5% a ese nivel de recall. Un sistema excelente, por debajo del 0,2%.

La gestión de falsos positivos incluye:

• Autenticación escalonada. En vez de bloquear, pedir verificación adicional (código SMS, notificación push) para transacciones en la zona gris.
• Feedback loop. Cada transacción que el cliente confirma como legítima retroalimenta el modelo. El sistema aprende los patrones individuales y reduce falsos positivos con el tiempo.
• Segmentación de umbrales. No usar el mismo umbral para todos. Un cliente con histórico de 10 años y patrón predecible puede tener un umbral más permisivo que un cliente nuevo.

El fraude bancario es una carrera armamentista. Los defraudadores adaptan sus técnicas. Los modelos se reentrenan. Las reglas se ajustan. No hay un sistema que “resuelva” el fraude. Hay sistemas que lo mantienen en un nivel gestionable. Y la diferencia entre gestionable e insostenible, en un banco mediano, son decenas de millones de euros al año. Si quieres entender cómo funciona el gobierno de IA empresarial en el contexto regulatorio del sector fintech, lo cubrimos en detalle.