Como medir falsos positivos em sistemas de fraude que os ocultam

Chen Zamir
Chen Zamir
bg-image
bg-image
Como medir falsos positivos em sistemas de fraude que os ocultam
Subscribe to newsletter
Share

Nesta série de artigos, Chen Zamir enfrenta um problema de fraude (quase) existencial: como reduzir falsos positivos. Na parte 1, ele apresenta cinco maneiras práticas pelas quais as equipes de fraude quantificam recusas indevidas quando os dados não fornecem respostas espontaneamente.

Todos concordam que falsos positivos são ruins, mas quase ninguém consegue quantificá-los.

Pergunte a um líder de fraude qual foi o número de chargebacks do mês passado e você receberá um valor preciso. Pergunte quantos bons clientes foram bloqueados por engano e você receberá um encolher de ombros ou, pior, ‘Nenhum’.

Não é porque as pessoas não se importam. É porque a forma como construímos sistemas de fraude torna os falsos positivos invisíveis por definição.

Se você aprovar uma transação, o mundo lhe dará um retorno. Se tiver sido fraude, você ficará sabendo. Se tiver sido uma boa transação, verá o cliente voltar, gastar mais, fazer login novamente, fazer as coisas normais de um cliente.

Mas se você bloquear alguma coisa, esse sinal desaparece.

No melhor dos casos: um cliente reclama. Mas mesmo assim, essa reclamação raramente volta para os seus dados. Ela geralmente morre isolada, enterrada em um tíquete de suporte, presa em uma caixa de entrada ou se apagando na memória de uma ligação telefônica irritada.

Quase nunca se torna um rótulo estruturado associado a um evento específico, do tipo que alimenta seus pipelines de treinamento de modelos ou impulsiona seus painéis.

Então, antes de falarmos sobre reduzir falsos positivos, precisamos falar sobre rotulá-los .

A Parte 1 desta série aborda este paradoxo: como medir um erro que o sistema foi projetado para ocultar?

Não existe solução mágica. Medir falsos positivos é sempre um exercício de triangulação. Você precisa combinar vários métodos imperfeitos até que o sinal forme uma imagem nítida o suficiente para a tomada de decisões.

Vamos direto ao assunto.

5 maneiras de medir falsos positivos em sistemas de fraude

O quê

Como

Simulação

Teste retroativamente as regras em dados históricos para identificar recusas falsas.

Revisão manual

Audite transações recusadas para identificar erros.

Vinculação comportamental

Acompanhar usuários bloqueados que retornam com boa atividade

Grupos de controlo

Permita a passagem de um grupo de teste para medir o que você está perdendo

Feedback do usuário

Entrevistar usuários sobre transações recusadas

Método 1 - Simulando suas regras e fluxos de trabalho

As equipes naturalmente tendem à simulação porque é fácil: você simplesmente faz backtests da sua lógica usando dados históricos.

Pegue uma regra, ou um conjunto de regras, ou um fluxo de trabalho, e execute isso sobre os últimos 6 meses de tráfego. Observe todos os eventos que ela teria recusado e depois faça a correlação com o status final deles (fraude ou legítimo).

É fundamental não deixar de levar em conta a maturação da fraude. Como os chargebacks levam tempo para se concretizar, os dados mais recentes acabam ficando, na prática, “sem rótulo”. Um intervalo de 30 dias é o mínimo; uma janela de 90 dias garante que seus usuários “limpos” sejam realmente limpos.

Qualquer transação rotulada como 'limpa' que a sua regra teria bloqueado é um Falso Positivo teórico.

O atrativo aqui é a acessibilidade: você pode executar isso em SQL ou na sua plataforma de fraude sem precisar implantar nenhuma infraestrutura nova.

Mas a simulação vem com limitações importantes. Você está testando uma única regra de forma isolada, mas em produção essa regra faz parte de uma complexa “pilha de decisões”, com diferentes regras, limiares de modelos, agentes de IA, revisões manuais, decisões de terceiros e assim por diante.

Na prática, uma regra não funciona sozinha. Ela pode ser antecipada por um bloqueio anterior ou anulada por uma revisão manual. A sua simulação parte do princípio de que a sua regra é a autoridade final; em produção, ela costuma ser apenas uma voz em um coro.

