En esta serie de blogs, Chen Zamir aborda un problema de fraude (casi) existencial: cómo reducir los falsos positivos. En la parte 1, presenta cinco formas prácticas en que los equipos de fraude cuantifican los rechazos falsos cuando los datos no ofrecen respuestas.
Todo el mundo está de acuerdo en que los falsos positivos son malos, pero casi nadie puede cuantificarlos.
Pregúntale a un líder de fraude cuántos contracargos hubo el mes pasado y te dará una cifra precisa. Pregunta cuántos buenos clientes fueron bloqueados por error y obtendrás un encogimiento de hombros o, peor aún, “Ninguno”.
No es porque a la gente no le importe. Es porque la forma en que construimos los sistemas antifraude hace que los falsos positivos sean invisibles por diseño.
Si apruebas una transacción, el mundo te da retroalimentación. Si fue fraude, te enterarás. Si fue legítima, verás que el cliente regresa, gasta más, inicia sesión de nuevo y hace las cosas normales que hace un cliente.
Pero si bloqueas algo, esa señal desaparece.
En el mejor de los casos, un cliente se queja. Pero incluso entonces, esa queja rara vez vuelve a reflejarse en tus datos. Normalmente muere aislada, enterrada en un ticket de soporte, atrapada en una bandeja de entrada o desvaneciéndose en el recuerdo de una llamada telefónica airada.
Casi nunca se convierte en una etiqueta estructurada asociada a un evento específico, del tipo que alimenta tus canalizaciones de entrenamiento de modelos o impulsa tus paneles de control.
Entonces, antes de hablar de reducir los falsos positivos, tenemos que hablar de etiquetar esos casos.
La Parte 1 de esta serie aborda esta paradoja: ¿cómo se mide un error que el sistema está diseñado para ocultar?
No existe una solución mágica. Medir los falsos positivos siempre es un ejercicio de triangulación. Debes combinar varios métodos imperfectos hasta que la señal forme una imagen lo suficientemente nítida para tomar decisiones.
Vamos al grano.
5 formas de medir los falsos positivos en sistemas de fraude
Qué | Cómo |
Simulación | Prueba retrospectivamente las reglas con datos históricos para identificar falsos rechazos. |
Revisión manual | Audita las transacciones rechazadas para detectar errores. |
Vinculación conductual | Registrar a los usuarios bloqueados que regresan con buena actividad |
Grupos de control | Permite que un grupo de prueba pase para medir lo que te estás perdiendo |
Comentarios de los usuarios | Encuestar a los usuarios sobre las transacciones rechazadas |
Método 1: simulación de tus reglas y flujos de trabajo
Los equipos tienden de forma natural a recurrir a la simulación porque es fácil: simplemente haces backtesting de tu lógica con datos históricos.
Toma una regla, o un conjunto de reglas, o un flujo de trabajo, y ejecútalo contra los últimos 6 meses de tráfico. Observa todos los eventos que habría rechazado y luego compáralos con su estado final (fraude o legítimo).
Es fundamental no olvidar tener en cuenta la maduración del fraude. Como los contracargos tardan en materializarse, los datos recientes están, en la práctica, “sin etiquetar”. Un margen de 30 días es el mínimo; una ventana de 90 días garantiza que tus usuarios “limpios” sean realmente limpios.
Cualquier transacción etiquetada como 'limpia' que tu regla habría bloqueado es un Falso Positivo teórico.
El atractivo aquí es la accesibilidad: puedes ejecutar esto en SQL o en tu plataforma de fraude sin desplegar ninguna infraestructura nueva.
Pero la simulación tiene limitaciones importantes. Estás probando una sola regla de forma aislada, pero en producción esa regla forma parte de una compleja “pila de decisiones” con diferentes reglas, umbrales de modelos, agentes de IA, revisiones manuales, decisiones de terceros y mucho más.
En realidad, una regla no opera por sí sola. Puede quedar anulada por un bloqueo anterior o ser revocada por una revisión manual. Tu simulación asume que tu regla es la autoridad final; en producción, a menudo es solo una voz más dentro de un conjunto.
Tampoco puedes hacer backtesting de la fricción operativa. La simulación asume una ejecución de código perfecta, pero pasa por alto errores, problemas de integración o el comportamiento de actores aguas arriba como emisores y procesadores. Todos ellos pueden generar falsos positivos, y ninguno queda reflejado en un simple ejercicio de “Si esta regla hubiera estado activa, ¿qué habría hecho?”.
Así que sí, simula. Es un buen comienzo. Solo no confundas “Esta regla tiene una baja tasa de falsos positivos” con “Esto es toda la imagen”.
Método 2: revisión manual de eventos rechazados
El segundo método es más antiguo, más lento y mucho más potente: revisas manualmente el tráfico rechazado.
En lugar de fijarte en la lógica, te centras directamente en el impacto. Tomas una muestra de eventos bloqueados, ya sea de forma general o para una solución específica, y pides a un investigador de fraude con experiencia que los clasifique manualmente.
Este es esencialmente el mismo proceso que utilizas para diseñar nuevas reglas o buscar nuevos patrones de fraude, solo que aplicado a la inversa.
Las limitaciones son evidentes: no es escalable, requiere mucho tiempo y es costoso desde el punto de vista operativo. Además, necesitas analistas de alta especialización y, aun así, un porcentaje de los eventos seguirá siendo casos inconclusos de 'zona gris'.
Por otro lado, como se trata de una auditoría offline y no de una decisión en tiempo real, la precisión específica de cada caso importa menos. Además, no es necesario etiquetarlo todo.
Lo único que necesitas es una idea de en qué punto estás y dónde están los peores infractores. Al fin y al cabo, no importa mucho si concluyes que una regla tiene una precisión del 45% o del 48%.
También es posible combinar los dos primeros métodos. Esto es especialmente útil cuando se trata de un nuevo patrón de fraude que quieres bloquear y no puedes permitirte esperar a que “madure”. Simplemente ejecuta la lógica sobre el último mes y luego revisa una muestra de los resultados para evaluar el rendimiento.
Método 3: Vincular las denegaciones con el comportamiento positivo posterior
El tercer método es el que considero más subestimado: el enlace.
La idea es sencilla: en muchos casos, los buenos usuarios aparecen varias veces en tu plataforma antes, o incluso después, de que sean bloqueados. Pueden intentarlo de nuevo con una tarjeta diferente. Pueden volver a intentar el registro con una dirección de correo electrónico distinta. Pueden volver a realizar transacciones desde el mismo dispositivo con una dirección IP que no consideres arriesgada.
Si puedes vincular esos eventos y ver la secuencia completa, de repente obtienes una señal extremadamente fuerte de que el rechazo original fue un falso positivo.
Este vínculo puede ser directo:
- Mismo ID de usuario, tarjeta diferente.
- Mismo dispositivo, correo electrónico diferente.
- Misma IP y nombre, dispositivo diferente.
O también puede ser más probabilístico (más difuso), como un usuario bloqueado seguido del registro exitoso de su cónyuge en el mismo hogar.
Una vez que tienes la infraestructura básica en su lugar, el método escala de forma excelente. Simplemente revisas periódicamente tu población bloqueada e intentas asociarla con eventos positivos que ocurrieron antes o después.
El problema es que necesitas esa infraestructura. Tienes que investigar una heurística que funcione bien. Necesitas algún tipo de resolución de entidades. Debes ser capaz de extraer secuencias de eventos a lo largo del tiempo. Ese trabajo no es trivial.
Pero el retorno de la inversión es enorme. Generas un flujo continuo de etiquetas de falsos positivos de alta precisión. No detectará todos los falsos positivos, pero los que detecte serán muy fiables.
Método 4 - Grupos de control: Dejar pasar algo de fraude a propósito
El cuarto método es el que incomoda un poco a todo el mundo: los grupos de control.
Tomas una muestra aleatoria del tráfico, normalmente del 1 %, y la autorizas por completo.
Sin reglas. Sin rechazos basados en modelos. Sin revisión manual. Esta población pasa directamente al siguiente paso, sea procesamiento de pagos, creación de cuentas o acceso a funciones.
Entonces simplemente observas lo que sucede.
Si tu sistema en general funciona bien, verás una cantidad significativa de fraude en ese grupo de control. Si, por otro lado, notas que la tasa de falsos positivos del grupo de control es mucho más alta de lo que esperabas, entonces sabrás que necesitas volver a examinar tu configuración.
Los grupos de control son poderosos porque responden a una pregunta muy directa: “¿Qué pasaría si elimináramos el sistema por completo para algunos usuarios?” La respuesta por lo general no es agradable de ver, pero es honesta.
Este enfoque, sin embargo, solo es práctico a gran escala. Necesitas suficiente tráfico para que uno o dos por ciento sigan produciendo cifras estadísticamente significativas en un plazo que tenga sentido.
También necesitas contar con un presupuesto que pueda absorber las pérdidas. Para una pequeña fintech con márgenes reducidos y volumen limitado, esto puede no ser viable. Para los actores más grandes, es una de las pocas herramientas que te ofrece una medición realmente imparcial.
Método 5: preguntar al usuario
El quinto método, solicitar comentarios directos del usuario, es una táctica más oportunista que solo está disponible en contextos específicos. Si estás revisando transacciones rechazadas en cuentas que ya conoces y en las que confías, puedes activar una notificación fuera de banda: “Bloqueamos una transacción que terminaba en 1234. ¿Fuiste tú?”
Si el usuario ha iniciado sesión y está autenticado, un mensaje dentro de la aplicación o un correo electrónico puede preguntar explícitamente si un bloqueo determinado fue legítimo.
Pero esto no es algo que puedas aplicar de forma general. Es inutilizable durante el onboarding cuando nunca has visto al usuario antes; preguntarle a un desconocido si es un estafador no aporta datos útiles.
Además, y no puedo enfatizar esto lo suficiente, no les des a los estafadores una forma de marcar sus propios intentos como “buenos”. Si un botón de “Sí, fui yo” levanta automáticamente el bloqueo, no has creado un circuito de retroalimentación, has creado una puerta trasera para que los estafadores se incluyan a sí mismos en la lista blanca.
Pero como una fuente adicional de verdad fundamental en situaciones muy específicas, como intentos de inicio de sesión fallidos o cambios en los datos de contacto, esto puede ser sorprendentemente útil.
No existe un único método mágico
Si tu conclusión es «Ninguno de estos es perfecto», estás en lo correcto. Esa es la naturaleza del asunto.
No estás buscando una única métrica mágica que te diga el número exacto de falsos positivos en tu sistema. Lo que buscas es combinar varios indicadores independientes para lograr tanto precisión como escalabilidad.
En la práctica, la mayoría de los equipos terminan utilizando alguna combinación de:
- Simulación para comprobaciones rápidas, regla por regla.
- Revisión manual para flujos de alto valor y principales infractores.
- Vinculación como la principal canalización de medición continua una vez que se haya completado el trabajo de ingeniería.
- Grupos de control para grandes poblaciones en las que se puede tolerar cierta pérdida controlada.
- Comentarios de usuarios en contextos reducidos y cuidadosamente seleccionados.
Si combinas estos elementos correctamente, obtendrás una estimación útil de tus falsos positivos, desglosada al menos por algunas dimensiones importantes: flujo de producto, tipo de tráfico, capa de decisión, y así sucesivamente.
Y una vez que puedas medir el problema, por fin podrás hacer la pregunta correcta.
De «¿Cuántos?» a «¿De dónde?»
Una cosa es saber que tienes un problema de falsos positivos. Otra muy distinta es saber de dónde proviene.
¿Se debe principalmente a tus reglas? ¿Al umbral de tu modelo? ¿A tus revisores humanos? ¿A una integración específica que corrompe las direcciones IP en dispositivos móviles? ¿A un procesador de pagos de terceros que es extremadamente agresivo en cierta región?
En la segunda parte de esta serie, tomaremos los falsos positivos que hayas logrado detectar y los agruparemos según su causa raíz. Veremos:
- Cuánto de tu problema de falsos positivos está realmente bajo tu control.
- Cuánto proviene de flujos y plataformas específicos.
- Cuánto se debe a problemas de calidad de los datos que no tienen nada que ver con el fraude.
- Y, lo más importante: cómo saber qué aspectos vale la pena corregir y con cuáles simplemente tendrás que aprender a convivir.
Cero falsos positivos es un mito. Pero aún puedes llegar a un punto en el que cada falso positivo restante sea aceptado conscientemente o esté fuera de tu esfera de influencia.
Y esa claridad por sí sola vale mucho.
Nos vemos todos en la parte 2.
