El fraude no es un problema nuevo, pero la escala a la que ocurre hoy sí lo es. Cada pago en línea, alta de cuenta o solicitud de reembolso es una oportunidad para quien intenta engañar al sistema, y las reglas fijas que durante años frenaron los esquemas más obvios ya no bastan. Quien comete fraude se adapta rápido, tantea los límites y se esconde entre millones de transacciones legítimas.
Aquí es donde entra el machine learning. En lugar de depender de una lista de reglas escritas a mano — bloquear si el importe supera X —, un modelo aprende del histórico aquello que distingue una operación normal de una sospechosa, y sigue ajustándose a medida que los patrones cambian. Bien aplicado, detecta esquemas que ninguna regla anticiparía; mal aplicado, bloquea a clientes legítimos y deja pasar a los verdaderos defraudadores.
Esta guía recorre las decisiones que separan un sistema de detección de fraude útil de uno que solo genera ruido: qué tipo de modelo usar, qué datos alimentan la decisión, cómo lidiar con el hecho de que el fraude sea raro y cómo saber si el modelo está realmente ayudando.
Por qué el fraude es tan difícil de detectar
Antes de elegir un algoritmo, conviene entender contra qué luchamos. La detección de fraude tiene cuatro características que la hacen diferente de un problema de predicción corriente.
- Es raro. En muchos negocios, menos del 1% de las transacciones son fraudulentas. Un modelo que siempre diga "esto es legítimo" acierta el 99% de las veces y, aun así, es completamente inútil.
- El adversario se adapta. A diferencia de predecir ventas, aquí hay alguien del otro lado que cambia de táctica en cuanto nota que se ha cerrado un camino.
- El coste de equivocarse es asimétrico. Dejar pasar un fraude cuesta dinero; bloquear a un cliente legítimo cuesta confianza y, a menudo, al propio cliente. Rara vez pesan lo mismo.
- La decisión es urgente. Un pago debe aprobarse o rechazarse en milisegundos, no al día siguiente.
Cualquier enfoque serio del fraude tiene que responder a estas cuatro presiones a la vez. Por eso copiar un modelo de otro contexto rara vez funciona.
Aprendizaje supervisado vs no supervisado
Hay dos grandes caminos, y los mejores sistemas suelen combinar ambos.
En el aprendizaje supervisado, entrenamos el modelo con casos pasados ya etiquetados como fraude o no fraude. Modelos como gradient boosting (por ejemplo, XGBoost o LightGBM) o los random forests funcionan bien cuando existe un histórico fiable de fraudes confirmados. La limitación es evidente: solo aprenden a reconocer lo que ya hemos visto.
En el aprendizaje no supervisado, el modelo no recibe etiquetas: solo busca aquello que se aparta de lo normal. Técnicas como isolation forest, autoencoders o clustering señalan comportamientos anómalos, aunque nunca se hayan visto. Es la mejor defensa frente a esquemas nuevos, pero genera más falsas alarmas, porque "extraño" no es sinónimo de "fraudulento".
En la práctica, muchos equipos usan un modelo supervisado para los patrones conocidos y una capa no supervisada para detectar lo que es genuinamente nuevo, dejando los casos más ambiguos para revisión humana.
Las features que marcan la diferencia
Un modelo de fraude es tan bueno como los datos que recibe. Y, casi siempre, el valor no está en la transacción aislada, sino en el contexto en el que ocurre. Las features más útiles suelen construirse a partir del comportamiento a lo largo del tiempo:
- Velocidad: ¿cuántas transacciones salieron de esta tarjeta, dispositivo o IP en la última hora? Un salto repentino es una señal clásica.
- Desviación del hábito: ¿este cliente suele comprar a esta hora, en este país, por este importe? La comparación con su propio histórico vale más que cualquier umbral absoluto.
- Vínculos compartidos: ¿este dispositivo está asociado a decenas de cuentas distintas? ¿Varias tarjetas apuntan a la misma dirección?
- Fricción temporal: ¿cuánto tiempo pasó entre crear la cuenta y la primera compra de importe elevado?
Fíjese en que ninguna de estas features es el importe de la compra en sí. Es la ingeniería de features — convertir datos en bruto en señales con significado — la que separa un modelo mediocre de uno bueno.
El problema de los datos desequilibrados
Volvamos al hecho de que el fraude es raro. Si entrenamos un modelo con datos en los que el 99,5% de los casos son legítimos, aprende rápido que la apuesta más segura es decir siempre "legítimo". La exactitud (accuracy) global queda estupenda y el modelo no detecta nada.
Hay varias formas de sortear esto: remuestrear los datos (reducir los casos legítimos o sobrerrepresentar los fraudulentos, con técnicas como SMOTE), asignar más peso a los errores de fraude durante el entrenamiento o — lo más importante — dejar de mirar la exactitud y elegir métricas que reflejen lo que importa.
Precisión, recall y el coste de equivocarse
Dos métricas dominan la conversación en fraude, y es esencial entender la tensión entre ellas.
- Recall (sensibilidad): de todos los fraudes que ocurrieron, ¿cuántos detectó el modelo? Un recall bajo significa dinero escapándose por la puerta.
- Precisión: de todas las alertas que el modelo levantó, ¿cuántas eran realmente fraude? Una precisión baja significa clientes legítimos bloqueados y un equipo de revisión ahogado en falsas alarmas.
Subir una casi siempre baja la otra. Dónde colocar el umbral de decisión no es una pregunta técnica, sino de negocio. ¿Cuánto cuesta un fraude no detectado? ¿Y un cliente molesto al ver su tarjeta rechazada durante el almuerzo? La respuesta define el punto de equilibrio, y por eso la curva precisión-recall dice mucho más que un único porcentaje de exactitud.
Tiempo real vs análisis por lotes
No todo el fraude necesita la misma velocidad de respuesta. Autorizar un pago con tarjeta exige una decisión en tiempo real, en unas pocas decenas de milisegundos, lo que impone límites al modelo y a la infraestructura. En cambio, detectar cuentas falsas creadas en masa, o redes de colusión, puede hacerse por lotes (batch), ejecutando análisis más pesados cada hora o de noche.
Muchos sistemas combinan las dos capas: una decisión rápida en el momento, seguida de un análisis más profundo que revisa, confirma o revierte casos y, sobre todo, alimenta el modelo con nuevos ejemplos.
Cuándo el modelo empieza a fallar
Un modelo de fraude no es un proyecto que se entrega y se olvida. Como el adversario se adapta, el rendimiento se degrada de forma natural con el tiempo: es el llamado concept drift. Lo que era una señal fuerte de fraude hace seis meses puede ser hoy un comportamiento perfectamente normal.
Por eso, monitorizar el modelo en producción es tan importante como entrenarlo. Conviene seguir la tasa de alertas, la precisión confirmada por el equipo de revisión y la evolución de las features a lo largo del tiempo. Un matiz sutil pero crítico: el fraude que el modelo bloquea nunca llega a confirmarse como fraude, lo que puede engañar a las métricas. Sin una muestra de control y sin el retorno de quien investiga los casos, el modelo queda ciego a su propio error.
Minicaso: detectar más fraude sin molestar a los clientes
Una empresa de pagos en línea dependía de un conjunto de reglas fijas: bloqueaba compras por encima de cierto importe, o procedentes de ciertos países. Detectaba alrededor del 60% del fraude, pero a costa de rechazar muchas compras legítimas: la tasa de falsos positivos rondaba el 5%, y el soporte al cliente vivía lleno de reclamaciones.
El equipo introdujo un modelo de gradient boosting alimentado por features de velocidad y desviación del hábito, manteniendo las reglas antiguas solo como red de seguridad para los casos obvios. Fijaron el umbral no para maximizar la detección, sino para mantener los falsos positivos por debajo del 1%. Al cabo de tres meses, la detección de fraude subió a cerca del 85% y las compras legítimas rechazadas cayeron a menos de la mitad. La mejora no vino de un algoritmo mágico, sino de mejores features y de un umbral elegido pensando en el negocio, no solo en la estadística.
En la práctica
Detectar fraude con machine learning no es comprar el modelo más sofisticado, es diseñar un sistema que respeta la naturaleza del problema: la rareza de los casos, el adversario que se adapta y el coste real de cada tipo de error. Empiece por las features correctas, elija métricas que reflejen el negocio — precisión y recall, no exactitud —, combine modelos supervisados y no supervisados, y trate la monitorización como parte del producto, no como un extra.
Y no descarte las reglas: las mejores defensas combinan la rapidez de una regla simple para lo obvio con la sutileza de un modelo para el resto. El objetivo nunca es detectar el 100% del fraude a cualquier precio, sino encontrar el equilibrio en el que se pierde menos dinero sin ahuyentar a quienes, al final, sostienen el negocio: los clientes de buena fe.