Você também não consegue fazer backtest do atrito operacional. A simulação parte do pressuposto de uma execução de código perfeita, mas deixa passar bugs, problemas de integração ou o comportamento de agentes a montante, como emissores e processadores. Tudo isso pode gerar falsos positivos, e nada disso é capturado em um simples exercício de “Se esta regra estivesse ativa, o que ela teria feito?”.

Então sim, faça simulações. É um bom começo. Só não confunda “Esta regra tem uma baixa taxa de falsos positivos” com “Isto é o quadro completo.”

Método 2 - Revisão manual de eventos recusados

O segundo método é mais antigo, mais lento e muito mais poderoso: você analisa manualmente o tráfego recusado.

Em vez de analisar a lógica, você olha diretamente para o impacto. Você pega uma amostra de eventos bloqueados, seja de forma geral ou para uma solução específica, e pede a um investigador de fraude experiente que os classifique manualmente.

Este é essencialmente o mesmo processo que você usa para criar novas regras ou buscar novos padrões de fraude, apenas aplicado ao contrário.

As limitações são óbvias: não é escalável, consome muito tempo e é caro do ponto de vista operacional. Você também precisa de analistas altamente especializados e, mesmo assim, uma porcentagem dos eventos continuará sendo casos inconclusivos de “zona cinzenta”.

Por outro lado, como esta é uma auditoria offline e não uma decisão em tempo real, a precisão específica de cada caso importa menos. Você também não precisa rotular tudo.

Tudo o que você precisa é ter uma noção de onde você está e onde estão os piores infratores. Afinal, não faz muita diferença concluir que uma regra tem uma precisão de 45% ou de 48%.

Também é possível combinar os dois primeiros métodos. Isso é especialmente útil ao lidar com um novo padrão de fraude que você quer bloquear e não pode se dar ao luxo de esperar que ele “amadureça”. Basta executar a lógica sobre o último mês e depois revisar uma amostra dos resultados para avaliar o desempenho.

Método 3 - Vinculando recusas a comportamentos positivos posteriores

O terceiro método é aquele que considero o mais subestimado: Vinculação.

A ideia é simples: em muitos casos, bons usuários aparecem várias vezes na sua plataforma antes, ou até depois, de serem bloqueados. Eles podem tentar novamente com um cartão diferente. Podem refazer o onboarding com um endereço de e-mail diferente. Podem voltar a transacionar a partir do mesmo dispositivo, com um endereço IP que você não considera arriscado.

Se você conseguir vincular esses eventos e ver a sequência completa, de repente terá um sinal extremamente forte de que a recusa original foi um falso positivo.

Essa conexão pode ser simples:

  • Mesmo ID de usuário, cartão diferente.
  • Mesmo dispositivo, e-mail diferente.
  • Mesmo IP+Nome, dispositivo diferente.

Ou pode ser mais probabilístico (mais incerto), como um usuário bloqueado, seguido pelo registro bem-sucedido do seu cônjuge na mesma residência.

Depois que você tiver a infraestrutura básica em funcionamento, o método escala de forma excelente. Você simplesmente analisa periodicamente a sua população bloqueada e tenta associá-la a eventos positivos que aconteceram antes ou depois.

O problema é que você precisa dessa infraestrutura. Você precisa pesquisar uma heurística que tenha um bom desempenho. Você precisa de algum tipo de resolução de entidades. Você precisa ser capaz de extrair sequências de eventos ao longo do tempo. Isso é um trabalho nada trivial.

Mas o retorno sobre o investimento é enorme. Você gera um fluxo contínuo de rótulos de falsos positivos de alta precisão. Isso não vai detectar todos os falsos positivos, mas aqueles que detectar serão muito confiáveis.

Método 4 - Grupos de controle: Deixar passar algumas fraudes de propósito

O quarto método é aquele com o qual todos se sentem um pouco desconfortáveis: grupos de controle.

Você pega uma amostra aleatória do tráfego, normalmente 1%, e a coloca totalmente na lista de permissões.

Sem regras. Sem recusas baseadas em modelos. Sem revisão manual. Essa população passa diretamente para o que quer que seja a próxima etapa: processamento de pagamento, criação de conta, acesso a recursos.

Então você simplesmente observa o que acontece.

