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 deteccion de fraude tiene 47 milisegundos de media para decidir si la transaccion es legitima o fraudulenta. Demasiado lento y la experiencia de compra se degrada. Demasiada agresividad y bloqueas transacciones legitimas, perdiendo clientes. Demasiada permisividad y el fraude se come los margenes.

El fraude con tarjetas de pago en Europa alcanzo los 1.550 millones de euros en 2023, segun 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 deteccion basados en inteligencia artificial, y los resultados son medibles: BBVA reporta una reduccion 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%.

Como funcionan estos sistemas?

Feature engineering: el trabajo invisible

El modelo de ML no ve “una transaccion.” Ve un vector de 150-300 features derivadas de la transaccion, el historico 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, pais, hora del dia, canal (presencial, online, contactless). Las menos obvias: distancia respecto a la transaccion anterior, tiempo transcurrido desde la ultima transaccion, ratio del importe respecto al gasto medio del cliente, desviacion del patron de gasto por dia de la semana.

Features de perfil de cliente. Patron de gasto historico (media, desviacion tipica, percentiles), comercios habituales, paises habituales, horarios habituales, metodos de pago preferidos. Un cliente que siempre compra en supermercados de Madrid entre lunes y viernes y de repente tiene una transaccion en un casino de Macao a las 3 de la madrugada genera un vector de features que grita anomalia.

Features de red. Aqui esta la ventaja competitiva real. Las transacciones no ocurren aisladas. Un comercio que en la ultima hora ha procesado 15 transacciones de tarjetas comprometidas es un punto de compromiso (POS compromise). Un grupo de tarjetas que comparten la misma direccion de envio en compras online es un patron de fraude organizado. Estas features de red (graph features) son las mas potentes y las mas dificiles de calcular en tiempo real.

Features de velocidad. Numero de transacciones en los ultimos 5 minutos, 1 hora, 24 horas. Numero de comercios distintos en la ultima hora. Numero de paises distintos en las ultimas 24 horas. Un cliente que tiene transacciones en tres paises en 4 horas no esta viajando; esta siendo victima de fraude.

Arquitectura de modelos

Los sistemas de deteccion de fraude en produccion no usan un unico modelo. Usan una cascada:

Capa 1: Reglas deterministas. Rapidas, interpretables, inamovibles. “Toda transaccion superior a 10.000 euros requiere autorizacion manual.” “Toda transaccion desde un pais en lista de riesgo con tarjeta no presente pasa a revision.” Las reglas capturan el fraude obvio y reducen la carga del modelo.

Capa 2: Modelo de scoring. Tipicamente un gradient boosted tree (XGBoost o LightGBM) entrenado sobre millones de transacciones historicas etiquetadas. El modelo asigna un score de 0 a 1000 a cada transaccion. 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 revision manual.

Por que gradient boosting y no deep learning? Porque es rapido (inferencia en 2-5ms), interpretable (puedes explicar por que una transaccion 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 anomalia. Isolation Forest o autoencoders que detectan patrones que no estaban en los datos de entrenamiento. El fraude evoluciona. Cada seis meses aparecen tecnicas nuevas que los modelos supervisados no han visto. Los modelos de anomalia no saben que es fraude, pero saben que algo es diferente. Esa señal se combina con el score de la capa 2. Para profundizar en como llevar estos modelos a produccion con las metricas correctas, consulta nuestro articulo sobre MLOps: del notebook al pipeline de produccion.

Scoring en tiempo real

Los 47 milisegundos incluyen llamada de red, extraccion de features, inferencia del modelo, y respuesta. La arquitectura tipica:

1. La transaccion 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 esta desplegado como un servicio gRPC con carga en memoria.
4. Un motor de decision aplica el score junto con las reglas de negocio y devuelve la decision: aprobar, rechazar, o escalar.

El cuello de botella no es el modelo (que tarda 2-5ms) sino la extraccion de features. Las features de red (cuantas transacciones fraudulentas ha tenido este comercio esta semana?) requieren consultas a grafos que pueden ser lentas. La solucion 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 tambien bloquea el 5% de las transacciones legitimas 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 metrica clave es la precision al nivel de recall objetivo. Si tu objetivo es detectar el 95% del fraude (recall), la pregunta es: cuantas transacciones legitimas 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 gestion de falsos positivos incluye:

• Autenticacion escalonada. En vez de bloquear, pedir verificacion adicional (codigo SMS, notificacion push) para transacciones en la zona gris.
• Feedback loop. Cada transaccion que el cliente confirma como legitima retroalimenta el modelo. El sistema aprende los patrones individuales y reduce falsos positivos con el tiempo.
• Segmentacion de umbrales. No usar el mismo umbral para todos. Un cliente con historico de 10 años y patron predecible puede tener un umbral mas permisivo que un cliente nuevo.

El fraude bancario es una carrera armamentista. Los defraudadores adaptan sus tecnicas. 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 ano. Si quieres entender como funciona el gobierno de IA empresarial en el contexto regulatorio del sector fintech, lo cubrimos en detalle.