[Costo Real del Fraude] Tu stack antifraude tiene 5 proveedores y ninguno se habla con el otro (Parte 3/10)
[Costo Real del Fraude] Tu stack antifraude tiene 5 proveedores y ninguno se habla con el otro (Parte 3/10)
El Frankenstein antifraude
La película se repite en todas las operaciones que vi. Necesitás validar emails: contratás un proveedor. Necesitás device fingerprint: otro proveedor. Score de riesgo: otro. Grafos de relaciones: otro más. Velocidades y agregaciones: capaz que eso sí lo armaste in-house, en un microservicio que nadie quiere tocar.
El resultado: cinco herramientas, cinco contratos, cinco APIs, cinco dashboards. Y la data de cada una vive en su isla.
El analista que quiere responder “¿este usuario está conectado a una red de fraude Y tiene un email recién creado Y aceleró su frecuencia de compra en la última hora?” tiene que abrir tres pestañas, cruzar datos a mano, y rezar que los timestamps coincidan.
Eso no es un sistema antifraude. Es un Frankenstein con cinco cabezas que no se miran.
El problema no es la herramienta, es la integración
Cada técnica antifraude tiene una zona donde brilla y otra donde es ciega:
| Técnica | Dónde brilla | Dónde es ciega |
|---|---|---|
| Reglas | Lo explícito, repetible, regulatorio | Lo que no escribiste explícitamente |
| Listas (deny/allow) | Lo conocido | El primer ataque (nunca está en la lista la primera vez) |
| Velocidades | Abuso de cantidad | Calidad individual |
| Modelos ML supervisados | Patrones similares a labels históricos | Lo estructuralmente nuevo |
| Anomaly detection | Lo raro estadísticamente | Fraude que parece normal |
| Grafos | Fraud rings, redes de cuentas | Fraude solitario |
| Email/identity score | Signal externo | Tus clientes reales con emails raros |
Cada proveedor por separado suele ser bueno en lo suyo. El de email te dice si el correo tiene 2 días o 10 años. El de device te dice si el dispositivo ya se vio antes. El de grafos te muestra conexiones entre cuentas.
Pero el fraude real no vive en una sola dimensión. El ataque que te duele es el que combina un email viejo (pasa el filtro de email), un dispositivo nuevo (pasa si no tenés regla de device), pero que si cruzás con el grafo, ese dispositivo está conectado a 15 cuentas que hicieron chargebacks el mes pasado.
Esa conexión — email × device × grafo × velocidad — no existe cuando cada herramienta vive sola. Y es exactamente donde se esconde el fraude que más duele.
“Ya lo integramos internamente”
Sí, lo escuché muchas veces. El equipo de ingeniería armó un servicio que llama a los tres proveedores, junta los resultados y toma una decisión.
Suena bien hasta que lo mirás de cerca:
| Problema | Qué pasa |
|---|---|
| Latencia | Tres llamadas API, cada una con su timeout, retry, fallback. La transacción que tenía que resolverse en 200ms tarda 1.2 segundos. El usuario ve el spinner y se va. |
| Mantenimiento | Cada vez que un proveedor cambia su API (y lo hacen), tu integración se rompe. El equipo de fraude no puede arreglarla — depende de ingeniería, que tiene otras prioridades. |
| Reglas limitadas | Tu motor solo puede usar los campos que tu integración expone. Si el proveedor sacó un campo nuevo que necesitás, tenés que esperar un sprint para que ingeniería lo agregue. |
| Sin feedback loop | La decisión que tomaste no vuelve a ningún proveedor. No aprenden de tus datos. Tu operación es un consumidor pasivo de scores externos. |
El resultado neto: pagás por cinco herramientas, pagás por la integración, pagás por el mantenimiento, y seguís sin poder hacer la pregunta que realmente importa.
Lo que realmente necesita existir
Un stack antifraude que funcione no es una colección de proveedores pegados con cinta. Es una plataforma donde:
- Todo corre sobre el mismo evento. La transacción entra una vez. Email, device, velocidades, grafo, modelo: todos procesan el mismo evento, al mismo tiempo, con los mismos datos.
- Las reglas combinan todo. Podés escribir una regla que diga: “si el score del grafo es mayor a 0.7 Y la velocidad de transacciones en la última hora supera 3x el baseline del usuario Y el email tiene menos de 30 días → revisar”. Una sola regla. No tres sistemas.
- El analista ve todo junto. Un solo dashboard donde la transacción muestra su score, sus conexiones de grafo, su historial de velocidad, su validación de email. Sin abrir pestañas. Sin cruzar a mano.
- El feedback vuelve. Cuando el analista marca algo como fraude o falso positivo, esa etiqueta alimenta al modelo, ajusta las velocidades, actualiza el grafo. El sistema aprende de cada decisión.
La cuenta que nadie hace
Sumá lo que realmente estás pagando. No solo las licencias de cada proveedor por separado — sumale el equipo de ingeniería dedicado a mantener la integración, el tiempo del equipo de fraude perdido cruzando datos entre pestañas, y las horas de firefighting cada vez que un proveedor cambia su API y se rompe el pipeline.
Cada línea parece razonable por separado. Pero cuando sumás todo — licencias, ingeniería, mantenimiento, tiempo perdido — el número es mucho más alto de lo que cualquiera en la empresa cree. Y lo peor: estás pagando todo eso y aún así no podés hacer la consulta cruzada que necesitás.
La fragmentación no es solo un problema técnico. Es un problema de costos que nadie audita.
Cierre
El fraude moderno no se resuelve comprando herramientas y pegándolas. Se resuelve cuando toda la data vive en el mismo lugar, las reglas pueden combinar cualquier señal, y el sistema aprende de cada decisión.
Si tu operación antifraude se parece más al Frankenstein que a la plataforma, el problema no es que te falte un proveedor más — es que los que tenés no se hablan.
En Frauddi diseñamos el motor exactamente para esto: reglas que combinan grafo, velocidades, scores y validaciones en una sola plataforma, con IA que te ayuda a armar las combinaciones correctas según el tipo de fraude. Si querés ver cómo se ve eso funcionando, agendá una demo en frauddi.com.
Próximo en la serie: Escalar el equipo de analistas no escala (Parte 4/10) — la trampa de pensar en analistas como solución al volumen de fraude.
Comments