Si un motor de fraude llega tarde, pierde por los dos lados: deja pasar fraude o frena compras buenas. Ese es el punto central. En pagos online, no alcanza con detectar bien: hay que decidir dentro de una ventana muy corta, que en e-commerce suele estar por debajo de 250 ms y en POS por debajo de 100 ms.
Yo lo resumiría así:
Para que se vea de un golpe, dejo una comparación corta de los presupuestos de latencia que más pesan:
| Canal | Objetivo de latencia |
|---|---|
| POS | < 100 ms |
| E-commerce | < 250 ms |
| Login / ATO | < 500 ms |
| Transferencias A2A | < 1.000 ms |
| Alta de cuenta | < 2.000 ms |
En pocas palabras, yo no miraría la latencia como un detalle de infraestructura. La miraría como una parte directa de la tasa de fraude, de la tasa de rechazo y de la conversión.
Latencia en Detección de Fraudes: Presupuestos por Canal y Costo del Fraude vs. Falsos Rechazos
Antes de meternos en los números, conviene separar dos ideas que la literatura trata por separado.
La latencia de decisión online es el tiempo que tiene el sistema para aprobar, rechazar o escalar una transacción mientras esa transacción todavía puede frenarse antes de la autorización final. Dicho simple: es el reloj que corre desde que entra la solicitud de autorización hasta que el motor devuelve una respuesta.
El tiempo hasta la detección apunta a otra cosa. Mide cuánto tarda el sistema en identificar un ataque más grande, como una red de cuentas mula o una campaña de toma de cuentas. Acá puede haber ventanas de segundos, pero sigue siendo un dato clave para cortar el daño antes de que el fraude se expanda.
Las dos métricas importan, pero no en el mismo momento. La primera define si se frena una transacción puntual. La segunda define si se logra cortar un ataque que ya está en marcha.
Con esa diferencia clara, el próximo punto es cuánto tiempo aguanta cada canal antes de caer en timeout.
Cada canal tiene su propio límite de tiempo. Si el motor se pasa de ese límite, cae en timeout o entra en reglas de respaldo. Y eso puede terminar en autorizaciones sin el nivel de control esperado o en rechazos que no hacían falta.
Acá hay un punto que aparece una y otra vez en los estudios: el promedio de latencia puede engañar. Lo que de verdad manda es el p99 y el p99,9. O sea, cuánto tarda el sistema en el 1% o el 0,1% de los casos más lentos. Ahí es donde aparecen los timeouts de producción.
Ese presupuesto no es igual para todos los canales. Cambia según el caso de uso y, en la práctica, marca el margen que tiene el motor para decidir.
| Canal / Caso de uso | Presupuesto p99 | Contexto |
|---|---|---|
| Tarjeta presente (POS) | < 100 ms | Límite máximo típico de los SLAs de Visa/Mastercard |
| E-commerce (tarjeta no presente) | < 250 ms | Crítico para evitar el abandono de checkout |
| Login / prevención de ATO | < 500 ms | Los usuarios toleran una pausa breve por seguridad |
| Transferencias A2A | < 1.000 ms | Estándar para screening de pagos salientes |
| Apertura de cuenta | < 2.000 ms | Permite señales de KYC e identidad más ricas |
Los casos concretos ayudan a poner esto en escala. Mastercard evalúa más de 160.000 millones de transacciones por año, con modelos de IA que operan en menos de 50 ms dentro de un presupuesto total de 300 ms. Coinbase, por su lado, calcula más de 250 features de ML con latencias p99 por debajo de 100 ms usando Spark Real-Time Mode.
Un buen AUC offline no arregla una inferencia lenta en producción. Por eso, los equipos de fraude miran al mismo tiempo métricas de calidad y métricas operativas.
Del lado de la calidad del modelo, las métricas más usadas son precisión, recall, AUC y MCC (Matthews Correlation Coefficient). Del lado operativo, lo que define si el sistema funciona en producción es el cumplimiento del SLA, la tasa de timeout y la tasa de falsos rechazos (false decline rate).
En otras palabras, un modelo puede verse muy bien en laboratorio y aun así fallar donde importa. Si mejora el AUC pero empuja el p99 por arriba del presupuesto del canal, no resolvió el problema: sumó otro.
La elección del modelo también pega directo en la latencia. Los árboles de gradiente como XGBoost o LightGBM suelen dar tiempos de inferencia de 2 a 15 ms y quedan bien parados para scoring transaccional estándar. Los Transformers y las redes neuronales de grafos (GNN) pueden detectar patrones más complejos, pero agregan entre 50 y 300 ms. En muchos entornos, esa diferencia define si el modelo llega a tiempo o dispara un timeout.
En producción, la pregunta no es solo qué tan bien predice. La pregunta es si predice dentro del límite. Por eso, en fraude en tiempo real, la arquitectura pesa tanto como la precisión.
Con el presupuesto de latencia ya definido, la conversación cambia. Ya no alcanza con preguntar qué tan bien predice un modelo. La pregunta que importa es otra: si llega a decidir a tiempo.
Ahí aparece el problema de fondo. Un modelo más complejo puede mostrar mejores resultados offline, pero perder peso en la operación si se pasa del presupuesto de latencia del canal. Si cruza ese límite, el motor deja de prevenir en tiempo real. Y en ese punto, el modelo pierde utilidad en producción.
Por eso, actores como Mastercard priorizan arquitecturas optimizadas - RNNs y Gradient Boosting - por encima de modelos más pesados como los Transformers, para sostener tiempos de inferencia por debajo de 50 ms. En la práctica, los modelos livianos y las reglas quedan al frente de la decisión dentro del SLA. Los modelos más pesados pasan a capas secundarias o a procesos con más margen de latencia.
Cuando el motor empieza a rozar el límite, los equipos suelen recortar complejidad en las reglas y terminan subiendo los falsos rechazos. Y ese costo ya no es menor. De hecho, los falsos rechazos ya superan al fraude real: US$ 443.000 millones frente a US$ 48.000 millones en 2025, y un tercio de los clientes rechazados no vuelve a comprar. Entre clientes de alto valor, la tasa de abandono es entre 3 y 5 veces mayor que el promedio.
Dicho simple: cuando el sistema se apura para cumplir el SLA, muchas veces la cuenta la paga el cliente.
En un flujo de alto volumen, sumar 200 o 300 ms puede alcanzar para perder conversión. En mobile, el margen es todavía más chico. Si el motor no responde a tiempo, entra en timeout o activa un fallback, y ahí aparecen rechazos innecesarios.
El golpe viene por los dos lados al mismo tiempo: pasa fraude y se pierden ventas. Por eso, la pregunta que sigue no es solo qué modelo conviene usar, sino qué arquitectura puede sostener esa latencia en producción.
Con la latencia ya acotada por canal, la pregunta deja de ser cuánto tarda cada flujo y pasa a ser qué arquitectura puede sostener ese tiempo. Ahí se juega el SLA. Un diseño flojo puede tirar abajo incluso un buen sistema de scoring.
En los estudios más recientes se ve un cambio claro: muchas empresas están dejando atrás el procesamiento por lotes y pasando a arquitecturas orientadas a eventos. Herramientas como Kafka y Flink permiten separar la ingesta del scoring y procesar cada transacción apenas entra, en vez de esperar a juntar datos para analizarlos después. Y eso, en fraude, cambia todo. El fraude que está pasando ahora no espera al próximo ETL.
En producción, el patrón que mejor rinde es la decisión en cascada. Primero entra un motor de reglas determinísticas, como OPA o Drools, que resuelve los casos conocidos en menos de 5 ms. Si la transacción no coincide con ninguna regla, pasa a un modelo de ML liviano, como XGBoost o LightGBM, que suele responder entre 15 y 40 ms.
Dicho simple:
Redis baja las lecturas a menos de 10 ms. Y si el scoring y las variables están co-ubicados en la misma zona, la ida y vuelta de red puede quedar en 5-10 ms.
La arquitectura no se sostiene sola. Funciona bien solo si los desvíos aparecen antes de pegarle a producción. Por eso, monitorear p99, tasa de timeout, tasa de fallback y deriva del score no es opcional.
El p99 muestra ese 1 % de transacciones que tarda más de lo previsto. Cuando ese número sube, suele pasar una de dos cosas: baja la prevención o suben los falsos rechazos. Ninguna de las dos conviene.
Instrumentar las distribuciones de variables con histogramas de Prometheus y dejar alertas automáticas cuando el PSI supera 0,2 ayuda a detectar cambios en el entorno antes de que le peguen al modelo.
En e-commerce, el problema de latencia no termina en el pago. Plataformas como Burbuxa, que sincronizan en tiempo real órdenes, inventario, clientes, descuentos y conversaciones de WhatsApp e Instagram con tiendas en Shopify, Tiendanube, VTEX y stacks propios vía API, trabajan con varios flujos de datos al mismo tiempo. Y cada uno trae su propio presupuesto de latencia y sus propias reglas de gobernanza.
La tabla siguiente resume algunos objetivos de latencia p99 según el tipo de transacción.
| Tipo de transacción | Latencia objetivo (p99) | Controles de gobernanza |
|---|---|---|
| E-commerce (CNP) | < 250 ms | Monitoreo de TRA/PSD2, alertas PSI |
| Conversacional (WhatsApp) | < 500 ms | Trazabilidad, explicabilidad (SHAP) |
| Tiendas vía API | < 200 ms | Alertas p99, seguimiento de timeouts |
| Checkout de alto volumen | < 100 ms | Precisión ponderada, alertas de deriva |
En omnicanal, el canal más exigente termina marcando el presupuesto de toda la arquitectura. Si un flujo necesita responder en menos de 100 ms, el resto del diseño no puede hacerse el distraído.
Con la arquitectura ya definida, la pregunta cambia: ¿qué métrica manda en producción? La respuesta no es la latencia promedio. Lo que de verdad pesa es el p99 bajo tráfico real. Si ese umbral se pasa, el sistema entra en ruta de respaldo: aprueba sin evaluar riesgo o rechaza sin análisis.
Eso no es un detalle técnico menor. Es lo que aparece en producción cuando hay que resolver dentro de una ventana fija. Mastercard lo deja claro con su criterio operativo: ventana total acotada, inferencia en menos de 50 ms y modelos elegidos por velocidad, no solo por score.
En el día a día, esto empuja a los equipos a vigilar el sistema todo el tiempo y a ajustar modelos con frecuencia. En e-commerce, las prioridades pasan por:
Y hay un dato que no conviene pasar por alto: en entornos con alta deriva, el reentrenamiento semanal mejora el AUC frente al mensual.
Porque el p99 muestra la experiencia de las personas que se comen las peores demoras, no un promedio que muchas veces tapa picos de lentitud.
En detección de fraude, si la latencia pasa los 250 ms, puede pegar de lleno en la conversión y en la experiencia de compra. Por eso, mirar el p99 sirve para asegurar velocidad incluso cuando hay alta carga o más complejidad, sin degradar el pago ni romper SLA críticos.
Si el motor de fraude entra en timeout, la transacción puede aprobarse sin un filtro antifraude que funcione bien. O, en el otro extremo, puede rechazarse al cuete.
En redes de tarjetas pasa algo parecido. Si el emisor o el sistema de análisis tarda de más, puede romperse el SLA, aparecer declines accidentales o activarse reglas de respaldo menos precisas. Y hay otro problema que pega directo en negocio: más latencia en el checkout empeora la experiencia de usuario, sube el abandono del carrito y baja la conversión.
Hay que tratar la latencia como una restricción de producto que no se negocia. En e-commerce, pasar los 300 ms puede pegarle a la conversión, con una baja estimada de 1,5 % por cada 100 ms extra.
Para encontrar ese equilibrio, conviene poner el foco en una arquitectura eficiente: modelos rápidos, feature store cerca del scoring, fricción dinámica según el riesgo y paridad entre entrenamiento y producción. Además, el happy path tiene que estar lo más liviano posible, con menos I/O bloqueante y cachés agresivas.
