The Saturday Fraud Strategist
Masterclass sobre Falsos Positivos Parte 3: Como reduzir FPs dentro do seu sistema
9 min
Então, aqui está a questão sobre reduzir falsos positivos. A maioria das equipes quer ir direto para as táticas. Ajustar a regra. Ajustar o limite. Adicionar uma exceção. Mandar os casos estranhos e de borda para revisão manual. Tudo bem. Tudo isso pode ser útil. Mas, sinceramente, se é por aí que você começa, provavelmente está apenas chutando.
E ficar adivinhando em prevenção a fraudes não é exatamente o meu modelo operacional favorito. Não porque nunca funcione. Às vezes funciona. O que é quase pior, porque aí todo mundo fica confiante. Não é uma boa.
Neste episódio, dou continuidade à Masterclass sobre Falsos Positivos, passando da medição e segmentação para a parte em que todo mundo realmente quer chegar: corrigir as partes do sistema que estão se comportando mal. Mas a questão não é apenas reduzir os falsos positivos. A questão é reduzir os falsos positivos sem criar um novo problema de fraude que você só vai descobrir três semanas depois, quando as perdas amadurecem e todo mundo começa a olhar silenciosamente para o dashboard como se ele tivesse traído cada um pessoalmente.
Este episódio é sobre disciplina. Trata-se de revisão manual, regras de fraude, precisão de modelos de fraude, recall de modelos de fraude, testes em modo sombra, problemas de qualidade de dados e a pergunta desconfortável, mas necessária, que toda equipe de fraude eventualmente precisa fazer: esta regra está realmente ajudando ou estamos apenas emocionalmente apegados a ela desde aquele pico de fraude em 2022?
O que você vai ouvir neste episódio:
- Por que a redução de falsos positivos deve começar com uma revisão manual, não com o instinto
- Como decidir se uma regra de fraude deve ser removida, rebaixada ou aprimorada
- Por que a precisão e o recall do modelo de fraude são importantes quando as regras detectam fraudes, mas prejudicam bons usuários
- Como criar exclusões sem acidentalmente abrir uma porta dos fundos para fraudadores
- Por que os testes em modo sombra e as regras desafiadoras são essenciais antes do lançamento
- Como problemas de qualidade de dados podem fazer com que uma lógica de prevenção a fraudes, de outra forma razoável, se comporte de maneira inadequada
- Por que as equipes de operações de fraude precisam ser pragmáticas, e não elegantes, quando os dados estão comprometidos
Você deve ouvir este episódio se você:
- É responsável por regras de fraude, regras de detecção de fraude, modelos, agentes de IA ou fluxos de revisão
- Estão tentando reduzir falsos positivos sem aumentar as perdas por fraude
- Têm uma taxa alta de falsos positivos, mas não têm certeza de qual parte do sistema está causando isso
- Precisam de uma forma mais estruturada de revisar amostras de análises manuais e os principais infratores
- Estão lidando com dados corrompidos, sinais ruidosos ou fluxos em que a lógica de prevenção de fraude continua falhando
Notas do episódio e principais aprendizados
Reduzir falsos positivos começa com observar, não adivinhar
O primeiro ponto desconfortável neste episódio é também o mais simples: você não consegue resolver um problema de falsos positivos apenas olhando para um dashboard. Você precisa olhar de verdade. Manualmente. Para eventos reais. Eu sei, nada glamouroso. Todo mundo entrou em operações de fraude para poder inspecionar 100 casos bloqueados e se perguntar por que uma regra existe. Mas, sinceramente, é aqui que o trabalho útil começa.
Se uma regra, modelo ou agente de IA estiver gerando um número alto de falsos positivos, o primeiro passo é inspecionar manualmente uma amostra do que foi bloqueado. Na maioria dos casos, de 50 a 100 eventos são suficientes para obter uma noção direcional. Você não está tentando escrever uma tese. Você está tentando responder a perguntas práticas:
- Essa regra é realmente tão imprecisa quanto pensamos?
- Esta regra ainda merece existir?
- Ela ainda deve tomar decisões automatizadas?
- Ele poderia passar para uma revisão manual em vez disso?
- O que reduziria os falsos positivos sem aumentar de forma significativa as perdas por fraude?
O ponto principal é que cada resposta depende do seu negócio. Não existe um limite universal de “bom o suficiente”. Algumas equipes têm capacidade para revisão manual. Outras não fazem revisão manual nenhuma. Algumas regras geram muito ruído, mas ainda são necessárias porque o volume é grande demais para ser enviado aos analistas. Irritante? Sim. Mas também é a realidade.
Três caminhos para cada regra de fraude problemática
Depois de analisar as evidências, a maioria das regras ou modelos de fraude com mau desempenho se encaixa em uma de três categorias. É aqui que o trabalho fica mais claro.
A primeira categoria é a de regras que não deveriam existir de forma alguma. Elas são a fruta mais fácil de colher. Normalmente foram criadas durante uma crise, pegaram alguma coisa uma vez e depois ficaram em produção para sempre porque ninguém quis mexer nelas. Muito humano. Muito comum. E também, nada bom. Se a cobertura de fraude é insignificante e os falsos positivos são significativos, remover a regra pode ser a solução mais segura e mais limpa.
A segunda categoria é composta por regras que devem existir, mas que não deveriam mais tomar decisões automatizadas. São regras de precisão média. Elas identificam fraudes relevantes, mas não o fazem de forma suficientemente confiável para justificar uma recusa automática. Se a sua equipe de operações de fraude tiver capacidade, mover essa lógica para o gerenciamento de casos pode preservar a cobertura contra fraude enquanto reduz falsos positivos. Você coloca uma pessoa no processo, e essa pessoa consegue perceber mudanças de padrão em tempo real.
A contrapartida é o custo. A revisão manual é útil, mas não é gratuita. Você reduz falsos positivos, mas aumenta a carga de trabalho operacional. Então você precisa se perguntar se esse compromisso realmente vale a pena.
A terceira categoria é a mais comum e a mais interessante: regras que deveriam existir, mas precisam ser aprimoradas. Essas regras geralmente têm alta cobertura e baixa precisão. Em termos simples, elas detectam fraude, mas também atingem muitos usuários legítimos. Portanto, a resposta não é excluí-las. A resposta é refiná-las.
A redução de falsos positivos é a detecção de fraude ao contrário
Uma das maneiras mais úteis de pensar na redução de falsos positivos é que ela é, basicamente, a detecção de fraude ao contrário.
Quando você cria uma regra de fraude, normalmente começa com casos de fraude confirmados. Você analisa esses casos, identifica o padrão que eles têm em comum, compara esse padrão com a população legítima e então desenvolve uma lógica que detecta a fraude sem capturar eventos legítimos em excesso.
Para reduzir falsos positivos, você faz a mesma coisa, mas com o objetivo oposto. Você começa com falsos positivos confirmados, identifica os padrões que eles têm em comum, compara esses padrões com os casos de fraude e então cria exclusões que separam bons usuários de fraudadores sem liberar risco em excesso.
É aqui que as equipes às vezes se complicam. Não basta dizer: “Muitos falsos positivos parecem com X.” Ok, isso é útil. Mas os casos de fraude também se parecem com X? Se sim, a sua exclusão não é uma exclusão. É um convite à fraude com uma formatação melhor.
Esse último passo é importante. Muito importante.
Como criar exclusões sem abrir brechas para fraudes
O exemplo deste episódio é intencionalmente simples: recusar se o país do IP não corresponder ao país da conta. É uma regra básica de incompatibilidade e, sim, as regras do mundo real costumam ser mais complexas. Mas nem sempre tanto quanto gostamos de fingir.
Suponha que você revise manualmente 100 eventos bloqueados por essa regra. Trinta são fraude. Setenta são legítimos. Desses 70 eventos legítimos, 20 envolvem usuários dos EUA cujos endereços IP aparecem no Canadá. Isso é um padrão significativo de falsos positivos.
Agora, a próxima pergunta é a importante: seus casos de fraude também apresentam esse padrão de conta dos EUA com IP canadense? Se não, você pode ter uma separação clara. Talvez você tenha pessoas que fazem o trajeto diariamente. Talvez as VPNs façam o tráfego passar por endpoints no Canadá. Talvez sua base de usuários more perto da fronteira. Seja qual for a causa, o padrão de falso positivo é real e a sobreposição com fraude é baixa.
Isso lhe dá a base para uma exclusão mais segura: recuse se o país do IP não corresponder ao país da conta, a menos que o país do IP seja o Canadá e o país da conta seja os EUA.
Ou, dependendo da presença da sua empresa e dos recursos disponíveis, talvez você amplie isso para uma lógica de países vizinhos. A questão não é a regra exata. A questão é o método. A exclusão vem da população de falsos positivos e é validada em relação à população de fraude.
É assim que você reduz falsos positivos sem, por engano, criar um novo ponto de entrada para fraudadores. Estou sendo otimista demais ao achar que todo mundo faz essa etapa? Provavelmente.
Teste cada alteração na lógica de fraude antes da implementação
Sempre que você alterar a lógica de prevenção a fraudes, mesmo que seja “apenas” uma exclusão, estará mudando sua postura de risco. Trate isso como uma nova versão de regra.
Os testes em modo sombra e as regras desafiantes são seus melhores aliados aqui. Mantenha a regra atual ativa, mas execute a versão refinada em paralelo. Depois, meça a diferença.
Você quer saber:
- Quantos eventos adicionais a nova versão permitiria?
- Quantos desses eventos acabam se tornando fraude?
- Quantos falsos positivos a alteração evitaria?
- A nova lógica se comporta de forma consistente ao longo do tempo?
Se os resultados se mantiverem, você pode fazer a implantação com mais confiança. Se não se mantiverem, faça ajustes. Não é algo glamoroso. Não é um grande momento dramático de lançamento. É apenas uma operação antifraude melhor.
A janela de monitoramento deve depender de quão rapidamente a fraude amadurece no seu ambiente. Se você tiver tempo, espere o suficiente para comparar os resultados de fraude na versão desafiante com os da versão original. Se estiver sob pressão, revise manualmente amostras aleatórias. Não é perfeito, mas é melhor do que operar às cegas.
Problemas de qualidade de dados podem fazer uma boa lógica parecer ruim
Às vezes, o problema não é a regra. É o dado que alimenta a regra.
Isso é frustrante porque todo mundo quer que a correção esteja na lógica de fraude. Mude a regra, reduza a pontuação, adicione a exceção, coloque em produção. Mas se o campo subjacente estiver corrompido, ausente, inconsistente ou quebrado em um fluxo específico, a regra pode estar se comportando exatamente como foi projetada. A entrada é que está ruim.
Certo. Irritante, mas útil saber.
Se o problema de dados estiver sob seu controle, a melhor solução de longo prazo é corrigir o próprio problema de qualidade dos dados. Isso pode significar reparar o payload de uma API, atualizar a versão de um SDK, corrigir uma integração interna ou trabalhar com as equipes de produto e engenharia para fechar essa lacuna. Isso pode levar dias. Pode levar semanas. Mas, depois que os dados forem corrigidos, a regra de fraude poderá voltar a se comportar corretamente.
Além disso, você pode resolver outros problemas ao mesmo tempo. Problemas de dados raramente estragam apenas uma coisa. Eles geralmente circulam pelo sistema silenciosamente, piorando várias coisas. Muito eficientes, da pior maneira possível.
Quando os dados não puderem ser corrigidos rapidamente, ajuste a lógica
Nem todo problema de qualidade de dados é solucionável no curto prazo. Às vezes ele vem de um parceiro externo. Às vezes vem de uma plataforma que você não controla. Às vezes vem de um sistema que, tecnicamente, você até controla, mas a correção está perdida em algum lugar atrás de 14 prioridades de roadmap e de um time que continua dizendo “no próximo trimestre”. Não pega bem, mas é familiar.
Se você não conseguir corrigir os dados em breve, ajuste a lógica de fraude para esse fluxo. Isso pode significar excluir o fluxo problemático da regra, reduzir o peso da regra, alterar o impacto da regra ou direcionar esses casos para revisão manual.
É aqui que a prevenção à fraude precisa ser pragmática, e não elegante. Um sistema limpo é bom. Um sistema que funciona é melhor. Às vezes, a resposta certa não é a mais teoricamente satisfatória. Às vezes, é aquela que mantém os bons usuários em movimento, ainda assim controlando o risco de fraude.
Conclusão final:
Reduzir falsos positivos não significa tornar o seu sistema mais brando, e sim torná-lo mais preciso.
Isso significa revisar os eventos reais, separar as regras que devem ser removidas daquelas que devem ser rebaixadas ou aprimoradas, criar exclusões com base em evidências, validar essas exclusões em relação a casos de fraude, testar as mudanças em modo sombra e corrigir problemas de qualidade de dados quando a lógica não é realmente o problema.
De qualquer forma, a conclusão um pouco desconfortável é esta: se você está reduzindo falsos positivos sem analisar os casos subjacentes, você não está fazendo ajuste. Você está apenas chutando.
E talvez você tenha sorte. Talvez.
Mas, na prevenção a fraudes, sorte não é exatamente um controle. É mais uma condição temporária.
Conecte-se com Chen Zamir | LinkedIn
Apresentador de The Saturday Fraud Strategist
Ajudando fintechs a construir defesas contra fraudes mais inteligentes
Coautor de “The Fraud Fighter’s AI Playbook”
Ainda não está pronto para encerrar a conversa sobre o meu e, espero, o seu assunto favorito? Assine a newsletter The Saturday Fraud Strategist.
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
