El problema: fraude creciente en pagos digitales
Una fintech en Latinoamérica procesaba más de 2 millones de transacciones mensuales. El fraude representaba el 4.2% del volumen total — más del doble del benchmark de la industria (1.5–2%). Las reglas manuales existentes bloqueaban transacciones legítimas (falsos positivos del 18%) mientras dejaban pasar patrones sofisticados de fraude.
El costo no era solo financiero: cada transacción fraudulenta generaba chargebacks, pérdida de confianza del usuario y riesgo regulatorio.
La solución: detección en tiempo real con ML
Diseñamos e implementamos un sistema de detección de fraude en 3 capas:
Capa 1: Feature engineering
El 80% del valor de un modelo de ML está en las features. Construimos 147 features en 4 categorías:
- Transaccionales: monto, frecuencia, velocidad entre transacciones, desviación del patrón habitual
- De dispositivo: fingerprint del dispositivo, geolocalización, cambios de IP, User-Agent
- De comportamiento: hora del día, día de la semana, patrones de navegación pre-transacción
- De red: relaciones entre cuentas (mismo dispositivo, misma IP, beneficiarios compartidos)
Las features de red fueron las más discriminativas. Un patrón común de fraude involucra múltiples cuentas "limpia" que convergen en un mismo beneficiario.
Capa 2: Modelo de clasificación
Evaluamos 4 algoritmos y seleccionamos XGBoost por su balance entre rendimiento, interpretabilidad y velocidad de inferencia:
| Modelo | AUC-ROC | Precisión | Recall | Latencia (p99) |
|---|---|---|---|---|
| Logistic Regression | 0.89 | 0.82 | 0.71 | 2ms |
| Random Forest | 0.93 | 0.88 | 0.79 | 15ms |
| XGBoost | 0.96 | 0.92 | 0.85 | 8ms |
| Neural Network | 0.95 | 0.90 | 0.86 | 45ms |
La red neuronal tenía recall similar pero latencia 5× mayor — inaceptable para decisiones en tiempo real.
Capa 3: Sistema de decisión
No todo se decide con ML. El sistema combina:
- Reglas deterministas: Bloqueo inmediato para patrones conocidos (tarjetas robadas confirmadas, IPs en blacklist)
- Score del modelo: Probabilidad de fraude (0–1)
- Umbral dinámico: Ajustado por segmento de riesgo del comercio y monto de la transacción
- Revisión manual: Transacciones en la zona gris (score 0.4–0.7) van a un equipo de analistas
Arquitectura de producción
El sistema procesa decisiones en menos de 100ms end-to-end:
Transacción → API Gateway → Feature Store (Redis)
↓
Feature Pipeline (Flink)
↓
Modelo XGBoost (servido con BentoML)
↓
Motor de Decisión → Aprobar / Rechazar / Revisar
Componentes clave:
- Feature Store en Redis: Features pre-computadas con TTL de 24h para features de ventana temporal
- Apache Flink: Streaming de features en tiempo real (ventanas de 1h, 24h, 7d)
- BentoML: Serving del modelo con batching automático y health checks
- PostgreSQL: Log de decisiones para auditoría y reentrenamiento
Resultados en producción
Después de 4 meses en producción:
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Tasa de fraude | 4.2% | 1.1% | -73% |
| Falsos positivos | 18% | 3.2% | -82% |
| Tiempo de decisión | 2-5 min (manual) | 85ms | ~99.9% |
| Chargebacks mensuales | ~8,400 | ~2,200 | -74% |
El ROI se alcanzó en el segundo mes. La reducción en chargebacks y la mejora en conversión (menos bloqueos de transacciones legítimas) generaron un impacto neto positivo de $2.1M USD anualizados.
Lecciones aprendidas
Lo que funcionó
- Features de red fueron el mayor diferenciador. Los patrones de relación entre cuentas son más difíciles de falsificar que las features individuales.
- Umbral dinámico por segmento evitó un modelo "one-size-fits-all" que habría sido demasiado agresivo para comercios de bajo riesgo.
- Monitoreo de drift con alertas automáticas cuando la distribución de features cambia significativamente.
Lo que no funcionó al principio
- Oversampling agresivo (SMOTE) en el entrenamiento inicial generó un modelo demasiado sensible. Pasamos a focal loss con XGBoost para manejar el desbalance de clases.
- Features de geolocalización tenían baja discriminación en LATAM por la prevalencia de VPNs y redes móviles con IPs dinámicas.
Lo que haríamos diferente
- Implementar explicabilidad desde el día 1 (SHAP values por transacción). El equipo de compliance lo necesitaba para justificar rechazos ante reguladores y llegó 6 semanas tarde.
- Invertir más en synthetic data para entrenar contra patrones de fraude emergentes antes de que aparezcan en producción.
Caso fintech descrito arriba. Mismo volumen y población de actores; el stack ML reemplaza la detección solo por reglas.
- Baseline pre-ML
- Post-ML (90 días)
Métricas de cliente anonimizadas.
Impacto de negocio
Cómo Numoru lo productiza
Los rollouts de fraud detection son de los ROI más claros en fintech — reducir pérdidas + chargebacks se ve en el P&L el primer trimestre. Numoru lo vende como engagement de 3-4 meses con threshold de métrica garantizado más un retainer MLOps que mantiene fresco el modelo contra drift adversario.
Ticket fraud-detection por comprador (Numoru 2026, USD)
Stripe Radar — benchmarks de detección
IBM — Cost of a Data Breach (segmento fintech)
Fintech desplegando stack Numoru (12 meses)
| Engagement (one-time) | −$140,000 |
| MLOps (12 mo × $6k) | −$72,000 |
| Fraude evitado (3.1% × 2M × $38 × 12) | +$28,272,000 |
| Conversión recuperada por menos FP (12 × $280k) | +$3,360,000 |
| Contribución neta año 1 | +$31,420,000 |
- Auditoría de métricas baseline
- Cobertura de features
- Análisis costo-de-fraude
- Roadmap + quick wins
- Pipeline + feature store
- XGBoost + modelos GNN
- Decision engine + case mgmt
- Explainability (SHAP)
- Artefactos de compliance
- Retraining semanal
- Monitoreo de drift
- Red-team adversario
- Reporting regulatorio
Conclusión
La detección de fraude con ML no es magia — es ingeniería de features, selección cuidadosa de modelo, y un sistema de decisión que combina automatización con supervisión humana.
El componente más valioso no fue el modelo en sí, sino la infraestructura de features en tiempo real que permite reaccionar en milisegundos a patrones que ningún equipo humano podría detectar a escala.