Cuando la gente habla de reducir los falsos positivos, normalmente pasa directamente a las tácticas: ajustar reglas, modificar umbrales, añadir excepciones, relajar el modelo, derivar los casos límite a revisión manual, y así sucesivamente. Todo eso forma parte del trabajo, pero nada de ello debería ser el punto de partida.
Si has llegado hasta aquí en la serie (ponte al día con la parte 1 y la parte 2 aquí), ya has hecho las dos tareas que la mayoría de los equipos se saltan:
- Has creado una medición razonablemente precisa de tus falsos positivos, aunque tu sistema los oculte por defecto.
- Has clasificado esos falsos positivos en categorías: por actor, por soluciones, por flujo, por calidad de los datos y por lo que está o no bajo tu control.
Esa es la base. Ahora estás listo para abordar el plato fuerte: arreglar las partes del sistema que se están comportando mal.
Pero aquí es donde debemos abordar el trabajo con disciplina. De lo contrario, terminarás haciendo cambios que no importan, pasando por alto cambios que sí habrían importado o, lo que es peor, abriendo la puerta a fraudes adicionales sin darte cuenta.
Este blog se centra en las soluciones que funcionan dentro de tu sistema de fraude.
Revisa a tus principales infractores mediante una revisión manual
Una de las mejores formas de orientarte antes de hacer cualquier cambio es volver a la revisión manual. Elige la regla, el umbral del modelo o el agente de IA que se active con mayor frecuencia e inspecciona manualmente una muestra de los eventos que bloqueó (entre 50 y 100 suele ser suficiente en la mayoría de los casos).
Lo que intentas responder suelen ser preguntas muy básicas:
- ¿Es esta regla realmente tan inexacta como pensamos?
- ¿Queremos que esta regla siga existiendo?
- Si existe, ¿debería seguir tomando decisiones automatizadas o debería pasar a revisión manual?
- Si debe seguir siendo automatizado, ¿qué haría falta para reducir sus falsos positivos sin aumentar de forma significativa nuestras pérdidas por fraude?
Cada una de estas preguntas depende de la empresa. No existe un umbral universal de «suficientemente bueno».
A veces tu equipo de FraudOps puede hacerse cargo de las revisiones manuales adicionales. Otras veces no tienes revisiones manuales en absoluto como parte de tu proceso.
Y a veces una regla debe seguir siendo automática incluso si genera mucho ruido, porque simplemente no puedes permitirte revisar manualmente ese volumen.
Pero necesitas tener claridad antes de cambiar nada. El peor caso es pensar que una regla está bien porque “parece lógica”, solo para descubrir durante una revisión manual que está bloqueando tráfico abrumadoramente legítimo.
No puedes resolver estas situaciones solo con razonamientos. Tienes que observarlas directamente.
Lo más importante es que esto no se trata solo de comprobar que estás solucionando un problema real, sino de mostrarte cómo hacerlo.
Tres caminos de decisión para cada regla o modelo de fraude que se comporte mal
Una vez que hayas revisado las pruebas, casi todas las soluciones que se comportan de forma incorrecta encajan en una de tres categorías:
1. La regla de fraude no debería existir en absoluto.
Esto sucede con más frecuencia de lo que los equipos admiten.
Tienes lógica en tu sistema que:
- Detecta una pequeña parte de la población
- No bloquea mucho fraude
- Genera una cantidad desproporcionada de falsos positivos
- Existe principalmente porque alguien lo añadió durante una crisis y nadie lo volvió a revisar
Eliminar estas reglas se siente incómodo las primeras veces que lo haces. Pero si el fraude que detectan es insignificante y los falsos positivos son significativos, desactivarlas es una de las formas más limpias y seguras de mejorar tu sistema.
Este es tu fruto fácil de conseguir.
2. La regla de fraude debe existir, pero ya no debe tomar decisiones automatizadas.
Esto es común con una lógica de precisión media que aún detecta fraudes significativos, pero no con la fiabilidad suficiente como para bloquearlos sin revisión humana.
Si cuentas con capacidad para revisiones manuales y esta lógica en particular tiende a generar eventos que tus analistas se sienten cómodos evaluando, entonces enviarlos a gestión de casos en lugar de rechazarlos automáticamente puede ser el compromiso perfecto.
Mantienes la cobertura contra el fraude, reduces los falsos positivos y pones a una persona en el circuito que puede observar los cambios de rendimiento en tiempo real.
El costo, por supuesto, es operativo. Esto solo funciona cuando tienes una visión clara de la precisión de tus analistas y de la capacidad de tu cola.
3. La regla de fraude debe existir y seguir siendo automática, pero su lógica necesita mejorarse.
Este es el escenario más interesante. También es el más común.
La lógica detecta fraudes reales. Es necesaria. Es eficaz. Pero también está afectando a un número significativo de usuarios legítimos.
Así que necesitas perfeccionarlo. La cuestión es cómo.
Ruta 1: Eliminar la regla | Ruta 2: Redirigir a revisión manual | Ruta 3: Refinar la lógica | |
Cuándo usarlo | Baja detección de fraude, muchas falsas alarmas; lógica heredada o de época de crisis que nadie volvió a revisar | Regla de precisión media que detecta fraudes significativos pero no es lo suficientemente confiable como para rechazar automáticamente | Alta detección de fraude y regla necesaria, pero también está afectando a un número significativo de usuarios legítimos |
Requisito previo | Se confirmó un impacto insignificante del fraude mediante revisión manual | Capacidad disponible de analistas y ancho de banda claro en la cola | Separación clara entre patrones de fraude y de falsos positivos (validada mediante el método de «imagen en espejo») |
Acción | Desactivar la regla por completo | Redirigir los eventos marcados al sistema de gestión de casos en lugar de rechazarlos automáticamente | Crear exclusiones derivadas de la población de falsos positivos, validadas frente a la población de fraude |
Riesgo | Mínimo si el volumen de fraude es realmente bajo | Costo operativo; depende de la precisión del analista y de la capacidad de la cola | La exclusión podría dar lugar a fraude si no se valida adecuadamente |
Validación | Supervisar las tasas de fraude después de la eliminación | Realiza un seguimiento de la precisión de las decisiones de los analistas y de la carga de la cola a lo largo del tiempo | Modo sombra / prueba de reglas desafiantes antes del despliegue completo |
La “imagen en espejo” de la detección de fraude: cómo crear exclusiones correctamente
El proceso para mejorar una regla con muchos falsos positivos es casi idéntico a la forma en que diseñas una nueva regla de fraude, solo que a la inversa.
Piénsalo. Cuando diseñas una regla antifraude, tú:
- Revisa un conjunto de casos de fraude confirmados.
- Identifica el patrón que comparten.
- Compara ese patrón de fraude con la población general de buenos clientes.
- Crea una lógica que detecte el fraude sin incluir demasiados eventos legítimos.
Para reducir los falsos positivos, haces lo mismo pero con el objetivo contrario en mente. Tú:
- Revisa un conjunto de casos confirmados como falsos positivos.
- Identificar sus patrones repetitivos.
- Compara esos patrones con los casos de fraude para asegurarte de que la separación sea real.
- Cree exclusiones o ajustes que capten esa separación sin “liberar” demasiado fraude.
Este último paso es crucial. No basta con decir: “Muchos falsos positivos tienen la característica X”. Tienes que demostrar que tus casos de fraude no presentan esa misma característica. De lo contrario, tu exclusión debilitará tu detección de fraude.
¿Lo mejor de todo? Si has seguido todos los pasos sin saltarte ninguno, ya hiciste esta revisión manual mientras validabas las métricas de falsos positivos.
Veamos un ejemplo. Supongamos que tienes una regla de desajuste muy estándar:
«Rechazar si el país de la IP no coincide con el país de la cuenta».
Esto es común y a menudo genera mucho ruido. Ahora imagina que revisas manualmente una muestra de 100 eventos que esta regla bloqueó. Después de etiquetarlos, notas lo siguiente:
- 30 eran fraude
- 70 eran legítimos
- Y de esos 70 eventos legítimos, 20 involucraron a usuarios de EE. UU. cuyas direcciones IP se resolvieron en Canadá
20 de 70 es un patrón significativo.
Tal vez tu empresa tenga una gran población que viaja a diario entre EE. UU. y Canadá. Quizá los VPN para endpoints canadienses sean comunes. Puede que parte de tu base de usuarios trabaje cerca de la frontera. Sea cual sea la razón, este desajuste específico (cuenta de EE. UU. → IP canadiense) parece generar muchos falsos positivos.
Si, en tus casos de fraude, ves poco o ningún fraude que provenga de ese mismo patrón de EE. UU. → Canadá, entonces tienes una separación clara. Eso significa que puedes introducir con seguridad una exclusión:
“Rechazar si (el país de la IP no coincide con el país de la cuenta) Y NO (el país de la IP es CA y el país de la cuenta es US)”
O mejor aún, amplíalo un poco para incluir lógica de países vecinos, según la presencia de tu negocio y las funciones disponibles.
La cuestión es que la exclusión se obtiene a partir de revisar tu población de falsos positivos y se valida frente a tu población de fraude.
Así es como perfeccionas las reglas sin abrir brechas peligrosas.
Prueba los cambios en la lógica antes de publicarlos
Cada vez que cambias la lógica de fraude, incluso si solo se trata de una exclusión en una regla existente, estás modificando tu perfil de riesgo. Esto es igual que cuando lanzas una regla nueva completamente desde cero.
Así que, antes de lanzar la nueva versión, pruébala.
Modo sombra y reglas desafiantes son tus aliadas. Mantén la regla existente activa, pero ejecuta tu regla refinada en paralelo durante unos días. Mide las diferencias:
- ¿Cuántos eventos adicionales habría permitido?
- ¿Cuántos de esos eventos se convirtieron en fraude?
- ¿Cuántos falsos positivos habría evitado?
Si los resultados se mantienen con el tiempo, puedes implementar con confianza. Si no, ajusta.
¿Durante cuánto tiempo deberías supervisar estos cambios?
Idealmente, el suficiente como para obtener una buena medida de la rapidez con la que madura el fraude en la nueva versión y de si eso está o no en línea con la versión original. Si vas muy justo de tiempo, quizá quieras considerar revisar manualmente muestras aleatorias.
Al tratar problemas de datos
Como vimos en la parte 2 de esta serie, a veces la causa principal de los falsos positivos no es una lógica defectuosa, sino datos corruptos.
En el mejor de los casos, ya lo has identificado en tu análisis preliminar. En el peor de los casos, pasaste por todos los pasos solo para descubrirlo durante tu revisión manual detallada.
Cuando esta es la causa raíz identificada, tienes dos opciones, dependiendo de si el problema de datos se puede solucionar a corto plazo.
Opción 1: Corregir el propio problema de calidad de los datos
Si el campo dañado está bajo tu control, ya sea tu SDK, tu integración interna o tu infraestructura, entonces la mejor solución a largo plazo es reparar los datos.
Eso podría implicar corregir una carga útil de la API, ajustar una versión del SDK o trabajar con un equipo de producto para tapar una brecha.
Puede llevar unos días o unas semanas, según tu organización. Pero una vez que se corrijan los datos, la regla a menudo volverá a comportarse correctamente.
Además, es probable que también hayas resuelto una serie de problemas que al mismo tiempo estaban afectando a otros departamentos.
Opción 2 - Ajustar la lógica de fraude para ese flujo
No todos los problemas de datos se pueden solucionar internamente. A veces se originan en terceros externos que simplemente no puedes controlar. O, en los casos más frustrantes, sí controlas estos problemas, pero no hay una solución a la vista.
Si no puedes corregir pronto los datos subyacentes, es posible que tengas que ajustar tu lógica de fraude específicamente para ese flujo. Una vez más, puedes considerar algunas alternativas:
- Excluir por completo del criterio el flujo problemático.
- Reducir el peso de la regla o cambiar su impacto.
- Mueve esos casos a revisión manual.
La prevención del fraude es más pragmática que elegante y, a veces, no se trata de tener razón, sino de ser inteligente.
Lo que deberías tener al final de la parte 3
En esta etapa, deberías ser capaz de:
- Identifica los principales factores que generan falsos positivos en mayor volumen.
- Determina si cada uno debe eliminarse, redirigirse o perfeccionarse.
- Aplica el método de “imagen especular” para crear exclusiones eficaces y seguras.
- Distinguir entre un comportamiento realmente inapropiado y problemas de calidad de los datos.
- Valida cada cambio mediante el modo sombra antes de implementarlo.
Este es el núcleo táctico de la reducción de falsos positivos: tratar con los actores específicos dentro de tu sistema.
Pero hay una capa más que aún no hemos abordado, una capa arquitectónica que opera por encima de las reglas, los modelos, los agentes e incluso la revisión manual.
Esa capa es a donde nos lleva la parte 4. Nos vemos allí.
