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

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á.