Crie comigo uma regra antifraude de alto desempenho: um exemplo do mundo real

--- title: Crie comigo uma regra antifraude de alto desempenho: um exemplo do mundo real source_page: https://www.sardine.ai/pt/blog/ai-assisted-fraud-rule-writing canonical: https://www.sardine.ai/pt/blog/ai-assisted-fraud-rule-writing format: text/markdown date: 2026-03-12T00:00:00.000Z author: Chen Zamir description: Aprenda a criar regras de fraude resilientes e de alto desempenho usando uma abordagem iterativa e orientada por dados. Este guia aborda detecção de anomalias, redução de falsos positivos, trade-offs entre precisão e recall e como IA e LLMs aceleram a pesquisa moderna de regras de fraude. --- **Quick links:** [Human page](https://www.sardine.ai/pt/blog/ai-assisted-fraud-rule-writing) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/pt/customers) · [Blog](https://www.sardine.ai/pt/blog) · [Demo](https://www.sardine.ai/pt/demo) --- # Crie comigo uma regra antifraude de alto desempenho: um exemplo do mundo real **Author:** Chen Zamir · **Published:** 2026-03-12T00:00:00.000Z · **Categories:** Fraud Aprenda a criar regras de fraude resilientes e de alto desempenho usando uma abordagem iterativa e orientada por dados. Este guia aborda detecção de anomalias, redução de falsos positivos, trade-offs entre precisão e recall e como IA e LLMs aceleram a pesquisa moderna de regras de fraude. Escrever uma regra de fraude é uma tarefa que a maioria dos analistas de dados e especialistas em fraude consegue fazer na primeira semana de trabalho. Escrever uma boa regra de fraude, porém, é um pouco mais complicado. Para entender o porquê, primeiro precisamos definir o que torna uma regra de fraude boa. A resposta é bastante simples: seu desempenho precisa ser eficaz no momento e, ao mesmo tempo, resiliente às mudanças de comportamento dos fraudadores. Neste post do blog, quero compartilhar o processo de análise que segui ao escrever recentemente uma regra de fraude para um grupo de nossos clientes. Espero que isso lhe dê algumas ideias de como estruturar a sua. Antes de começarmos, algumas palavras sobre a metodologia O foco de hoje é a fase de pesquisa de uma nova regra. E, como em qualquer tarefa de pesquisa analítica, minha recomendação é realizá-la em um ambiente SQL em vez de no Excel ou diretamente no seu motor de regras. Claro, sinta-se à vontade para fazer a pesquisa como quiser, mas, pela minha experiência, o exercício será mais eficaz dentro do seu data warehouse. Você é apenas iniciante em SQL? Não se preocupe, é para isso que temos LLMs hoje em dia! Outra coisa que gostaria de destacar é o conjunto de KPIs que me orientam quando estou conduzindo um processo de pesquisa iterativo. Antes de aprovar uma regra para entrar em produção, minha organização segue uma política que define os critérios de sucesso que precisam ser atendidos. Em muitas organizações, isso corresponde a um conjunto de metas, validações e documentações exigidas para liberar uma nova regra. Os critérios finais de sucesso devem orientar o desenho do nosso processo de pesquisa iterativo, incluindo quais KPIs analisar e quais metas estabelecer. Quando estou construindo uma regra, uma condição de cada vez, isso me ajuda a entender se estou tomando as decisões corretas. Embora isso possa variar de caso de uso para caso de uso, há dois KPIs que gosto de acompanhar em todas as etapas do processo: Precisão: quão precisa é a minha regra e, por consequência, quantos falsos positivos são afetados Recall: Quantos dos casos de fraude eu detecto O equilíbrio é bastante direto, mas não é simples. Para cada condição que adiciono à regra, quero ver minha precisão aumentar enquanto meu recall permanece praticamente o mesmo. Por fim, algumas palavras sobre o conjunto de dados com o qual eu estava trabalhando. Quando comecei minha análise, concentrei-me em um segmento específico: eventos de pagamento de qualquer tipo, em um período de tempo específico, de um conjunto específico de clientes. Meu conjunto de dados inicial incluía quase 476 mil registros, dos quais 1.480 foram marcados como fraudulentos. Isso definiu a precisão inicial (ou taxa de fraude) em 0,31%. Eu sempre uso 40% de precisão como meu parâmetro de referência para regras de recusa automática de pagamentos, então, se eu conseguir atingir esse número com uma revocação alta o suficiente, ficarei satisfeito. Como escrever regras de fraude em 3 passos simples: Passei 16 anos na prevenção de fraudes, escrevi centenas de regras e supervisionei sistemas que executaram milhares de regras de prevenção de fraudes. Este é o processo que utilizo para escrever regras de alto desempenho: Encontre uma “anomalia desencadeadora”. Defina o comportamento suspeito central que estamos tentando impedir. Explique a anomalia. Refine a regra para reduzir falsos positivos, excluindo: Explicações da anomalia: comportamentos legítimos que imitam nossa principal suspeita Sinais de confiança: indicadores que caracterizam uma população geralmente de baixo risco Validar e aprovar. Vamos analisar isso. Encontrando a “anomalia incitante” Lá estava eu, explorando o conjunto de dados que descrevi acima, analisando estornos e buscando inspiração. Foi então que percebi: vários casos de fraude em que a geolocalização do IP (especificamente, o estado do IP) não correspondia ao endereço do usuário. Isso me fez pensar. A incompatibilidade geográfica é um sinal de fraude tão clássico, e mesmo assim encontrei vários desses casos. Você esperaria que esse tipo de discrepância fosse facilmente identificado pelo sistema, certo? O motivo, como você provavelmente já imaginou, é que a população de “mismatches aprovados” estava repleta de falsos positivos. De 4.355 casos, apenas 370 foram classificados como fraude. Eu conseguia entender por que essas divergências de “baixo risco” não eram recusadas, mas elas também ofereciam um bom “gancho” para pesquisar uma regra, ou uma “anomalia instigadora”. Um sinal anormal que descreve muitos casos de fraude, mesmo que com baixa precisão. E, de fato, uma precisão de 8,5% significa que ter uma discrepância entre IP e endereço já é 27 vezes mais arriscado do que na população em geral, e isso captura exatamente 25% das fraudes. Senti potencial. Normalmente, qualquer sinal que seja 20 vezes mais arriscado do que a população em geral é um bom ponto de partida para pesquisa de regras. Rascunho de regra IP_state != address_state Desempenho da regra Explicando a anomalia Quando encontro uma anomalia desencadeadora, meu próximo objetivo é aumentar a precisão sem reduzir demais a revocação. O que eu não quero fazer é adicionar mais indicadores suspeitos à minha lógica de regras. Por quê? Porque isso tem uma grande chance de dividir a população de fraudadores em diferentes quadrilhas de fraude. Isso não apenas reduziria a abrangência, como também tornaria a regra muito específica. E lembre-se, regras específicas são fáceis de contornar. Em vez disso, quero descrever como é o comportamento de um cliente confiável para poder excluí‑lo da lógica da regra. Parece apenas uma questão de semântica, mas você logo vai perceber que a parte essencial na criação de regras é formular falsos positivos, não encontrar indicadores suspeitos. Existem duas maneiras de identificar padrões de falsos positivos que podemos excluir: explicações de anomalias e sinais de confiança. Explicações de anomalias Uma explicação de anomalia é qualquer sinal que não seja necessariamente de baixo risco por si só, mas que possa “resolver” a anomalia. Basicamente, ela mostra por que um bom usuário apresentaria esse comportamento. Por exemplo, sempre que lido com anomalias envolvendo IPs, a minha explicação padrão é o próprio tipo de IP. Se for um IP altamente controlado (.gov, .mil, .edu), isso pode explicar por que há uma discrepância geográfica entre ele e o endereço do usuário. Isso acontece em parte porque pode indicar viagens frequentes, mas, mais importante, muitas vezes aponta para o uso de VPNs internas. Claro, usar um IP altamente controlado é, em geral, seguro mesmo fora da nossa anomalia específica. Mas isso tem um preço: eles não são tão comuns. E foi exatamente esse o caso aqui também. Rascunho de regra IP_state != address_state E IP_connection_type EM (“mil | gov | edu | org | corp”) Desempenho da regra Só conseguimos reduzir um punhado de falsos positivos, mas o desempenho é praticamente o mesmo. Em seguida, eu quis analisar mais de perto os sinais de proxy de IP. Ficou claro que muitos dos incidentes de fraude surgiam quando a probabilidade de uso de IP proxy era média ou alta. Isso faz sentido, pois fraudadores muitas vezes usam de forma descuidada IPs de proxy que ficam bem longe do endereço da vítima, desde que estejam no mesmo país. Então eu foquei nos eventos em que a probabilidade de uso de proxy era baixa e notei que os tipos de conexão de ISP eram muito mais seguros do que as conexões móveis/híbridas. Isso também fazia sentido: fraudadores são menos propensos a usar faixas de IP estáveis que possam expô-los. Com isso, adicionei uma condição em que excluí os casos em que a probabilidade de proxy é “baixa” e o tipo de conexão é ISP. Rascunho de regra IP_state != address_state E IP_connection_type EM (“mil | gov | edu | org | corp”) E (IP_proxy == “low” E IP_connection_type == “ISP”) Desempenho da regra Parece bem bom, né? Talvez, mas eu não fiquei satisfeito com a quantidade de casos de fraude que “perdemos” aqui. Mesmo tendo reduzido muitos falsos positivos, eu estava confiante de que uma análise mais aprofundada me ajudaria a manter os caras maus dentro do radar. Aqui está um pequeno vídeo que gravei e que mostra como eu geralmente faço isso: Você pode me ver analisando os 1.484 casos que a última exclusão removeu da minha população de regras. A primeira coisa que faço é ordenar os resultados com os casos de fraude no topo, para que eu possa identificar padrões com facilidade. Em seguida, verifico rapidamente quantos casos de fraude vejo no total (os 46 excluídos) e, por fim, tento identificar como diferenciar a população ruim da boa. Neste caso (e obviamente percebi isso antes de gravar o vídeo), notei que todos os casos ruins não tinham um endereço de e-mail verificado. Rapidamente incluí isso na lógica das minhas regras. Rascunho de regra IP_state != address_state E IP_connection_type EM (“mil | gov | edu | org | corp”) E (IP_proxy == “low” E IP_connection_type == “ISP” E cust_email_verified == TRUE) Desempenho da regra (ignorando a última versão) Observe que, embora minha precisão seja a mesma e eu não tenha excluído tantos falsos positivos, o recall melhorou bastante. Essa é uma versão de regra muito melhor. Sinais de confiança A essa altura, passei várias horas a mais tentando descobrir se conseguia encontrar outras boas explicações para o motivo de o IP e o endereço não coincidirem. Como não encontrei mais nada, parti para a minha segunda tática: identificar sinais gerais de confiança. Aqui, a ideia não é explicar por que essa anomalia faz sentido, mas sim reduzir a população, excluindo dela os segmentos gerais de baixo risco. O sinal de verificação de e-mail que usamos acima é um exemplo perfeito. Dentro do contexto deste conjunto de dados, ele não era particularmente forte por si só, até o combinarmos com a condição de tipo de IP. Por outro lado, ter um telefone verificado mostrou ser um sinal suficientemente robusto por si só, então o incluí como minha próxima camada. Rascunho de regra IP_state != address_state E IP_connection_type EM (“mil | gov | edu | org | corp”) E (IP_proxy == “low” E IP_connection_type == “ISP” E cust_email_verified == TRUE) E cust_phone_verified == TRUE Desempenho da regra Por fim, notei que muitos bons clientes capturados pela minha versão da regra usavam e-mails corporativos. Portanto, optei por manter apenas domínios de e-mail “gratuitos” no meu conjunto de dados. Isso não é necessariamente um forte indicador por si só (golpistas podem roubar seu e‑mail sem problema), mas pode explicar mais histórias de viagem ou uso de VPN que não conseguimos identificar diretamente. Rascunho de regra IP_state != address_state E IP_connection_type EM (“mil | gov | edu | org | corp”) E (IP_proxy == “low” E IP_connection_type == “ISP” E cust_email_verified == TRUE) E cust_phone_verified == TRUE E email_domain_type == "free" Desempenho da regra Como você pode ver, embora nossa revocação tenha caído em quase um quinto, também dobramos nossa precisão a um ponto em que, com alguns ajustes, a regra pode ser liberada para produção. Preparando a regra para o lançamento Depois que definirmos a lógica da regra, restarão duas etapas antes de podermos colocá-la em produção. A primeira é aprovar o desempenho geral da regra e o impacto esperado nos negócios. Para fornecer uma visão completa do desempenho quando eu o enviar para aprovação, compartilharei o seguinte: Isso deve fornecer ao gerente aprovador tudo de que ele precisa para aprovar meu pedido com confiança. Mas a aprovação é apenas metade da batalha. A segunda coisa que precisamos fazer é concluir todo o processo de validação da regra. A boa notícia? Acabamos de concluir a primeira etapa (de seis)!