Detección de fraude con tus datos: dónde se quedan cortas las reglas

Casi todas las empresas que nos preguntan por detección de fraude ya tienen un sistema funcionando: una lista de reglas que alguien escribió hace años, a la que se han ido añadiendo excepciones cada vez que pasó algo malo. «Si el importe supera X y el cliente es nuevo, bloquea». «Si la IP viene de fuera de España, revisa». Funciona —hasta que el que intenta colarte algo aprende dónde están las líneas y se queda justo por debajo.

Esta guía va de lo que viene después: cuándo las reglas siguen siendo la respuesta correcta, qué aporta de verdad un modelo, por qué el enemigo número uno no es el fraude sino el falso positivo, y cómo medir que todo el montaje está pagándose solo. Sin promesas de «detectamos el 99 % del fraude»: ese número, cuando alguien lo dice sin contarte cuántas operaciones legítimas tumba por el camino, no significa nada.

¿Qué es la detección de fraude y qué tipos hay en una empresa?

Detección de fraude es decidir, sobre una operación concreta y normalmente en segundos, si parece legítima o no. La operación cambia mucho según el negocio, y eso lo cambia todo:

• Fraude de pago. Tarjetas robadas, contracargos, pedidos que nunca se pagan. Es el caso de libro: millones de transacciones, decisión en milisegundos.
• Fraude interno. Facturas duplicadas, proveedores fantasma, gastos inflados, descuentos fuera de política. Mucho menos volumen, mucho más daño por caso.
• Fraude en siniestros. Partes exagerados o directamente inventados. Es el terreno clásico en seguros.
• Abuso de promociones y cuentas. Cuentas múltiples para repetir un descuento de bienvenida, devoluciones sistemáticas, reventa.
• Suplantación en el alta. Documentos manipulados, identidades reutilizadas, altas automatizadas en masa.

Cada uno exige datos distintos y tolera errores distintos. Bloquear por error un pago de 40 € es molesto; bloquear por error el alta de un cliente corporativo de 200.000 € al año es un problema de dirección. Antes de hablar de tecnología hay que escribir en una línea qué operación se evalúa, con qué datos disponibles en ese instante y qué pasa cuando el sistema se equivoca en cada dirección.

El fraude no es un problema de detección. Es un problema de decisión bajo incertidumbre con dos costes asimétricos: el del fraude que pasa y el del cliente legítimo al que frenas.

¿Reglas o modelos? Qué resuelve de verdad cada uno

La pregunta está mal planteada, porque en producción casi siempre conviven. Pero sirven para cosas distintas.

| | Reglas | Modelo | |---|---|---| | Cómo decide | Condiciones escritas por una persona | Patrón aprendido del histórico | | Explicabilidad | Total: «saltó la regla 14» | Requiere trabajo extra para justificar cada decisión | | Casos que cubre | Los que alguien ya vio | Combinaciones que nadie formuló | | Reacción al cambio | Hay que reescribirlas | Se adapta reentrenando, si hay etiquetas nuevas | | Quién lo mantiene | Negocio y riesgos | Equipo de datos + negocio | | Coste de arranque | Bajo | Medio-alto: datos, etiquetas, despliegue | | Dónde falla | El defraudador aprende el umbral | Hereda el sesgo del histórico y envejece |

Lo que un modelo aporta y una regla no: combinar muchas señales débiles. Ninguna de estas es sospechosa por sí sola —importe algo alto, dirección de envío nueva, compra a las 3 de la mañana, tres intentos de tarjeta, cuenta creada hace 11 minutos— pero juntas describen un perfil que una regla con cinco condiciones encadenadas nunca va a capturar bien.

Lo que una regla aporta y un modelo no: obligación. Si tu política dice que una transferencia a un país concreto no sale sin firma del director financiero, eso es una regla, punto. No se vota, no se puntúa.

Arquitectura que vemos funcionar en empresa mediana: reglas duras arriba (cumplimiento, límites, listas), modelo en el medio para puntuar el resto, y umbrales de negocio abajo que convierten la puntuación en acción. Empezar al revés —modelo primero, reglas después— suele acabar con un modelo que nadie se atreve a conectar.

¿Qué datos hace falta para detectar fraude?

Aquí es donde mueren la mitad de los proyectos. Necesitas tres cosas, y la tercera es la que casi nunca está.

