Este é o segundo artigo da nossa série Fraud Ops 2026, em que exploramos as práticas que ajudam as equipes de fraude a operar com mais precisão, confiança e agilidade. Se você perdeu o primeiro artigo, confira aqui para conhecer 5 maneiras criativas de as equipes de fraude usarem IA hoje mesmo.
Lançar novas regras de prevenção a fraudes pode ser uma faca de dois gumes.
Todo profissional de combate à fraude que já colocou uma nova regra em produção conhece essa sensação: esperar pelos primeiros alertas aparecendo na tela, enquanto teme a possibilidade de que um pequeno erro possa prejudicar seriamente o desempenho do negócio.
Por mais que precisemos de regras antifraude para combater fraudes, a dura verdade é que qualquer mudança no sistema (grande ou pequena) representa uma oportunidade de introduzir um erro.
Todo líder de prevenção a fraudes que eu conheço, incluindo a mim mesmo, tem sua cota de histórias de terror para contar. Mas não precisa ser assim. Com um processo de validação adequado, sua equipe pode reduzir o risco ao liberar novas regras.
Veja como criar um processo seguro e confiável de liberação de regras de fraude que sua equipe possa implementar com confiança.
Como estruturar o processo de lançamento das suas regras de fraude
Um processo de liberação de regras de fraude é projetado para garantir que as novas regras atinjam o público certo quando entrarem em vigor.
Esteja você tentando sinalizar comportamentos suspeitos para revisão ou bloquear esses eventos de forma definitiva, o objetivo é a precisão. Quando uma regra é liberada de forma inadequada, você pode enfrentar dois problemas:
- A regra não atinge a população mal-intencionada e gera falsos positivos
- A regra afeta um número desproporcional de usuários legítimos
Embora o primeiro possa ser difícil de identificar, o segundo traz um risco operacional e para o cliente muito maior. Em operações de combate à fraude no mundo real, os maiores pontos de dor costumam ser falsos positivos, bloqueio de usuários legítimos, interrupções no negócio e a carga de revisões manuais que acompanha uma liberação mal-sucedida. Um processo bem estruturado de liberação de regras pode praticamente eliminar completamente ambos os cenários.
Na minha experiência, a maneira mais segura de implementar regras antifraude é tratar a liberação como um processo, não como um evento. Eu recomendo um processo em seis etapas, descrito na tabela abaixo.
Etapa | Backtest offline | Backtest online | Revisão especializada | Validação em tempo real | Revisão em tempo real | Monitoramento de longo prazo |
O quê | Estabelecer desempenho de referência | Descartar erros técnicos | Cumprir o princípio dos 4 olhos | Confirmar que as ocorrências da regra estão dentro da previsão | Confirmar se a precisão está dentro da previsão | Configurar monitoramento de longo prazo |
Onde | Armazém de dados | Mecanismo de regras | Mecanismo de regras | Mecanismo de regras | Gestão de casos | Mecanismo de regras |
Como | Simular com dados históricos | Validar se a sintaxe da regra corresponde ao rascunho SQL | Rever configuração de regra | Monitoramento em “modo sombra” | Revisar acertos do “modo sombra” | Definir limites de segurança |
Modo Sombra | Entrada em Produção |
Etapa 1 - Backtesting offline para detecção de fraude
Uma nova regra começa com um pequeno projeto de pesquisa, em que o especialista em combate à fraude itera sobre o padrão que deseja capturar nos dados históricos. Esse trabalho normalmente é feito no seu data warehouse interno de nível de qualidade aceitável (AQL), onde o objetivo é medir como a regra teria se comportado em relação aos principais indicadores caso estivesse ativa no passado. A cada iteração, o analista melhora o desempenho geral da sua lógica até ficar satisfeito com o resultado.
Naturalmente, isso levanta a questão do que “satisfeito” significa nesse contexto. A última coisa que você quer é uma situação em que cada membro da equipe tenha seu próprio padrão de qualidade. Por esse motivo, é fundamental que as equipes de fraude tenham uma política predefinida que determine quais critérios de sucesso as novas regras precisam atender para serem consideradas “aptas para produção”.
Esses critérios de sucesso, expressos como limites de métricas, variam não apenas entre organizações, mas também de acordo com o objetivo da regra.
Uma regra que bloqueia eventos automaticamente precisa ser mais precisa do que uma regra que sinaliza casos para revisão manual.
Uma regra que substitui bloqueios para evitar falsos positivos seria otimizada com base em métricas diferentes das de uma regra de redução de fraude “comum”.
Independentemente do objetivo, os critérios de sucesso devem apoiar uma visão holística do impacto da regra.
Recomenda-se que as equipes não avaliem a precisão na detecção de fraude de forma isolada. Elas também devem levar em conta falsos positivos, fricção para o cliente e se a regra melhora o desempenho geral do negócio depois de entrar em produção.
Etapa 2 - Backtesting online
Quando o especialista em combate à fraude estiver satisfeito com sua lógica SQL, ele precisará agora “traduzir” essa sintaxe para os limites de seu motor de regras. Às vezes é um exercício simples (por exemplo, amount > $100 AND risk_score > 80), mas em outras ocasiões isso pode ficar bem complicado.
Um desafio comum é que os recursos disponíveis no mecanismo de regras muitas vezes exigem uma lógica de regex estranha ou improvisada para serem reproduzidos no data warehouse local.
Outro desafio é que recursos como contadores de velocidade são difíceis de reproduzir, especialmente em um ponto específico no tempo, usando SQL.
Independentemente do motivo, o simples fato de você estar transplantando código de um sistema para outro já é uma grande vulnerabilidade. Para validar que a regra se comporta como esperado, assim como a consulta SQL se comportava, você também vai querer fazer um backtest da regra dentro do próprio mecanismo de regras. Idealmente, você a executaria sobre a mesma população e no mesmo período de tempo usados na sua população de backtest em SQL. Depois, tudo o que você precisa fazer é comparar as listas de eventos marcados e garantir que sejam iguais nas duas versões.
Etapa 3 - Revisão por especialista
A implementação do princípio dos “quatro olhos” para alterações no sistema pode já ser um requisito formal na sua organização. Mesmo que não seja, a introdução desse ponto de verificação é fortemente recomendada: regras de fraude podem causar estragos em sistemas de produção e, na maioria dos casos, as falhas decorrem de simples erro humano.
Como última salvaguarda antes de entrar em produção, certifique-se de que um especialista experiente revise e aprove a nova regra. Mesmo que sua equipe tenha níveis de experiência semelhantes, uma revisão estruturada por pares ainda pode reduzir significativamente o risco de erros.
A função do revisor é garantir que as melhores práticas sejam seguidas, incluindo:
- Os testes retrospectivos mostram um bom desempenho
- A documentação corresponde à sintaxe
- A regra está devidamente marcada e configurada em “modo sombra”
Um revisor também pode fazer uma verificação de sanidade da regra fora dos limites do conjunto de dados, por exemplo, os períodos de pico foram levados em consideração? Excluímos uma nova linha de produtos que não estava no conjunto de dados?
Quando a revisão for concluída com sucesso, o revisor poderá ativar a regra e liberá-la para o ambiente de produção ao vivo.
Etapa 4 - Validação em tempo real em modo sombra
Conforme mencionado na etapa anterior, o ideal é que novas regras sejam lançadas em “modo sombra”, no qual elas marcam os eventos sobre os quais teriam atuado, sem de fato aplicar nenhuma ação. Isso permite monitorar o desempenho e confirmar que a regra se comporta como esperado, sem assumir riscos desnecessários.
O objetivo desta etapa é descartar o pior cenário descrito anteriormente: uma regra que, sem querer, afete tantos usuários legítimos que acabe acionando imediatamente um incidente em toda a empresa. Isso acontece com mais frequência do que você imagina, às vezes por algo tão simples quanto trocar “score > 90” por “score < 90”, o que pode, de repente, bloquear 80% do tráfego.
Monitorar o volume de eventos que uma regra atingiria enquanto está em modo sombra permite detectar esses problemas com segurança e antecedência, antes que se transformem em bloqueio de usuários legítimos, aumento de chamados de suporte ou interrupções mais amplas no negócio. Como regra geral, novas regras devem permanecer em modo sombra por pelo menos uma semana, para confirmar que o comportamento em produção está alinhado com o desempenho histórico que justificou a liberação da regra em primeiro lugar.
Caso você tenha pulado o “modo sombra” por urgência (ou pela falta dela), ainda assim deve executar esta etapa enquanto monitora os resultados em tempo real. Observe a regra de perto nas primeiras 24 horas, especialmente na primeira hora, para descartar falhas catastróficas.
Etapa 5 - Revisão ao vivo em produção
Nesta etapa, o seu objetivo é evitar outro cenário indesejado: a regra não consegue detectar o padrão de fraude para o qual foi criada e acaba principalmente bloqueando falsos positivos. No entanto, isso é mais difícil de alcançar do que parece.
Se um evento for bloqueado, como você sabe que ele era realmente fraudulento? Sem chargebacks ou reclamações de clientes, não há uma maneira direta de medir fraudes bloqueadas ou falsos positivos nos seus painéis. Pelo que você sabe, a regra pode estar bloqueando o volume esperado de eventos, mas eles também podem ser falsos positivos.
A melhor forma de obter uma validação “rápida e simples” é revisar manualmente uma amostra dos acertos da regra e comparar os resultados com seus backtests. Se você espera que uma parte significativa da população seja fraude, não precisa revisar muitos casos. Normalmente, de 50 a 100 casos rotulados manualmente já oferecem uma boa indicação de se a regra está tendo o desempenho esperado. Esse tipo de amostragem também ajuda as equipes a decidir se uma regra está realmente melhorando o desempenho contra fraudes ou apenas transferindo mais trabalho para a revisão manual.
Tenha em mente que, se essa revisão for usada apenas para rotulagem temporária e não para aplicação de regras, a precisão em nível de caso é menos crítica. O que mais importa é obter uma visão de alto nível sobre as métricas ocultas que você está tentando revelar.
Depois de concluir esta etapa com sucesso, você pode afirmar com segurança que sua regra está estável e pronta para entrar totalmente em produção. É hora de desligar o “modo sombra”.
Etapa 6 - Monitoramento de longo prazo
Saber que sua regra se comporta como esperado no momento do lançamento é uma ótima notícia, mas isso não significa que ela continuará assim para sempre. Todo profissional de combate à fraude sabe que regras, como frutas, começam a apodrecer no minuto em que você as coloca em produção.
Com o tempo, os fraudadores vão evoluir e mudar seus padrões, novos padrões de falsos positivos vão surgir e o desempenho da sua regra vai se deteriorar.
A etapa final é configurar alertas de regras para avisá-lo quando isso começar a acontecer.
Considere estes dois casos de alerta:
- O problema: A regra pode sair do controle e começar a bloquear grandes parcelas da sua população.
- A solução: Implemente alertas que monitorem as ocorrências da regra e disparem quando um limite predefinido for atingido. Para evitar muitos falsos positivos, defina limites mais amplos.
- O problema: A precisão da regra está se deteriorando lentamente e está mais complexa de monitorar com alertas.
- A correção:A forma mais precisa de medir a taxa de falsos positivos de uma regra em produção é usando um grupo de controle que ignore o bloqueio para uma pequena população aleatória. Observe que essa abordagem provavelmente não será eficaz para a maioria das regras, especialmente aquelas que não foram projetadas para recusar grandes volumes de eventos por dia.
Embora existam diferentes maneiras de obter uma estimativa de precisão de forma automatizada, a maioria das equipes as consideraria complexas demais para implementar. Por esse motivo, o ideal é começar com uma revisão periódica das regras em produção a cada seis a doze meses.
Parabéns! Assim que seus alertas estiverem configurados, você pode considerar sua regra totalmente liberada.
Avalie-se: quão seguro é o seu processo de implantação de regras de fraude?
Como mencionamos, o processo acima representa o conjunto completo de melhores práticas. A boa notícia é que as equipes não precisam aperfeiçoar todas as etapas de uma só vez. Um rollout prático geralmente começa com um backtesting mais robusto, uma revisão especializada mais rigorosa e uma validação em modo sombra mais segura, amadurecendo depois para um fluxo mais completo de liberação e monitoramento. Na prática, sua equipe pode deixar de lado várias dessas partes, e a tarefa de implementar o processo por inteiro pode parecer assustadora. Tudo bem, não é um jogo de soma zero.
Aqui estão as etapas que você deve ir alcançando aos poucos enquanto avança nesse processo:
Liberar regras de fraude não precisa ser um salto de fé. Com um processo estruturado de validação e monitoramento, as equipes podem lançar mais rápido, reduzir riscos e manter alto desempenho do sistema, mesmo à medida que a fraude continua a evoluir.
As regras são apenas uma camada do quadro geral. Para saber até onde elas deixam de escalar e os fluxos de trabalho assumem, veja regras de fraude vs. fluxos de trabalho.
Perguntas frequentes
Quais critérios de sucesso devemos usar para avaliar uma regra?
Uma nova regra de fraude deve refletir o entendimento prévio e acordado sobre o equilíbrio que a empresa está disposta a aceitar entre impedir fraudes e gerar novos falsos positivos. Quaisquer que sejam as métricas usadas, certifique-se de que elas reflitam essa tensão. Uma boa regra geral é usar o desempenho geral do seu sistema de fraude como a base a ser superada para que uma nova regra seja liberada. Por exemplo, se a soma de todas as suas regras e modelos se traduz em 80% de precisão e 2% de recall, ambas as métricas devem ser melhoradas para que uma nova regra seja aprovada. Dessa forma, suas regras terão garantidamente um impacto geral positivo.
O que é uma “regra de rede de segurança” e por que as equipes de prevenção a fraudes devem usá-la?
As regras de segurança não são projetadas para impedir padrões de fraude do dia a dia; elas são feitas para protegê-lo contra cenários catastróficos, de pior caso, que possam ameaçar o negócio. Essas regras normalmente usam contadores de velocidade com limites muito altos ou limites amplos para detectar grandes e improváveis explosões de fraude que suas regras normais podem não captar. A ideia é que quase nunca sejam acionadas, mas, se forem, elas evitam perdas extremas e dão à sua equipe tempo para reagir sem entrar em crise. Tê-las implementadas pode reduzir o estresse em torno de eventos de fraude raros, porém de alto impacto, e garantir que você esteja preparado para picos excepcionais de risco.
As regras de prevenção a fraudes devem, em algum momento, ser pensadas para limitar a exposição em vez de simplesmente bloquear totalmente as ameaças?
Sim, limitar a exposição (por exemplo, colocando teto nos valores das transações ou restringindo novas contas) pode ser uma ferramenta estratégica, não apenas um controle de último recurso. Os limites não impedem totalmente a fraude, mas obrigam os fraudadores a ampliar suas operações para atingir suas metas econômicas. Cada tentativa adicional gera mais sinais e padrões que você pode detectar, transformando os limites em mecanismos de detecção, e não apenas em tetos de perda.
Por que uma regra pode parecer “boa” nos testes, mas ainda assim prejudicar o desempenho em produção?
Uma regra pode parecer eficaz de forma isolada, ter alta precisão no papel ou apresentar métricas históricas de backtest muito fortes e, ainda assim, ter um desempenho ruim em produção, porque as métricas de avaliação sozinhas não capturam o impacto no mundo real. As equipes costumam se apoiar em termos como recall ou taxa de falsos positivos, mas isso não mede o benefício incremental, como quanto de fraude extra a regra detecta além do sistema já existente ou se ela introduz custos ocultos para o negócio. A melhor forma de validar o desempenho de uma regra é observar a precisão em contexto, o impacto incremental sobre o sistema como um todo e as métricas reais de negócio (por exemplo, valor preservado vs. conversões afetadas). Essa visão sistêmica ajuda a identificar quando regras que “parecem ótimas” no papel na verdade só adicionam ruído ou prejudicam as operações na prática.
Por que o backtesting offline não é suficiente?
O backtesting offline mostra como uma regra teria se comportado usando dados históricos, mas não confirma como ela se comporta no seu sistema em produção. O backtesting online e o modo sombra são necessários para garantir que a regra funcione conforme o esperado quando for implantada.