The Saturday Fraud Strategist
Clase magistral sobre falsos positivos, Parte 3: Cómo reducir los FPs dentro de tu sistema
9 min
Bien, el tema con la reducción de falsos positivos es el siguiente. La mayoría de los equipos quiere pasar directamente a las tácticas. Ajustar la regla. Modificar el umbral. Añadir una excepción. Pasar los casos raros a revisión manual. Bien. Todo eso puede ser útil. Pero, sinceramente, si empiezas por ahí, probablemente estés adivinando.
Y adivinar en la prevención del fraude no es precisamente mi modelo operativo favorito. No porque nunca funcione. A veces sí lo hace. Lo cual es casi peor, porque entonces todo el mundo se confía. No es una buena señal.
En este episodio continúo con la Masterclass sobre falsos positivos, pasando de la medición y la segmentación a la parte a la que todo el mundo quiere llegar: arreglar las partes del sistema que se están comportando mal. Pero el objetivo no es solo reducir los falsos positivos. El objetivo es reducir los falsos positivos sin crear un nuevo problema de fraude que solo descubres tres semanas después, cuando las pérdidas maduran y todo el mundo empieza a mirar el panel en silencio, como si los hubiera traicionado personalmente.
Este episodio trata sobre la disciplina. Trata de la revisión manual, las reglas antifraude, la precisión del modelo de fraude, el recall del modelo de fraude, las pruebas en modo sombra, los problemas de calidad de los datos y la incómoda pero necesaria pregunta que todo equipo de fraude acaba teniendo que hacerse: ¿esta regla realmente está ayudando, o solo le hemos tomado apego emocional desde aquel pico de fraude en 2022?
Lo que escucharás en este episodio:
- Por qué la reducción de falsos positivos debe comenzar con una revisión manual y no con el instinto
- Cómo decidir si una regla de fraude debe eliminarse, relajarse o mejorarse
- Por qué la precisión y el recall del modelo de fraude son importantes cuando las reglas detectan fraude pero perjudican a los buenos usuarios
- Cómo crear exclusiones sin abrir accidentalmente una puerta trasera para los estafadores
- Por qué las pruebas en modo sombra y las reglas desafiantes son esenciales antes del lanzamiento
- Cómo los problemas de calidad de los datos pueden hacer que una lógica de prevención de fraude por lo demás razonable se comporte de forma incorrecta
- Por qué los equipos de operaciones contra el fraude deben ser pragmáticos, no elegantes, cuando los datos están dañados
Deberías escuchar este episodio si:
- Ser responsable de reglas de fraude, reglas de detección de fraude, modelos, agentes de IA o flujos de revisión
- Están intentando reducir los falsos positivos sin aumentar las pérdidas por fraude
- Tienen una alta tasa de falsos positivos, pero no están seguros de qué parte del sistema la está causando
- Necesita una forma más estructurada de revisar las muestras de revisión manual y los principales infractores
- Están lidiando con datos corruptos, señales ruidosas o flujos en los que la lógica de prevención de fraude sigue fallando
Notas del episodio y puntos clave
Reducir los falsos positivos empieza por observar, no por adivinar
El primer punto incómodo de este episodio es también el más sencillo: no puedes resolver un problema de falsos positivos solo desde un panel de control. Tienes que mirar. Manualmente. Casos reales. Ya sé, muy glamuroso. Todo el mundo se metió en operaciones antifraude para poder revisar 100 casos bloqueados y preguntarse por qué existe una regla. Pero, siendo sinceros, es aquí donde empieza el trabajo realmente útil.
Si una regla, un modelo o un agente de IA está generando un número elevado de falsos positivos, el primer paso es revisar manualmente una muestra de lo que ha bloqueado. En la mayoría de los casos, entre 50 y 100 eventos son suficientes para obtener una orientación clara. No estás intentando escribir una tesis; estás intentando responder a preguntas prácticas:
- ¿Esta regla es realmente tan imprecisa como pensamos?
- ¿Esta regla todavía merece existir?
- ¿Debería seguir tomando decisiones automatizadas?
- ¿Podría pasar a una revisión manual en su lugar?
- ¿Qué reduciría los falsos positivos sin aumentar de forma significativa las pérdidas por fraude?
La clave es que cada respuesta depende de tu negocio. No existe un umbral universal de “suficientemente bueno”. Algunos equipos tienen capacidad para revisiones manuales. Otros no realizan revisiones manuales en absoluto. Algunas reglas generan mucho ruido, pero siguen siendo necesarias porque el volumen es demasiado grande para enviarlo a los analistas. ¿Molesto? Sí. Pero también es la realidad.
Tres caminos para cada regla de fraude que se comporta mal
Una vez que revises las pruebas, la mayoría de las reglas o modelos de fraude que se comportan de forma incorrecta encajan en una de tres categorías. Aquí es donde el trabajo se vuelve más claro.
La primera categoría son las reglas que no deberían existir en absoluto. Estas son las de “fruta al alcance de la mano”. Normalmente se crearon durante una crisis, detectaron algo una vez y luego se quedaron en producción para siempre porque nadie quiso tocarlas. Muy humano. Muy común. Y tampoco muy bueno. Si la cobertura de fraude es insignificante y los falsos positivos son significativos, eliminar la regla puede ser la solución más segura y más limpia.
La segunda categoría son reglas que deberían existir, pero que ya no deberían tomar decisiones automatizadas. Son reglas de precisión media. Detectan fraude relevante, pero no lo hacen con la suficiente fiabilidad como para justificar un rechazo automático. Si tu equipo de operaciones de fraude tiene capacidad, trasladar esa lógica a la gestión de casos puede mantener la cobertura de fraude y, al mismo tiempo, reducir los falsos positivos. Incorporas a una persona en el proceso, y esa persona puede detectar cambios en los patrones en tiempo real.
La contrapartida es el costo. La revisión manual es útil, pero no es gratuita. Reduces los falsos positivos, pero aumentas la carga operativa. Así que tienes que preguntarte si el compromiso realmente vale la pena.
La tercera categoría es la más común y la más interesante: reglas que deberían existir, pero que necesitan mejorarse. Estas reglas suelen tener una alta cobertura y baja precisión. En términos sencillos, detectan el fraude, pero también afectan a demasiados usuarios legítimos. Así que la respuesta no es eliminarlas, sino perfeccionarlas.
La reducción de falsos positivos es la detección de fraude a la inversa
Una de las formas más útiles de pensar en la reducción de falsos positivos es que, básicamente, es detección de fraude a la inversa.
Cuando creas una regla de fraude, normalmente comienzas con casos de fraude confirmados. Revisas esos casos, identificas el patrón que comparten, comparas ese patrón con la población legítima y luego construyes una lógica que detecte el fraude sin atrapar demasiados eventos legítimos.
Para reducir los falsos positivos, haces lo mismo pero con el objetivo contrario. Empiezas con falsos positivos confirmados, identificas los patrones que comparten, comparas esos patrones con los casos de fraude y luego creas exclusiones que separan a los buenos usuarios del fraude sin liberar demasiado riesgo.
Aquí es donde los equipos a veces se meten en problemas. No basta con decir: “Muchos falsos positivos se ven como X”. De acuerdo, es útil. Pero, ¿los casos de fraude también se ven como X? Si la respuesta es sí, tu exclusión no es una exclusión. Es una invitación al fraude con mejor formato.
Ese último paso es importante. Mucho.
Cómo crear exclusiones sin abrir puertas traseras al fraude
El ejemplo de este episodio es intencionalmente sencillo: rechazar si el país de la IP no coincide con el país de la cuenta. Es una regla básica de discrepancia y, sí, las reglas del mundo real suelen ser más complejas. Pero no siempre tanto como nos gusta aparentar.
Supongamos que revisas manualmente 100 eventos bloqueados por esta regla. Treinta son fraude. Setenta son legítimos. De esos 70 eventos legítimos, 20 involucran a usuarios de EE. UU. cuyas direcciones IP aparecen en Canadá. Ese es un patrón significativo de falsos positivos.
Ahora la siguiente pregunta es la importante: ¿tus casos de fraude también muestran ese patrón de cuenta estadounidense con IP canadiense? Si no, es posible que tengas una separación clara. Tal vez tengas personas que se desplazan a diario. Tal vez las VPN se enruten a través de puntos de salida en Canadá. Tal vez tu base de usuarios viva cerca de la frontera. Sea cual sea la causa, el patrón de falsos positivos es real y la superposición con el fraude es baja.
Eso te da la base para una exclusión más segura: rechaza si el país de la IP no coincide con el país de la cuenta, a menos que el país de la IP sea Canadá y el país de la cuenta sea Estados Unidos.
O, dependiendo de la presencia de tu negocio y de las funciones disponibles, quizá amplíes eso a una lógica de países vecinos. El punto no es la regla exacta. El punto es el método. La exclusión proviene de la población de falsos positivos y se valida frente a la población de fraude.
Así es como reduces los falsos positivos sin crear accidentalmente un nuevo punto de entrada para los estafadores. ¿Soy demasiado optimista al pensar que todo el mundo hace este paso? Probablemente.
Prueba cada cambio en la lógica antifraude antes de lanzarlo
Cada vez que cambies la lógica de prevención de fraude, incluso si es “solo” una exclusión, estarás modificando tu perfil de riesgo. Trátalo como si fuera el lanzamiento de una nueva regla.
Las pruebas en modo sombra y las reglas desafiantes son tus mejores aliadas aquí. Mantén la regla actual activa, pero ejecuta la versión refinada en paralelo. Luego mide la diferencia.
Quieres saber:
- ¿Cuántos eventos adicionales permitiría la nueva versión?
- ¿Cuántos de esos eventos terminan convirtiéndose en fraude?
- ¿Cuántos falsos positivos evitaría el cambio?
- ¿La nueva lógica se comporta de manera consistente a lo largo del tiempo?
Si los resultados se mantienen, puedes implementar con más confianza. Si no, haz ajustes. No es algo glamuroso. No es un gran momento de lanzamiento dramático. Es simplemente una mejor operación contra el fraude.
La ventana de monitoreo debe depender de la rapidez con la que el fraude madura en tu entorno. Si tienes tiempo, espera lo suficiente para comparar los resultados de fraude en la versión desafiante con los de la original. Si estás bajo presión, revisa manualmente muestras aleatorias. No es perfecto, pero es mejor que ir a ciegas.
Los problemas de calidad de los datos pueden hacer que una buena lógica parezca mala
A veces el problema no es la regla, sino los datos que la alimentan.
Esto es frustrante porque todo el mundo quiere que la solución esté en la lógica de fraude. Cambia la regla, baja la puntuación, añade la excepción, lánzalo. Pero si el campo subyacente está dañado, falta, es inconsistente o está roto en un flujo específico, es posible que la regla se esté comportando exactamente como fue diseñada. El problema es simplemente la entrada.
Vale. Molesto, pero útil saberlo.
Si el problema de datos está bajo tu control, la mejor solución a largo plazo es corregir el propio problema de calidad de los datos. Eso puede implicar reparar la carga útil de una API, actualizar una versión del SDK, arreglar una integración interna o trabajar con los equipos de producto e ingeniería para cerrar la brecha. Puede llevar días. Puede llevar semanas. Pero una vez que los datos estén corregidos, la regla antifraude puede empezar a comportarse correctamente de nuevo.
Además, es posible que soluciones otros problemas al mismo tiempo. Los problemas de datos rara vez arruinan solo una cosa. Suelen deambular por el sistema en silencio, empeorando varias cosas. Muy eficientes, en el peor sentido posible.
Cuando los datos no puedan corregirse rápidamente, ajusta la lógica
No todos los problemas de calidad de datos se pueden resolver a corto plazo. A veces provienen de un socio externo. A veces vienen de una plataforma que no controlas. A veces vienen de un sistema que técnicamente sí controlas, pero la solución está enterrada detrás de 14 prioridades en la hoja de ruta y de un equipo que no deja de decir “el próximo trimestre”. No se ve bien, pero resulta familiar.
Si no puedes corregir los datos pronto, ajusta la lógica de fraude para ese flujo. Eso podría significar excluir el flujo problemático de la regla, reducir el peso de la regla, cambiar el impacto de la regla o pasar esos casos a revisión manual.
Aquí es donde la prevención del fraude debe ser pragmática más que elegante. Un sistema limpio es algo bueno. Un sistema que funciona es mejor. A veces la respuesta correcta no es la más satisfactoria desde el punto de vista teórico. A veces es la que mantiene a los buenos usuarios avanzando mientras sigue conteniendo el riesgo de fraude.
Conclusión final:
Reducir los falsos positivos no se trata de hacer que tu sistema sea más permisivo, sino de hacerlo más preciso.
Eso significa revisar los eventos reales, separar las reglas que deben eliminarse de las que deben degradarse o mejorarse, crear exclusiones basadas en evidencia, validar esas exclusiones frente a casos de fraude, probar los cambios en modo sombra y corregir los problemas de calidad de los datos cuando la lógica no es realmente el problema.
En cualquier caso, la conclusión ligeramente incómoda es esta: si estás reduciendo falsos positivos sin analizar los casos subyacentes, no estás ajustando nada. Solo estás adivinando.
Y quizá tengas suerte. Quizá.
Pero en la prevención del fraude, la suerte no es realmente un control. Es más bien una condición temporal.
Conecta con Chen Zamir | LinkedIn
Presentador de The Saturday Fraud Strategist
Ayudando a las fintech a construir defensas contra el fraude más inteligentes
Coautor de «The Fraud Fighter’s AI Playbook»
¿No estás listo para dejar de hablar de mi, y ojalá también tu, tema favorito? Suscríbete a The Saturday Fraud Strategist newsletter.
Episode transcript
Chen Zamir
00:03
When people talk about reducing false positives, they usually jump straight to tactics: tuning rules, adjusting thresholds, adding exemptions, redirecting edge cases to manual review, and so on. All of that is important, but it shouldn't be where you start. In the previous parts of this masterclass, we've covered the two pieces of work that most teams skip: how to measure your false positives, and how to map them into buckets by actor, by solution, by flow, by data quality, and by what is or isn't under your control. That's the groundwork. Now you're ready to tackle the main course, fixing the parts of the system that are misbehaving. But this is where we should approach the work with discipline. Otherwise, you'll end up making changes that don't matter, overlook changes that would have mattered, or worst of all, open the door for additional fraud without realizing it. So let's get down to it.
Chen Zamir
01:07
One of the best ways to ground yourself before making any change is to go back to manual review. Pick a rule, a model, or an AI agent that creates a high number of false positives, and manually inspect a sample of the events it blocked. 50 to 100 should be enough in most cases. What you're trying to answer are often very basic questions. Is this rule actually as inaccurate as we think? Do we still want this rule to exist at all? If it exists, should it still make automated decisions, or should it fit into manual review instead? And if it should remain automated, what would it take to reduce its false positives without materially increasing our fraud losses? Each of these questions is business specific. There is no universal threshold for good enough. Sometimes your fraud ops team can take on the additional workload. Sometimes you have no manual reviews at all as part of your process. And sometimes a rule needs to remain automated, even if it's noisy, because you simply cannot afford to manually review that volume. But you need clarity before you change anything. The worst case is thinking a rule is fine because it looks logical, only to discover under review that it's blocking overwhelmingly legitimate traffic.
Chen Zamir
02:43
You can't reason your way through these situations, you have to look. But most importantly, this isn't about validating that you're fixing a real problem. It's about discovering how to do it.
Chen Zamir
03:02
Once you've reviewed the evidence, almost every misbehaving solution falls into one of three categories. The first is that the rule shouldn't exist at all. This happens more often than teams admit. Many times it would catch only a small population, would not block much fraud, but would generate a disproportionate amount of false positives. Usually it exists only because someone added it during a crisis, and no one ever bothered to revisit it since then. Removing such rules feels uncomfortable the first few times you do it, but if the fraud they catch is negligible and the false positives are significant, turning them off is one of the cleanest, safest ways to improve your system. So this category has your low-hanging fruits. The second category is of rules that should exist, but no longer make automated decisions. This is common with mid accuracy logic that still captures meaningful fraud, but not reliably enough to block without human review. If you have manual review capacity, and if this particular logic tends to produce events your analysts are comfortable judging, then flagging it to case management instead of auto decline can be the perfect compromise. You preserve fraud coverage, reduce false positives, and put a human in the loop that can observe pattern changes in real time. The downside, of course, is that it's resource intense. You have fewer false positives, but at higher operational costs. And to be honest, I try as much as possible not to resort to it. The third category is of rules that should exist, but they need to be improved first.
Chen Zamir
05:06
This is the most interesting scenario, and it's also the most common one. In this case, the logic captures fraud effectively, meaning the recall is high, but at the cost of impacting many good users, meaning the precision is low. So you need to refine it. The question is how?
Chen Zamir
05:31
The process for improving a false positive heavy rule is exactly the same as when you design a new fraud rule, just in reverse. Think about it. When you design a fraud rule, you review a set of confirmed fraud cases, identify the pattern they share, compare that fraud pattern to the general good population, and build logic that captures the fraud without catching too many good events. Now, to reduce false positives, you do exactly the same thing, but with the opposite goal in mind. You review a set of confirmed false positive cases, identify the repeating patterns, compare those patterns to the fraud cases to make sure you know how to separate them, and finally build exclusions that capture that separation without releasing too much fraud. And this last step is crucial. It's not enough to say a lot of false positives look like X. You need to prove that your fraud cases don't also look the same. Otherwise, your exclusion will undermine your fraud detection. But here's the thing: if you've worked through the steps I outlined without skipping any, you already did this manual review while validating the false positive metrics. Let's take an example. Suppose you have a very standard mismatch rule: decline if IP country mismatch account country. Obviously, given a simplified scenario, but keep in mind that in reality, many rules are not that much more sophisticated than that. Now imagine you manually review a sample of 100 events this rule blocked. After tagging them, you notice 30 were fraud, 70 were legitimate, and out of those 70 legitimate events, 20 involved US users whose IP addresses appeared in Canada. 20 out of 70 is a meaningful pattern. Maybe your business has a large US-Canadian commuting demographic. Maybe VPNs for Canadian endpoints are common. Maybe part of your user base works close to the border. For whatever reason, this specific mismatch, US account and Canadian IP, seems to produce a lot of false positives. If in your fraud cases you see little to no fraud coming from the same US-Canada pattern,
Chen Zamir
07:59
Then you have a clean separation. That means you can safely introduce an exclusion. Decline if IP country mismatch account country and not IP country equals Canada and account country
Chen Zamir
08:18
Equals US. Or better yet, broaden it slightly to include general neighboring country logic, depending on your business footprint and available features. The point is that the exclusion is derived from reviewing your false positive population, and is validated against your fraud population. This is how you refine rules without accidentally creating backdoors for fraudsters to exploit.
Chen Zamir
09:10
Anytime you change a fraud logic, even if it's just an exclusion on an existing rule, you're changing your posture. That's the same as releasing a new rule completely from scratch. So before you release the new version, test it. Shadow mode and challenger rules are your best friends here.
Chen Zamir
09:36
Keep the existing rule active, but run your refined rule in parallel. Measure the differences. How many additional events would it have allowed to go through? How many of those events matured into fraud? How many false positives would it have prevented? If the results hold over time, you can deploy with confidence. If not, adjust. How much time should you monitor these changes? Ideally, enough to gain a good measure of how fast fraud matures in the new version, and whether that's in line or not with the original version. And if you're really pressed for time, you may want to consider manually reviewing random samples.
Chen Zamir
10:25
As we explored in part two of the masterclass, sometimes the root cause of false positives is not faulty logic, but corrupted data. Best case, you've already identified it in your groundwork analysis. Worst case, you went through all of the motions just to figure it out on your detailed manual review. When this is the identified root cause, you have two options, depending on whether the data issue is fixable in the near term. Option one is to fix the data quality issue itself. If the corrupted field is under your control, be it your SDK, your internal integration, or your infrastructure, then the best long-term solution is to repair the data. That might mean fixing an API payload, adjusting an SDK version, or working with a product team to plug a hole. It may take a few days or a few weeks, depending on your organization. But once the data is fixed, the rule will often start behaving correctly again. Also, it's likely that you also solved a whole bunch of other issues that were plaguing other solutions at the same time. Your second option is to adjust the fraud logic for that flow. Not all data issues are internally fixable. Sometimes they originate from external parties that you just cannot control. Or, in the most frustrating cases, you do control these issues, but there's no fix in sight. If you cannot fix the underlying data soon, then you may need to adjust your fraud logic specifically for that flow. You have a couple of choices here. Either exclude the problematic flow from the rule altogether, lower the rule's weight or change its impact, or move those cases to manual review.
Chen Zamir
12:19
Whatever you do, just keep in mind that fraud prevention should be more pragmatic than elegant. And sometimes it's not about being right, it's about being smart.
View full transcript