1. El histórico de operaciones. Con las variables tal y como existían en el momento de la operación, no como están hoy. Si tu tabla de clientes guarda el estado actual («bloqueado»), y entrenas con eso, el modelo aprenderá que los clientes bloqueados defraudan. Enhorabuena: has construido una máquina del tiempo inútil. Se llama fuga de información y es el error más común y más caro.

2. Las etiquetas. Qué operaciones resultaron ser fraude de verdad. Contracargos confirmados, expedientes cerrados, siniestros rechazados por el perito. Sin esto no hay aprendizaje supervisado posible.

3. El registro de lo que no viste. Si llevas años bloqueando lo que saltaba en las reglas, nunca sabrás si esas operaciones eran fraude. Tu histórico solo contiene el fraude que dejaste pasar y luego descubriste. Por eso conviene dejar pasar deliberadamente una muestra pequeña y controlada de operaciones sospechosas de bajo importe: es el único modo de saber qué hay al otro lado del umbral.

Dos datos más, igual de importantes: la fecha real de descubrimiento (un contracargo llega 60 días después; si no lo tienes en cuenta, mides sobre casos que aún no han madurado) y la velocidad: casi todas las señales buenas son de ritmo —intentos por minuto, dispositivos por cuenta, cuentas por dispositivo, variación frente al comportamiento propio de ese cliente—. Si tu calidad de datos no permite reconstruir esas secuencias, el proyecto empieza por ahí, no por el modelo.

En volumen: para un modelo supervisado razonable queremos del orden de varios cientos de casos de fraude confirmados, no de operaciones totales. Con 20 casos no se entrena nada; se escriben reglas y se montan alertas por anomalía.

¿Por qué el falso positivo es el problema caro?

El fraude suele ser un 0,1 %–1 % de las operaciones. Con esa proporción, un sistema que dijera «todo legítimo» acertaría el 99 %. Por eso la precisión global es una métrica inútil aquí, y por eso cualquiera que te la presente como argumento no ha trabajado en esto.

Las que importan son cuatro:

• Detección (recall): del fraude real, qué porcentaje cazas.
• Precisión: de lo que marcas, qué porcentaje era fraude de verdad.
• Tasa de revisión: qué porcentaje del total acaba en la cola de una persona. Es tu factura de nóminas.
• Fricción al cliente legítimo: cuántos clientes buenos bloqueas, y qué valor tienen.

Las dos primeras se intercambian moviendo un único número: el umbral. Bajarlo caza más fraude y llena la cola de revisión; subirlo limpia la cola y deja pasar casos. No hay configuración «buena», hay una configuración que corresponde a una decisión de negocio.

La forma honesta de fijarla es en euros. Pon encima de la mesa: pérdida media por caso de fraude que pasa, coste de revisar una alerta (minutos × coste/hora), y valor perdido cuando frenas a un cliente legítimo —que no es el importe del pedido, es el pedido más la probabilidad de que ese cliente no vuelva—. Con esos tres números, el umbral sale solo y además queda documentado por qué. Es el mismo ejercicio de medir el ROI que pedimos en cualquier proyecto: si no sabes lo que cuesta equivocarte, no puedes calibrar nada.

Un matiz que se olvida: no todo es bloquear o dejar pasar. Entre medias hay acciones baratas —pedir verificación en dos pasos, retener el envío 24 horas, exigir pago por adelantado, llamar— que recortan el fraude sin la brutalidad de un bloqueo. Diseñar esa escala intermedia suele dar más resultado que afinar el modelo dos puntos.

¿Cómo encaja la revisión humana?

El modelo no decide: prioriza. Quien decide, en los casos que importan, sigue siendo una persona. Para que eso funcione hacen falta tres piezas que casi nunca se presupuestan:

• Una cola de trabajo ordenada por riesgo y por importe, no por orden de llegada. La persona que revisa tiene un tiempo finito; que lo gaste donde más euros hay en juego.
• Explicación por caso. «Riesgo 0,87» no sirve. «Riesgo alto: tercera tarjeta distinta en 10 minutos, envío a dirección nueva, cuenta creada hoy» sí. Esto se puede generar con las técnicas de atribución habituales y es exigible a cualquier proveedor.
• Realimentación. Lo que el revisor decide tiene que volver al sistema como etiqueta. Si las resoluciones se quedan en un Excel aparte, el modelo no aprende nunca y repetirás los mismos falsos positivos cada semana.

