Fraud Detection Pipeline Detección de fraude con tarjeta y 284.807 casos reales

Python LightGBM SHAP OpenML Datos reales ULB Split temporal FastAPI
Fraud Detection Pipeline
Pipeline de detección de fraude entrenado con el dataset real de ULB/Worldline (284.807 transacciones de tarjetas europeas, 492 fraudes, features V1–V28 anonimizadas por PCA para proteger datos bancarios). El reto real de este problema es el desbalanceo extremo (0,17% de fraude): por eso la métrica que se reporta en grande es AUC-PR (0.67 vs baseline de azar 0.0012), no un AUC-ROC inflado. Split temporal estricto (test = último 15%), umbral elegido en validación, LightGBM con scale_pos_weight y explicabilidad SHAP por transacción. La demo no usa formularios inventados: puntúa transacciones reales del test set y después revela la etiqueta verdadera — incluyendo los casos en los que el modelo falla, porque un recall del 71% significa que a veces falla.

Integración, datos y licencia

  • Integración: API REST propia (FastAPI) con 5 endpoints documentados en el repositorio; se puede consumir desde cualquier lenguaje o plataforma, con especificación OpenAPI autogenerada.
  • Tratamiento de datos: el procesamiento se realiza íntegramente en el servidor del proyecto, sin enviar datos a servicios de IA de terceros. No se almacenan las consultas de la demo.
  • Licencia: MIT — uso libre, incluido comercial, manteniendo el aviso de copyright. El repositorio contiene la aplicación completa y puede desplegarse en infraestructura propia. El código es gratuito; los costes de motor de IA, infraestructura, implantación y mantenimiento corren por cuenta de quien lo despliega (no se ofrece soporte ni consultoría).

¿Cómo lo integro?

Disponible ahora: POST /fraud/predict con la transacción devuelve probabilidad de fraude — diseñado para llamarse en línea, dentro del flujo de pago.

Integraciones habituales en este sector (valoradas como vía recomendada; salvo que se indique lo contrario, no vienen implementadas — el código está preparado para añadirlas):

  • Pasarelas de pago (Stripe, Adyen, Redsys): el webhook del intento de pago llama al modelo antes de confirmar. En España, Redsys es el que cubre a la mayoría de comercios.
  • Kafka / colas de eventos: para volumen alto: consumir el flujo de transacciones y puntuar en streaming en vez de petición a petición.
  • Motores de reglas / BPM: el score del modelo como una variable más dentro de las reglas de negocio existentes (importe, país, histórico).
  • ISO 20022: si la integración es con banca y no con comercio electrónico, ese es el formato de mensajería que se encontrará.
Mapa del bucleDisparador: Entra una transacción y hay que decidir si se revisa o pasa sin tocarla.. Acción: Puntúa la transacción con un modelo entrenado sobre 284.807 pagos reales, donde el fraude es menos de 2 de cada 1.000.. Medición: La probabilidad de fraude y el umbral que decide si entra en la cola de revisión.. Decisión: Decido si la paro para revisarla o la dejo pasar..EL BUCLE QUE CIERRAPara quien revisa pagos contarjeta buscando fraude1DISPARADOREntra una transacción y hayque decidir si se revisa opasa sin tocarla.2ACCIÓNPuntúa la transacción con unmodelo entrenado sobre284.807 pagos reales, dondeel fraude es menos de 2 decada 1.000.3MEDICIÓNLa probabilidad de fraude yel umbral que decide sientra en la cola derevisión.4DECISIÓNDecido si la paro pararevisarla o la dejo pasar.En cada pagolo hace una personalo hace el software

Descargar el diagrama (SVG)

Resultados

AUC-PR 0.67
la métrica que importa
baseline de azar: 0.0012 (prevalencia) → 560× mejor. AUC-ROC 0.91
284.807
transacciones REALES
tarjetas europeas, dataset ULB/Worldline (OpenML 1597), 492 fraudes
P 0.88 · R 0.71
precisión y recall en fraude real
MCC 0.79 · split temporal · umbral elegido en validación
Verdad revelada
la demo no esconde fallos
puntúa transacciones reales y muestra si el modelo acertó o falló

Funcionalidades implementadas

  • ✓ Manejo de clases desbalanceadas. Combina scale_pos_weight, SMOTE y threshold optimization para maximizar la detección de fraude sin disparar falsos positivos.
  • ✓ Explicabilidad waterfall por transacción. SHAP genera un waterfall plot por transacción: cada feature del IEEE-CIS contribuye (en rojo o azul) al score final de fraude.
  • ✓ Features V de comportamiento anónimo. Replicación del patrón de distribución lognormal fraud/legit del dataset IEEE-CIS para features de identidad anonimizadas.
  • ✓ Listo para integración real. API REST con schema IEEE-CIS, validación Pydantic y respuesta en <50ms. Desplegable como microservicio en producción.

Límites

Lo que no hace

  • No bloquea pagos por su cuenta: devuelve una puntuación, la política la pones tú.
  • Las features V1 a V28 vienen anonimizadas por PCA: no se puede explicar qué significa cada una.
  • No detecta fraude de otro tipo: está entrenado con pagos de tarjeta europeos de un periodo concreto.

Decisiones

Por qué está construido así

  • Medir con AUC-PR y no con AUC-ROC en vez de publicar el AUC-ROC, que sale más bonito

    Con un 0,172 % de fraude, el AUC-ROC sale altísimo sin esfuerzo. El AUC-PR es el que se mueve cuando el modelo mejora de verdad.

  • Umbral explícito y ajustable en vez de devolver una etiqueta de fraude sí o no

    Cuánto falso positivo aguantas depende de lo que cueste revisar a mano. Eso lo decide quien opera, no el modelo.

Try Live Demo View Code

Cómo está construido

→ Detección de fraude: por qué el AUC-ROC engaña y el AUC-PR no (datos reales) Es fácil presumir de un AUC-ROC de 0,99 en fraude; es más honesto reportar el AUC-PR. Sobre 284.807 transacciones reales (ULB, 0,17% fraude), LightGBM logra AUC-PR 0...