Detección de fraude bancario con IA: caso práctico

TL;DR El fraude es raro, cambia rápido y cada error cuesta dinero: o pierdes la transacción fraudulenta o bloqueas a un cliente legítimo. Por eso el modelo importa menos que tres decisiones: las features de comportamiento, la métrica de evaluación (precisión y recall, nunca accuracy) y el umbral según el coste de cada error.

La detección de fraude fue uno de los primeros usos masivos del machine learning, y sigue siendo uno de los más exigentes: hay que decidir en milisegundos, con muy pocos ejemplos de fraude y con estafadores que cambian de táctica en cuanto se les bloquea. En el libro IA en Ciberseguridad uno de los casos de estudio es precisamente la detección de fraude en una banca regional. Este artículo presenta los conceptos clave con un ejemplo práctico.

Por qué el fraude es un problema difícil

Clases muy desbalanceadas: por cada transacción fraudulenta hay miles de legítimas.
Adversario activo: los defraudadores prueban qué funciona y se adaptan. Un patrón que hoy detecta todo, mañana puede no detectar nada.
Etiquetas tardías: muchas veces solo se sabe que algo fue fraude semanas después, cuando el cliente reclama.
Dos costes opuestos: dejar pasar un fraude cuesta dinero; bloquear a un cliente legítimo cuesta su confianza y, a veces, el cliente.

Features que delatan el fraude

El monto de una transacción, por sí solo, dice poco. Lo que delata el fraude es la desviación respecto al comportamiento habitual del cliente:

Feature	Por qué ayuda
Monto respecto a la media del cliente	Un gasto de 10 veces lo habitual es más sospechoso que un monto alto en sí
Transacciones en la última hora	Las tarjetas robadas se usan rápido, antes del bloqueo
Comercio o beneficiario nuevo	Primera transferencia a una cuenta desconocida
Distancia a la última ubicación	Compras presenciales en dos ciudades lejanas en pocos minutos
Hora del día respecto a lo habitual	Actividad de madrugada en un cliente que nunca opera de noche
Cambios recientes en la cuenta	Nuevo dispositivo, cambio de email o teléfono justo antes de transferir

La última fila conecta el fraude con la seguridad de la identidad: muchos fraudes empiezan con una cuenta comprometida, y las señales de acceso son tan valiosas como las de la transacción.

Ejemplo: un modelo de fraude en Python

Suponiendo que ya calculaste las features anteriores en un DataFrame, este ejemplo entrena un modelo, lo evalúa con las métricas adecuadas y elige el umbral según el coste de cada tipo de error.

import numpy as np
import pandas as pd
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import average_precision_score, classification_report

df = pd.read_parquet("transacciones_features.parquet").sort_values("fecha")

FEATURES = ["monto_vs_media", "tx_ultima_hora", "beneficiario_nuevo",
            "distancia_km", "hora_inusual", "cambio_reciente_cuenta"]

# División TEMPORAL: entrenar con el pasado y evaluar con el futuro, como en la vida real
corte = df["fecha"].quantile(0.8)
train, test = df[df["fecha"] <= corte], df[df["fecha"] > corte]

modelo = RandomForestClassifier(
    n_estimators=300,
    class_weight="balanced",   # compensa el desbalance de clases
    min_samples_leaf=5,
    n_jobs=-1,
    random_state=42,
)
modelo.fit(train[FEATURES], train["es_fraude"])
prob = modelo.predict_proba(test[FEATURES])[:, 1]

print("PR-AUC:", round(average_precision_score(test["es_fraude"], prob), 3))

# Elegir el umbral que minimiza el coste total (valores de ejemplo)
COSTE_FRAUDE_NO_DETECTADO = 500   # pérdida media por fraude
COSTE_FALSA_ALARMA = 5            # revisión manual + molestia al cliente

def coste(umbral):
    pred = prob >= umbral
    fn = ((~pred) & (test["es_fraude"] == 1)).sum()
    fp = (pred & (test["es_fraude"] == 0)).sum()
    return fn * COSTE_FRAUDE_NO_DETECTADO + fp * COSTE_FALSA_ALARMA

umbrales = np.linspace(0.05, 0.95, 19)
mejor = min(umbrales, key=coste)
print(f"Umbral óptimo: {mejor:.2f}")
print(classification_report(test["es_fraude"], prob >= mejor, digits=3))

Dos detalles que separan un ejemplo de juguete de uno serio: la división temporal (una división aleatoria mezcla pasado y futuro y da resultados optimistas) y el umbral elegido por coste de negocio, no el 0,5 por defecto.

Métricas: por qué el accuracy engaña

Si el 0,1 % de las transacciones son fraude, un modelo que nunca detecta nada tiene un 99,9 % de accuracy. Por eso se usan:

Precisión: de las transacciones que bloqueamos, cuántas eran fraude.
Recall: de todos los fraudes, cuántos detectamos.
PR-AUC (área bajo la curva precisión-recall): resume el rendimiento en todos los umbrales y es mucho más informativa que la curva ROC con datos tan desbalanceados.
Métricas de negocio: dinero recuperado, porcentaje de clientes legítimos bloqueados y carga del equipo de revisión.

En producción: latencia, deriva y explicabilidad

Latencia: la decisión se toma mientras el cliente espera en la caja o en la app. Las features de comportamiento se precalculan y se consultan en milisegundos.
Deriva: el fraude cambia. Monitoriza la distribución de las predicciones y la tasa de fraude confirmado, y reentrena con frecuencia.
Reglas y modelo juntos: las reglas cubren lo conocido y lo regulatorio; el modelo, los patrones sutiles.
Explicabilidad: el analista que revisa un caso y el cliente que reclama necesitan saber por qué se bloqueó. Técnicas como SHAP muestran qué features pesaron en cada decisión; lo tratamos en ética y gobernanza de la IA.

El mismo enfoque (features de comportamiento, modelos sobre datos desbalanceados, umbral según el coste) se aplica a otros casos del libro, como la detección de anomalías en accesos y redes.

Cuatro casos de estudio reales

Además de banca, el libro IA en Ciberseguridad analiza casos en industria manufacturera (OT/ICS), sector salud y smart cities.

Comprar en Amazon