Añade el lado legal: el RGPD da derecho a no quedar sujeto a decisiones exclusivamente automatizadas con efecto significativo, y bloquear a un cliente lo tiene. En la práctica: deja trazado quién o qué decidió, conserva el motivo, y ofrece una vía humana de revisión. Nada de esto es opcional, y es más fácil si se diseña al principio que si se parchea después.

¿Cómo montar el primer caso en 90 días?

Una secuencia que funciona, con el entregable de cada tramo:

| Semanas | Qué se hace | Qué queda | |---|---|---| | 1–2 | Elegir un tipo de fraude y cuantificar la pérdida actual | Línea base en euros | | 3–5 | Reconstruir el histórico sin fuga de información y revisar etiquetas | Conjunto de entrenamiento auditado | | 6–8 | Modelo base + comparación contra las reglas actuales | ¿Aporta algo? Sí o no, con números | | 9–10 | Umbral fijado en euros y escala de acciones intermedias | Política de decisión escrita | | 11–12 | Piloto en sombra: puntúa todo, no bloquea nada | Comparativa real contra la operativa viva | | 13 | Activación progresiva + panel de seguimiento | Sistema en producción con dueño |

La fase de sombra es innegociable. Durante dos o tres semanas el sistema puntúa todas las operaciones y nadie actúa sobre su decisión; al final comparas qué habría bloqueado frente a lo que pasó de verdad. Es la única forma de conocer el impacto sin arriesgar ni un cliente, y ha evitado más de un despliegue que habría tumbado medio día de pedidos legítimos.

Después toca mantenerlo. Un modelo de fraude envejece más rápido que cualquier otro porque hay alguien al otro lado intentando activamente romperlo. Vigila la deriva, reentrena con calendario y no por sorpresa, y guarda versiones: las mismas prácticas de MLOps que aplicarías a cualquier modelo en producción, aquí con más motivo.

Errores que vemos repetirse

• Entrenar con datos del futuro. El clásico. Si una variable mejora el modelo de forma sospechosa, probablemente contiene información posterior a la operación.
• Medir con la precisión global. Con un 0,5 % de fraude, el 99,5 % es el suelo, no un logro.
• No contar el coste de revisión. Un sistema que caza un 30 % más de fraude pero triplica la cola puede ser peor negocio que el anterior.
• Dejar las reglas viejas sin tocar. Si enchufas el modelo encima de 300 reglas acumuladas, nadie sabrá qué bloqueó qué. Limpia primero; la mitad no las entiende ya nadie.
• Castigar al cliente bueno de siempre. El sistema tiene que saber distinguir entre una operación rara y una operación rara para ese cliente. Un pedido de 8.000 € es normal si lleva seis años haciéndolos.

Preguntas frecuentes

¿Cuántos datos necesito para empezar?

Importa más el número de casos de fraude confirmados que el volumen total. Por debajo de unos cientos de casos etiquetados, un modelo supervisado no se sostiene y conviene más trabajar con reglas bien calibradas y detección de anomalías. En paralelo, empieza a registrar etiquetas limpias desde hoy: dentro de un año serán tu activo.

¿Puedo detectar fraude sin etiquetas, solo con anomalías?

Sí, y es la vía habitual cuando no hay histórico. La detección de anomalías marca lo que se sale del comportamiento normal, pero no sabe si eso es fraude o simplemente un cliente raro. Genera más ruido y exige más revisión humana; sirve como arranque y para destapar tipos de fraude nuevos, no como sistema definitivo.

¿Hay que avisar al cliente de que un sistema automático le revisa?

Tienes que informar del tratamiento en la política de privacidad y, si la decisión es automatizada y le afecta de forma significativa, ofrecer intervención humana. Lo que no conviene es detallar públicamente las señales concretas que usas: equivale a publicar el manual de cómo esquivarlas.

¿Es mejor comprar una solución de fraude o construirla?

Si tu fraude es estándar —pagos con tarjeta en ecommerce, por ejemplo— las soluciones de mercado llegan con modelos entrenados sobre millones de operaciones que tú no tienes, y es difícil ganarles. Si tu fraude es específico de tu negocio (siniestros, proveedores, promociones propias), lo de fuera no encaja y toca construir sobre tus datos.

---

Si estás en el punto de «tenemos reglas y sospechamos que se nos escapa algo, pero no sabemos cuánto», lo primero no es un modelo: es poner un número a la pérdida actual y comprobar si el histórico permite aprender de ella. Eso es exactamente lo que miramos en la auditoría, y si prefieres contarlo en voz alta antes de mover un dato, hablemos.