Si la señal llega tarde, el fraude ya pasó. Yo lo resumiría así: en pagos online, no alcanza con tener un buen modelo; necesito datos listos en milisegundos para decidir si apruebo, rechazo o pido una verificación extra.
En este tema, el punto central es simple:
Dicho en corto: yo empezaría por definir pocos features que muevan la decisión, medir latencia punta a punta y vigilar drift desde el día uno.
Eso es, en pocas líneas, lo que desarrolla el artículo.
Con la idea de feature ya clara, el paso que sigue es separar qué señales están disponibles en el momento de la autorización y cuáles no.
En el instante exacto en que un cliente hace clic en "pagar", el sistema recibe señales del flujo de pago - monto, método de pago, marca temporal, BIN, país del emisor y resultado de 3-D Secure (3DS) - junto con señales de la tienda y del CRM, como el historial del cliente, el dispositivo, la IP y los datos de sesión.
Una vez detectadas esas señales, el problema cambia. Ya no se trata solo de qué datos existen, sino de cuáles pueden calcularse sin pasarse del presupuesto de latencia.
Los datos crudos no entran al modelo tal como llegan: primero se convierten en features. En fraude, hay tres grupos que suelen dar buen resultado:
card_txn_count_1h (cantidad de transacciones con esa tarjeta en la última hora) o ip_txn_count_5m (intentos desde esa IP en los últimos 5 minutos).device_country_mismatch o session_field_autofill_ratio.En fraude, esta diferencia importa por un motivo simple: qué conviene dejar resuelto de antemano y qué hay que calcular en streaming, sobre la marcha.
| Feature precalculado (batch) | Feature en tiempo real | |
|---|---|---|
| Latencia | < 10 ms (lectura desde caché) | 10–30 ms (cálculo en vivo) |
| Frescura | Horas o días | Segundos o minutos |
| Fuentes de datos | Data warehouse, CRM, historial | Flujos de eventos, sesión, Redis |
| Complejidad operativa | Moderada (pipelines ETL) | Alta (procesamiento en streaming) |
| Mejor uso en fraude | LTV del cliente, historial de fraude, antigüedad de la cuenta | Velocidad de intentos, desajuste de dispositivo, comportamiento de sesión |
Acá hay un punto delicado: la paridad entre entrenamiento y producción. Si el feature card_txn_count_1h se calcula de una forma durante el entrenamiento y de otra en producción, el modelo puede verse bien en pruebas y después fallar cuando entra en juego de verdad. Por eso, mantener una sola definición de cada feature entre ambos entornos no es un detalle técnico: es la base mínima para poder confiar en el modelo.
En ecommerce, el tiempo para decidir suele ser menor a 250 ms; sumar 100 ms extra puede pegarle a la conversión. El paso siguiente es pensar la arquitectura que toma esos eventos, calcula los features y los entrega antes de autorizar.
Con los datos en tiempo real ya definidos, el paso que sigue es claro: priorizar las señales que cambian rápido y empujan la decisión.
Las métricas de velocidad sirven para detectar fraude en segundos. Cuando alguien prueba tarjetas robadas, suele generar una ráfaga de intentos en muy poco tiempo. Por eso, usar ventanas de 1 hora, 24 horas y 7 días ayuda a cubrir tanto ataques bruscos como patrones más lentos de fase de prueba.
Pero no todo pasa por los conteos. En checkout también aparecen señales que dicen mucho: cambios repetidos de tarjeta dentro de una misma sesión, ediciones de la dirección de envío después de cargar el medio de pago o un ticket que salta por encima del comportamiento usual del cliente. Y si eso coincide con montos altos y un dispositivo poco habitual para esa cuenta, la alerta pesa más.
El fingerprint del dispositivo gana peso cuando cambia dentro de una cuenta con historial, sobre todo si además aparece una VPN o un proxy y la IP está fuera del país de facturación.
A nivel de pago y cliente, hay dos señales que conviene mirar de cerca:
Dicho simple: una compra no se evalúa sola. Importa el contexto. No es lo mismo una operación alta en una cuenta vieja con patrón estable que esa misma operación en una cuenta con cambios raros y poco historial.
Cuando ventas y soporte comparten contexto con checkout y pagos, empiezan a aparecer señales que un modelo más cerrado no suele ver. Por ejemplo, una dirección de envío distinta entre la que el cliente pasó por WhatsApp y la que figura en el checkout. O un cambio urgente de datos de contacto justo antes de un pago importante. Ese tipo de desajustes puede marcar ingeniería social o un cambio de riesgo que conviene revisar.
Las plataformas que sincronizan en tiempo real los datos de conversación con el perfil del cliente arman un registro muy útil para este tipo de features.
| Familia de features | Ejemplos concretos | Datos necesarios | Valor contra fraude |
|---|---|---|---|
| Velocidad y comportamiento | Intentos fallidos en < 5 min, monto total aprobado en las últimas 24 h, pico de ticket | Timestamps, estado de transacción, montos | Detecta carding y ataques automatizados |
| Dispositivo y red | Cambio de fingerprint, uso de VPN/proxy, desajuste IP-país de facturación | IP, device fingerprint, BIN | Identifica tomas de cuenta |
| Pago y cliente | Historial de contracargos, variación en valor promedio de compra, antigüedad de la cuenta | Datos de autorización, CRM, historial de órdenes | Refuerza la señal en transacciones de alto valor |
| Señales conversacionales | Dirección en chat ≠ dirección en checkout, cambio urgente de datos de contacto antes del pago | Logs de soporte, CRM, API de órdenes | Detecta ingeniería social y cambios urgentes de datos |
El próximo paso es llevar estas señales al flujo de eventos y cumplir la latencia de autorización.
Arquitectura de Detección de Fraude en Tiempo Real: Del Evento a la Decisión
Con esas señales ya definidas, el desafío cambia: hay que llevarlas al decisor sin romper la latencia.
Cuando la persona hace clic en pagar, arranca el flujo. Y ahí cada milisegundo pesa. La meta no es sumar herramientas porque sí, sino convertir contexto en una decisión antes de autorizar el pago.
El esquema más común es primero reglas, después ML: primero actúan reglas determinísticas y después la inferencia para los casos más complejos. El recorrido suele verse así:
La ingesta está separada del puntaje. Kafka desacopla ambas partes: si el servicio de ML tarda más de lo esperado, el orquestador puede apoyarse en el motor de reglas para que el pago no se frene. Esa separación entre ingestión, enriquecimiento, reglas y decisión sostiene una experiencia de checkout más fluida.
"Latency is not a performance metric in fraud detection - it is a business constraint." - Jay Palaniappan, Databricks
Todo el flujo tiene que entrar dentro del presupuesto de latencia del checkout. Pasarse tiene un costo directo: la tasa de conversión baja cerca de un 1,5 % por cada 100 ms extra más allá de los 300 ms.
Para entrar en ese presupuesto, cada componente cumple un papel concreto y tiene un techo de tiempo.
| Componente | Función principal | Tecnologías de ejemplo | Rol en detección de fraude |
|---|---|---|---|
| Flujo de eventos | Desacopla ingesta de procesamiento | Kafka, Redpanda | Garantiza durabilidad y permite replay de eventos para validar modelos |
| Repositorio de features | Sirve features batch y en tiempo real | Redis, Tecton, Feast, DynamoDB | Entrega contexto del usuario, como gasto en ventanas deslizantes recientes, en <10 ms |
| Motor de reglas | Lógica determinística (if-then) | OPA, Drools | Bloquea patrones conocidos sin overhead de ML, en <5 ms |
| API de puntaje de ML | Inferencia de riesgo en tiempo real | KServe, SageMaker, BentoML | Genera un score de probabilidad de fraude (0-1) |
| Orquestador | Secuencia llamadas y gestiona fallbacks | Temporal, AWS Step Functions | Asegura una decisión aunque falle algún componente |
| Gestión de casos | Revisión humana de casos ambiguos | Hummingbird, Unit21 | Etiqueta datos para reentrenamiento del modelo |
Hay un punto operativo que muchas veces se pasa por alto: el repositorio de features tiene que estar co-ubicado con el servicio de puntaje. Si entre ambos hay latencia de red WAN, buena parte del presupuesto se va antes de que el modelo siquiera empiece a trabajar.
También hay otro detalle nada menor. Los contadores de velocidad en Redis necesitan TTLs configurados de forma explícita. Si no, el estado crece sin control y las features pierden vigencia.
Con esta arquitectura en pie, el siguiente frente pasa por controlar calidad, drift y explicabilidad.
En ecommerce, la señal de fraude mejora cuando productos, órdenes, clientes, inventario, descuentos y políticas están sincronizados en tiempo real.
Burbuxa sincroniza en tiempo real productos, órdenes, clientes, inventario, descuentos y políticas. Eso alimenta features cruzados entre checkout y WhatsApp/Instagram antes de la autorización. En la práctica, esa sincronización nutre al repositorio de features con señales que llegan a tiempo para decidir. Sin ese contexto, el modelo termina resolviendo con menos señal y más ruido.
Con la arquitectura ya definida, el foco pasa a gobernar la calidad de las señales antes de cada autorización de pago.
Un feature veloz no alcanza si deja de predecir bien o pierde estabilidad en plena autorización. Por eso, conviene medir la precisión ponderada por monto y el percentil 99 de latencia. El promedio, por sí solo, puede dar una falsa sensación de calma: esconde picos que después rompen el checkout y aumentan el abandono.
Si el PSI supera 0,2, ya hay drift suficiente como para reentrenar. Lo mejor es automatizar ese ciclo y actualizar el modelo de forma semanal o antes, cuando entren nuevas etiquetas.
Cada decisión de alto riesgo tiene que poder seguirse de punta a punta: un mensaje breve para el cliente, un motivo operativo para el analista y un detalle técnico para el equipo de datos.
Así, el modelo deja de ser una caja negra y pasa a trabajar con control y auditoría.
En Argentina, la capa de ingesta también tiene que respetar los formatos locales. Fechas en dd/mm/aaaa y montos con coma decimal, como AR$ 12.500,00, ayudan a evitar errores que terminan distorsionando los features. Si no hay gobernanza, el modelo puede aprobar de más, rechazar de más o llegar tarde. Cada feature necesita una definición precisa, un responsable claro y versionado compartido entre entrenamiento y producción, para evitar desalineación entre ambos entornos.
La ingeniería de features en tiempo real no es un simple detalle de modelado: es una capacidad central para el control de riesgo. Si la calidad, el drift y la trazabilidad están bajo control, el modelo puede sostenerse en producción sin frenar ventas.
Para empezar, conviene ir por una base simple:
Después, ya podés escalar explicabilidad y reentrenamiento.
Conviene poner primero las features que detectan patrones raros en tiempo real: velocidad y recurrencia de transacciones, cantidad de comercios en poco tiempo y señales de actividad sospechosa. Son las que más ayudan a marcar anomalías rápido y a afinar la precisión.
También pesan mucho las features temporales, de geolocalización, de dispositivo y de vínculos entre cuentas, IPs y dispositivos. ¿Por qué? Porque permiten ver desvíos frente al comportamiento habitual del usuario y, además, encontrar posibles redes de fraude.
En checkout, una latencia aceptable para detectar fraude en tiempo real suele estar entre 20 y 30 milisegundos.
Parece un detalle chico, pero no lo es. En sistemas en tiempo real, cada milisegundo cuenta: si la demora sube de ese rango, la experiencia del usuario puede empeorar y la tasa de conversión también puede caer.
Usá datos consistentes en las dos etapas. En fraude en tiempo real, conviene dividir por tiempo y no al azar: entrená con datos históricos y validá con períodos más recientes. Así evitás fuga de información futura.
Además, aplicá lags o ventanas de tiempo en las features basadas en etiquetas históricas. No uses datos futuros ni información que recién se conoce después de la transacción. Y monitoreá las distribuciones en producción para detectar cambios.