Definiciones, métricas y hallazgos de estudios recientes

Latencia de decisión online vs. tiempo hasta la detección

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.

Qué reportan los estudios recientes sobre presupuestos de latencia

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.

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.

Cómo se evalúa la latencia junto con la calidad del modelo

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.

Compensaciones entre latencia, precisión de detección y experiencia del cliente

Por qué los modelos más lentos pueden mejorar los scores pero perjudican la prevención en tiempo real

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.

Cómo la latencia aumenta el fraude no detectado y los falsos rechazos

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.

Impacto en el cliente en flujos móviles y checkouts de alto volumen

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.

Detección de fraude de tarjetas de crédito en tiempo real - Couchbase | AI4RealSpain

Arquitecturas que reducen la latencia en el monitoreo de fraudes en tiempo real

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.

Pipelines de streaming, microservicios y decisión en memoria

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:

• Reglas para los casos obvios
• ML liviano para el scoring en el camino crítico
• Modelos pesados fuera del camino crítico

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.

Observabilidad: latencia p99, tasa de timeout y deriva del score

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.

Qué significa esto para plataformas omnicanal como Burbuxa

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.

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.

Lo que la investigación reciente le dice a los equipos de fraude

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:

• medir p99 y timeouts como KPIs
• usar una arquitectura por capas
• reentrenar semanalmente cuando hay deriva

Y hay un dato que no conviene pasar por alto: en entornos con alta deriva, el reentrenamiento semanal mejora el AUC frente al mensual.

FAQs

¿Por qué importa más el p99 que la latencia promedio?

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.

¿Qué pasa si el motor de fraude entra en timeout?

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.

¿Cómo equilibrar velocidad, precisión y 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.