[Costo Real del Fraude] El costo invisible de responder lento (Parte 1/10)
[Costo Real del Fraude] El costo invisible de responder lento (Parte 1/10)
Una hora que vale plata
Lo vi una y otra vez. Equipos de fraude descargándose los datos a su computadora personal, abriendo Excels gigantes, inventándose algoritmos raros sin validación real, filtrando miles de transacciones a mano. Todo al día siguiente del fraude.
El resultado siempre era el mismo: iban un día atrás del atacante. Las reglas que ponían “en monitoreo para ver cómo se comportan” se quedaban ahí, olvidadas, sin pasar nunca a bloqueo activo. Y el proceso de filtrado era tan lento por la cantidad de datos que cuando confirmaban un patrón, ya era foto vieja.
Durante esas 24 o 48 horas, el patrón siguió pasando. ¿Cuánto perdieron? La respuesta más honesta: no lo sabían. Y eso —no saberlo— ya es parte del problema.
O al revés: para no perder, tiraban reglas a ciegas, durísimas, sin medir impacto ni monitorear. Se enteraban del daño cuando un cliente se quejaba, y para entonces la tasa de aceptación ya estaba en el piso. Lento o estricto, el resultado era el mismo: descontrol con cara de proceso.
El número que casi nadie mide
En operaciones antifraude maduras hay una métrica que rara vez aparece en dashboards: la demora entre detección y acción. O sea, cuánto tiempo pasa entre que tu equipo sabe que un patrón nuevo está rompiendo, y que la regla, lista o modelo que lo bloquea está corriendo en producción.
En las operaciones que vi, esa demora se medía en horas o directamente en días. Y no era por incompetencia: a veces era un equipo enorme donde el caso se diluía entre tickets, capas de aprobación y gente de vacaciones. Otras veces eran 3 personas, alguno junior, y entre el volumen y las distracciones algo siempre se quedaba en el camino. La diferencia entre una demora de horas y una de días no es solo tecnológica, es de costo: cada hora es plata, chargebacks y, peor, clientes legítimos que se llevaron la peor parte porque la regla rota seguía afectándolos.
Por qué la demora existe
La demora típica viene de seis lugares, y los vi todos en operaciones reales:
- Análisis manual lento. El analista necesita correr consultas en distintos lugares para confirmar un patrón. Entre Looker, una base operativa y un dashboard interno se le va medio día.
- Volumen de datos inmanejable. Aunque tenga la consulta, la herramienta es pesada y los filtros tardan minutos. Se pasa de “voy a confirmar el patrón” a “voy a almorzar mientras corre la consulta” muy rápido.
- Aprobaciones de cambios. En muchas empresas, agregar o modificar una regla pasa por el mismo proceso que un cambio de código: PR, revisión, staging. Excelente disciplina para producto, fatal para antifraude.
- Despliegue acoplado. Si tus reglas viven dentro del codebase principal, cambiar una regla = release. Y los releases tienen ventana.
- Falta de responsabilidad. Reglas que alguien dejó en modo monitoreo “para ver cómo se comportan” y nadie posee. Pasan semanas, la regla sigue ahí, sin pasar a bloqueo activo, sin que nadie revise el dashboard.
- Equipo chico, sin manual. Tres personas, alguno junior, sin documentación de qué se priorizó cuándo. Si el senior está de vacaciones, el caso se queda donde se quedó.
Ninguno de estos seis se resuelve instalando una herramienta nueva. Son culturales, arquitecturales y de proceso, no técnicos.
De días a minutos: qué tiene que cambiar
Para cerrar la demora no necesitás magia, necesitás romper esos tres acoples:
- Reglas vivas, fuera del codebase. Las reglas y listas tienen que ser datos, no código. Un equipo de fraude debería poder activar, ajustar o revertir una regla sin tocar Git.
- Aprobaciones específicas para antifraude. Sí: revisión humana para regla nueva, especialmente si impacta autorizaciones. Pero el ciclo tiene que medirse en minutos, no en sprints. Eso se logra con límites (impacto máximo, modo sombra, reversa fácil), no con burocracia.
- Observabilidad en caliente. Una vez que la regla está en producción, tenés que poder ver en tiempo real qué transacciones está afectando, cuántos legítimos está tocando, y cuánto bajó el patrón fraudulento. Si no podés ver eso en 5 minutos, no podés iterar.
El otro lado: responder rápido sin romper UX
Lo más común que vi no era el equipo lento — era el equipo que para no perder tiraba reglas durísimas a ciegas, sin medir impacto, sin monitoreo. Se enteraban del daño cuando soporte recibía quejas, y para entonces la tasa de aceptación ya había caído. Bajar la demora a minutos sin límites es exactamente la misma trampa, pero más rápida: bloqueás mil clientes legítimos antes del almuerzo.
Las prácticas que funcionan:
- Modo sombra por defecto. Cualquier regla nueva corre primero sin bloquear, solo etiquetando. Dejás que junte datos por unas horas antes de pasarla a bloqueo activo.
- Límites de impacto duros. Si una regla nueva está afectando más del X% del tráfico, freno automático. No tenés que confiar en el ojo humano para detectar un disparate.
- Reversa en un clic. No “una PR de revert”. Un clic.
Si tu sistema antifraude no soporta esto nativamente, vas a tener que elegir entre lento-seguro y rápido-peligroso. Falsa dicotomía: hay cómo tener rápido-seguro, pero requiere arquitectura específica.
Las métricas que sí importan
Si estás auditando un equipo antifraude (propio o externo), tres números:
- Time-to-detect (TTD). Cuánto tarda el equipo en notar un patrón nuevo después de que empieza.
- Time-to-mitigate (TTM). Cuánto tarda entre detección y la regla corriendo en producción. Esta es la demora de la que estoy hablando.
- Time-to-recovery (TTR). Cuánto tarda en estabilizarse la métrica de fraude después de mitigar.
TTM es donde se gana o se pierde la mayor parte de la plata. Y curiosamente es donde menos foco hay, porque “es un problema de proceso”, lo que significa que nadie lo posee.
Cierre
El fraude no espera tu sprint. Cada hora que tu motor antifraude está detrás de los atacantes es plata que se va, clientes que se queman y métricas que mañana vas a tener que explicar.
Bajar la demora de días a minutos no es un detalle de rendimiento. Es la diferencia entre tener antifraude y tener un reporte mensual de pérdidas.
En Frauddi pensamos el motor exactamente alrededor de esto: cerrar el ciclo detección-acción en minutos, con límites para no romper UX. Si querés ver cómo se ve eso en operación real, agendá una demo en frauddi.com.
Próximo en la serie: Si el atacante usa IA, tu motor estático ya perdió (Parte 2/10) — adversarial drift y por qué los modelos congelados pierden la carrera contra fraude moderno.
Comments