Contexto
NovaPay México es una fintech de pagos y vales electrónicos que procesa transacciones B2B2C para más de 4,000 empresas afiliadas (nómina, vales de despensa, pagos corporativos). Ante el crecimiento de fraude digital en México, NovaPay identificó que su motor de reglas estático generaba demasiados falsos positivos y no podía reaccionar a patrones emergentes: identidades sintéticas, ataques coordinados y "card testing".
El reto
- Latencia máxima aceptable de autorización: 200 ms.
- Datos transaccionales y biométricos clasificados como sensibles bajo la LFPDPPP, sin posibilidad de enviarlos a APIs de terceros fuera de México.
- Necesidad de explicabilidad para auditorías de CNBV y disputas de contracargo.
- Equipo de analistas de fraude saturado: revisaban manualmente miles de alertas diarias con alta tasa de falsos positivos.
La solución: modelos privados on-premise
En lugar de depender de un proveedor SaaS externo, NovaPay optó por desplegar modelos propios, alojados en su propia infraestructura (VPC privada en territorio nacional), entrenados con sus propios datos históricos de transacciones.
ARQUITECTURA
- Ingesta en streaming: Kafka captura cada transacción en el momento de la autorización.
- Feature store en tiempo real: variables de comportamiento (dispositivo, geolocalización, velocidad de transacciones, huella de tecleo) calculadas en milisegundos.
- Modelo híbrido: gradient boosting (XGBoost) para score inicial de bajo costo computacional + red neuronal de grafos (GNN) para detectar anillos de fraude coordinado entre cuentas relacionadas.
- Two-step scoring: decisión rápida en el primer salto; si el resultado es incierto, se añaden señales adicionales (verificación de dispositivo, liveness) y se re-puntúa antes de autorizar o bloquear.
- Todo el pipeline corre dentro de la infraestructura de NovaPay — ningún dato transaccional sale hacia terceros, cumpliendo con requisitos regulatorios y de soberanía de datos.
- Reentrenamiento continuo: los modelos se reentrenan semanalmente con retroalimentación de analistas humanos, quienes validan los casos límite.
Resultados a 8 meses
| Métrica | Antes | Después |
| Tiempo de decisión por transacción | ~1.2 s (reglas estáticas) | <150 ms |
| Falsos positivos | Base 100% | -58% |
| Fraude detectado antes de liquidar | 41% | 89% |
| Pérdidas directas por fraude | Base 100% | -63% |
| Alertas revisadas manualmente por analista/día | ~220 | ~70 (mayor riesgo) |
El equipo de analistas dejó de revisar transacciones triviales y se enfocó en investigar patrones complejos y mejorar las reglas del modelo — el rol pasó de operativo a analítico.
Factores clave de éxito
- Modelos privados, no dependencia de terceros: control total sobre los datos y cumplimiento regulatorio sin fricción legal.
- Arquitectura de baja latencia desde el diseño, no como optimización posterior.
- Humano en el circuito para casos límite, evitando bloquear clientes legítimos.
- Reentrenamiento continuo como proceso operativo, no como proyecto único.
Lección para replicar
El diferenciador no fue solo "usar IA", sino tener el modelo corriendo dentro de la propia infraestructura, entrenado con datos propios y sin exponer información transaccional sensible a servicios externos — algo especialmente relevante para instituciones financieras y de pagos en México sujetas a CNBV y LFPDPPP.