Se o seu sistema geral tiver um bom desempenho, você verá uma quantidade significativa de fraude nesse grupo de controle. Por outro lado, se você notar que a taxa de falsos positivos do grupo de controle é muito maior do que o esperado, então saberá que precisa reexaminar a sua configuração.

Grupos de controle são poderosos porque respondem a uma pergunta muito direta: “O que aconteceria se removêssemos completamente o sistema para alguns usuários?” A resposta geralmente não é bonita de se ver, mas é honesta.

Essa abordagem, porém, só é prática em grande escala. Você precisa de tráfego suficiente para que um ou dois por cento ainda forneçam números estatisticamente significativos em um prazo que faça sentido.

Você também precisa de orçamento para absorver o prejuízo. Para uma fintech pequena, com margens apertadas e volume limitado, isso pode não ser viável. Para empresas maiores, é uma das poucas ferramentas que oferece uma medição realmente imparcial.

Método 5 - Perguntar ao usuário

O quinto método, solicitar feedback direto do usuário, é uma tática mais oportunista, disponível apenas em contextos específicos. Se você estiver analisando transações recusadas em contas que você já conhece e em que confia, pode disparar uma notificação fora de banda: “Bloqueamos uma transação terminada em 1234. Foi você?”

Se o usuário estiver logado e autenticado, uma mensagem no aplicativo ou um e-mail pode perguntar explicitamente se um determinado bloqueio foi legítimo.

Mas isso não é algo que você possa fazer de forma generalizada. É inútil na etapa de onboarding quando você nunca viu o usuário antes; perguntar a um desconhecido se ele é um fraudador não gera dados úteis.

Além disso, e não posso enfatizar isso o suficiente, não dê aos fraudadores uma forma de marcar as próprias tentativas como “boas”. Se um botão “Sim, fui eu” remover automaticamente o bloqueio, você não criou um ciclo de feedback, você criou uma porta dos fundos para que os fraudadores se coloquem na lista de permissões.

Mas, como uma fonte adicional de verdade factual em situações muito específicas, como tentativas de login fracassadas ou alteração de dados de contato, isso pode ser surpreendentemente útil.

Não existe um único método mágico

Se a sua conclusão for ‘Nenhuma dessas opções é perfeita’, você está certo. Essa é a natureza da coisa.

Você não está procurando um único indicador mágico que lhe diga o número exato de falsos positivos no seu sistema. Você está buscando combinar vários indicadores independentes para construir tanto precisão quanto escalabilidade.

Na prática, a maioria das equipes acaba com alguma combinação de:

  • Simulação para verificações rápidas de bom senso, regra por regra.
  • Revisão manual para fluxos de alto valor e principais infratores.
  • Vinculação como o principal pipeline contínuo de medição após a conclusão do trabalho de engenharia.
  • Grupos de controle para grandes populações em que é possível tolerar alguma perda controlada.
  • Feedback de usuários em contextos restritos e cuidadosamente selecionados.

Se você combinar esses elementos corretamente, terá uma estimativa utilizável dos seus falsos positivos, detalhada em pelo menos algumas dimensões importantes: fluxo de produto, tipo de tráfego, camada de decisão e assim por diante.

E, uma vez que você consiga medir o problema, finalmente poderá fazer a pergunta certa.

De “Quantos?” para “De onde?”

Uma coisa é saber que você tem um problema de falso positivo. Outra é saber de onde ele vem.

São principalmente as suas regras? O limite do seu modelo? Os seus revisores humanos? Uma integração específica que corrompe endereços IP em dispositivos móveis? Um processador de pagamentos de terceiros que é extremamente agressivo em determinada região?

Na segunda parte desta série, vamos pegar os falsos positivos que você conseguiu detectar e agrupá-los pela causa raiz. Vamos analisar:

  • Quanto do seu problema de falsos positivos está realmente sob seu controle.
  • Quanto vem de fluxos e plataformas específicos.
  • Quanto é impulsionado por problemas de qualidade de dados que não têm nada a ver com fraude.
  • E, mais importante: como saber quais problemas valem a pena corrigir e quais são aqueles com os quais você simplesmente terá que conviver.

Zero falsos positivos é um mito. Mas você ainda pode chegar a um ponto em que cada falso positivo restante é ou conscientemente aceito ou está fora da sua esfera de influência.

E essa clareza por si só já vale muito.

Vejo vocês todos na parte 2.