Quando as pessoas falam sobre reduzir falsos positivos, geralmente vão direto para as táticas: ajustar regras, calibrar limites, adicionar exceções, relaxar o modelo, direcionar casos de borda para revisão manual e assim por diante. Tudo isso faz parte do trabalho, mas nada disso deveria ser o ponto de partida.
Se você chegou até aqui na série (confira a parte 1 e a parte 2 aqui), você já fez as duas partes do trabalho que a maioria das equipes ignora:
- Você criou uma medição razoavelmente precisa dos seus falsos positivos, mesmo que o seu sistema os oculte por padrão.
- Você categorizou esses falsos positivos em grupos: por agente, por soluções, por fluxo, por qualidade dos dados e pelo que está ou não sob seu controle.
Essa é a base. Agora você está pronto para encarar o prato principal: corrigir as partes do sistema que estão se comportando mal.
Mas é aqui que devemos encarar o trabalho com disciplina. Caso contrário, você acabará fazendo mudanças que não importam, deixando de lado mudanças que teriam feito diferença ou, pior ainda, abrindo espaço para fraudes adicionais sem perceber.
Este blog se concentra nas correções que atuam dentro do seu sistema de fraude.
Revise seus principais infratores por meio de análise manual
Uma das melhores maneiras de se orientar antes de fazer qualquer mudança é voltar à revisão manual. Escolha a regra, o limite do modelo ou o agente de IA que é acionado com mais frequência e inspecione manualmente uma amostra dos eventos que ele bloqueou (entre 50 e 100 geralmente é suficiente na maioria dos casos).
O que você está tentando responder geralmente são perguntas bem básicas:
- Essa regra é realmente tão imprecisa quanto pensamos?
- Ainda queremos que essa regra exista?
- Se ele existir, ainda deve tomar decisões automatizadas ou deve servir apenas como insumo para uma revisão manual?
- Se ele continuar automatizado, o que seria necessário para reduzir seus falsos positivos sem aumentar de forma significativa nossas perdas por fraude?
Cada uma dessas perguntas é específica para o negócio. Não existe um limite universal para o que é considerado “bom o suficiente”.
Às vezes, sua equipe de FraudOps pode assumir as revisões manuais adicionais. Em outros casos, você não tem nenhuma revisão manual como parte do seu processo.
E às vezes uma regra precisa continuar automatizada, mesmo que seja barulhenta, porque você simplesmente não pode se dar ao luxo de revisar manualmente todo esse volume.
Mas você precisa de clareza antes de mudar qualquer coisa. O pior cenário é achar que uma regra está boa porque ela “parece lógica”, só para descobrir, durante uma revisão manual, que ela está bloqueando um volume esmagador de tráfego legítimo.
Você não consegue resolver essas situações só com raciocínio. Você precisa olhar.
Mais importante ainda, isso não é apenas sobre validar que você está resolvendo um problema real. É sobre mostrar como fazer isso.
Três caminhos de decisão para cada regra ou modelo de fraude com mau funcionamento
Depois de analisar as evidências, quase toda solução com mau desempenho se encaixa em uma de três categorias:
1. A regra de fraude não deveria existir de forma alguma.
Isso acontece com mais frequência do que as equipes admitem.
Você tem lógica no seu sistema que:
- Captura uma pequena parcela da população
- Não bloqueia muita fraude
- Gera uma quantidade desproporcional de falsos positivos
- Existe principalmente porque alguém o adicionou durante uma crise e ninguém o revisitou
Remover essas regras é desconfortável nas primeiras vezes que você faz isso. Mas, se a fraude que elas detectam é insignificante e os falsos positivos são significativos, desativá-las é uma das maneiras mais limpas e seguras de melhorar o seu sistema.
Este é o seu ganho fácil.
2. A regra de fraude deve existir, mas não deve mais tomar decisões automatizadas.
Isso é comum com lógicas de precisão média que ainda identificam fraudes relevantes, mas não com confiabilidade suficiente para bloquear sem revisão humana.
Se você tiver capacidade para revisão manual e se essa lógica em particular tende a gerar eventos que seus analistas se sentem à vontade para avaliar, então encaminhá-la para o gerenciamento de casos em vez de recusar automaticamente pode ser o compromisso perfeito.
Você mantém a cobertura contra fraude, reduz falsos positivos e coloca uma pessoa no processo, capaz de observar mudanças de desempenho em tempo real.
O custo, é claro, é operacional. Isso só funciona quando você tem uma visão clara da precisão dos seus analistas e da capacidade da sua fila.
3. A regra de fraude deve existir e permanecer automatizada, mas sua lógica precisa ser aprimorada.
Este é o cenário mais interessante. Também é o mais comum.
A lógica identifica fraudes reais. Ela é necessária. É eficaz. Mas também está atingindo um número significativo de usuários legítimos.
Então você precisa refiná-la. A questão é como.
Caminho 1: Remover a regra | Caminho 2: Redirecionar para revisão manual | Caminho 3: Refinar a lógica | |
Quando usar | Baixa detecção de fraude, muitos falsos positivos; lógica legada ou criada em época de crise que ninguém revisitou | Regra de precisão média que identifica fraudes relevantes, mas não é confiável o suficiente para recusar automaticamente | Alta detecção de fraude e regra necessária, mas que também acaba pegando um número significativo de usuários legítimos |
Pré-requisito | Confirmado impacto insignificante de fraude por meio de revisão manual | Capacidade disponível de analistas e largura de banda clara da fila | Separação clara entre padrões de fraude e de falsos positivos (validada por meio do método de "imagem espelhada") |
Ação | Desativar completamente a regra | Redirecionar eventos sinalizados para o gerenciamento de casos em vez de recusar automaticamente | Criar exclusões derivadas da população de falsos positivos, validadas em relação à população de fraude |
Risco | Mínimo, se o volume de fraude for realmente baixo | Custo operacional; depende da precisão do analista e da capacidade da fila | A exclusão pode permitir fraudes se não for devidamente validada |
Validação | Monitorar as taxas de fraude após a remoção | Acompanhe a precisão das decisões dos analistas e a carga da fila ao longo do tempo | Modo sombra / teste de regras desafiadoras antes da implantação completa |
A “imagem espelhada” da detecção de fraude: como criar exclusões corretamente
O processo de aprimorar uma regra com muitos falsos positivos é quase idêntico à forma como você cria uma nova regra de fraude, apenas ao contrário.
Pense nisso. Quando você cria uma regra de fraude, você:
- Analise um conjunto de casos de fraude confirmados.
- Identifique o padrão que eles compartilham.
- Compare esse padrão de fraude com a população geral de bons clientes.
- Crie uma lógica que identifique a fraude sem acabar incluindo eventos legítimos em excesso.
Para reduzir falsos positivos, você faz a mesma coisa, mas com o objetivo oposto em mente. Você:
- Analise um conjunto de casos confirmados como falsos positivos.
- Identifique seus padrões recorrentes.
- Compare esses padrões com os casos de fraude para garantir que a separação seja real.
- Crie exclusões ou refinamentos que capturem essa separação sem “liberar” fraude em excesso.
Esta última etapa é crucial. Não basta dizer: “Muitos falsos positivos têm a característica X.” Você precisa provar que seus casos de fraude não apresentam essa mesma característica. Caso contrário, sua exclusão vai prejudicar a detecção de fraude.
A beleza disso? Se você seguiu todas as etapas sem pular nenhuma, você já fez essa revisão manual enquanto validava as métricas de falsos positivos.
Vamos ver um exemplo. Suponha que você tenha uma regra de incompatibilidade bem padrão:
“Recuse se o país do IP não corresponder ao país da conta.”
Isso é comum e muitas vezes gera ruído. Agora imagine que você analisa manualmente uma amostra de 100 eventos que essa regra bloqueou. Depois de classificá-los, você percebe:
- 30 eram fraude
- 70 eram legítimos
- E, desses 70 eventos legítimos, 20 envolveram usuários dos EUA cujos endereços IP foram resolvidos para o Canadá
20 de 70 é um padrão significativo.
Talvez sua empresa tenha um grande número de pessoas que fazem o trajeto diário entre os EUA e o Canadá. Talvez VPNs para endpoints canadenses sejam comuns. Talvez parte da sua base de usuários trabalhe perto da fronteira. Por qualquer motivo, esse descompasso específico (conta dos EUA → IP canadense) parece gerar muitos falsos positivos.
Se, nos seus casos de fraude, você observar pouca ou nenhuma fraude vindo desse mesmo padrão EUA → Canadá, então você tem uma separação clara. Isso significa que pode introduzir com segurança uma exclusão:
“Recusar se (o país do IP não corresponder ao país da conta) E NÃO (o país do IP corresponder a CA e o país da conta corresponder aos EUA)”
Ou melhor ainda, amplie um pouco para incluir uma lógica de países vizinhos, dependendo da presença da sua empresa e dos recursos disponíveis.
A questão é que a exclusão é derivada da análise da sua população de falsos positivos e é validada em relação à sua população de fraudes.
É assim que você aprimora as regras sem abrir brechas perigosas.
Teste as alterações na lógica antes de as lançar
Sempre que você altera a lógica de fraude, mesmo que seja apenas uma exclusão em uma regra existente, você está mudando sua postura de risco. Isso é igual a quando você lança uma nova regra completamente do zero.
Então, antes de lançar a nova versão, teste-a.
Modo sombra e regras desafiantes são suas aliadas. Mantenha a regra existente ativa, mas execute sua regra refinada em paralelo por alguns dias. Meça as diferenças:
- Quantos eventos adicionais isso teria permitido?
- Quantos desses eventos evoluíram para fraude?
- Quantos falsos positivos isso teria evitado?
Se os resultados se mantiverem ao longo do tempo, você poderá implementar com confiança. Caso contrário, faça ajustes.
Por quanto tempo você deve monitorar essas mudanças?
Idealmente, tempo suficiente para obter uma boa noção de quão rápido a fraude amadurece na nova versão e se isso está ou não em linha com a versão original. Se você estiver realmente com pouco tempo, talvez queira considerar revisar manualmente amostras aleatórias.
Ao lidar com problemas de dados
Como exploramos em a parte 2 desta série, às vezes a causa raiz dos falsos positivos não é uma lógica falha, mas sim dados corrompidos.
No melhor cenário, você já o identificou na sua análise preliminar. No pior cenário, você passou por todas as etapas apenas para descobrir isso na sua revisão manual detalhada.
Quando essa é a causa raiz identificada, você tem duas opções, dependendo se o problema de dados é solucionável no curto prazo.
Opção 1 - Corrigir o próprio problema de qualidade dos dados
Se o campo corrompido estiver sob o seu controle, seja no seu SDK, na sua integração interna ou na sua infraestrutura, a melhor solução a longo prazo é corrigir os dados.
Isso pode significar corrigir um payload de API, ajustar a versão de um SDK ou trabalhar com uma equipe de produto para tapar uma brecha.
Isso pode levar alguns dias ou algumas semanas, dependendo da sua organização. Mas, uma vez que os dados sejam corrigidos, a regra geralmente voltará a se comportar corretamente.
Além disso, é provável que você também tenha resolvido uma série de problemas que estavam afetando outros departamentos ao mesmo tempo.
Opção 2 - Ajustar a lógica de fraude para esse fluxo
Nem todos os problemas de dados podem ser resolvidos internamente. Às vezes, eles têm origem em partes externas que você simplesmente não consegue controlar. Ou, nos casos mais frustrantes, você até controla esses problemas, mas não há solução à vista.
Se você não conseguir corrigir os dados subjacentes em breve, talvez precise ajustar sua lógica de fraude especificamente para esse fluxo. Mais uma vez, você pode considerar algumas alternativas:
- Excluir completamente o fluxo problemático da regra.
- Reduza o peso da regra ou altere o seu impacto.
- Mover esses casos para revisão manual.
A prevenção de fraude é mais pragmática do que elegante e, às vezes, não se trata de estar certo, mas de ser inteligente.
O que você deve ter ao final da parte 3
Nesta etapa, você deve ser capaz de:
- Identifique os principais fatores que geram o maior volume de falsos positivos.
- Analise se cada um deve ser removido, redirecionado ou aprimorado.
- Aplique o método de “imagem espelhada” para criar exclusões eficazes e seguras.
- Distinguir entre mau comportamento genuíno e problemas de qualidade de dados.
- Valide cada alteração em modo sombra antes de lançá-la.
Este é o núcleo tático da redução de falsos positivos: lidar com os atores específicos dentro do seu sistema.
Mas ainda há mais uma camada que não abordamos, uma camada arquitetural que opera acima de regras, modelos, agentes e até da revisão manual.
É essa camada que nos leva à parte 4. Vejo você lá.
