Detecção de Fraude com Machine Learning vs. Regras

Última atualização: Setembro de 2026

A detecção de fraudes por machine learning avalia uma transação ou um cliente com base em padrões aprendidos a partir de resultados históricos rotulados, retornando uma probabilidade em vez de um veredito. Essa característica única é o que a separa de uma regra, e é também por isso que a pergunta que as equipes de fraude continuam debatendo — regras ou modelos — é a pergunta errada. Regras e modelos respondem a perguntas diferentes. Toda operação em grande escala já utiliza ambos.

A pergunta realmente útil é mais específica e muito mais fácil de responder: diante de uma decisão de fraude específica, qual mecanismo deve ser o responsável por ela? Este artigo responde a isso, além de esclarecer o que você deve a um regulador e a um cliente recusado quando um modelo toma a decisão.

Resumo (TL;DR)

• A detecção de fraudes por machine learning aprende com resultados rotulados e gera uma probabilidade. Uma regra estabelece uma decisão tomada pela instituição. São instrumentos diferentes, não versões concorrentes do mesmo recurso.

• Os modelos não conseguem aprender fraudes que nunca foram detectadas e rotuladas. Esse limite é estrutural, e é por isso que novas tipologias e obrigações regulatórias ainda pertencem às regras.

• O verdadeiro eixo de comparação não é a precisão. É a explicabilidade, a latência, a disponibilidade de rótulos e quem pode alterar a lógica sem precisar esperar por um desenvolvedor.

• A explicabilidade não é uma propriedade do modelo que você simplesmente declara em uma ficha técnica. É uma propriedade operacional, e o local para mensurá-la é a fila de análise.

• Os modelos degradam silenciosamente. As regras degradam de forma visível. Essa assimetria, e não a precisão, é o argumento para monitorar o desvio por segmento.

O que é a detecção de fraudes por machine learning

A detecção de fraudes por machine learning é um método que avalia um evento — uma transação, um login, um cadastro — comparando seus atributos com padrões aprendidos a partir de resultados históricos que foram rotulados como fraude ou legítimos. O resultado é um número: a probabilidade de que este evento se pareça com as fraudes usadas no treinamento do modelo.

Esse resultado é uma probabilidade, não um veredito, e essa distinção importa mais do que qualquer outra coisa nesta comparação. Uma regra retorna uma decisão. Um modelo retorna um grau de convicção. Outro elemento ainda precisa decidir o que fazer com isso — aprovar, recusar, solicitar autenticação adicional ou direcionar para análise humana.

É por isso que a pergunta "devemos usar regras ou modelos" é mal formulada. Um modelo não toma decisões. Ele gera um sinal que é consumido por uma camada de decisão. Modelos e regras de detecção de fraude ocupam posições diferentes no mesmo fluxo de processamento.

Como um modelo realmente decide

Quatro etapas acontecem entre a chegada de um evento e o retorno de uma pontuação.

Variáveis (Features). O modelo não enxerga uma transação. Ele enxerga variáveis — atributos derivados do evento e do contexto ao seu redor. Valor, hora do dia e categoria do estabelecimento são os mais óbvios. Os que realmente importam costumam ser relacionais e temporais: como este valor se compara ao histórico do próprio cliente, quantas tentativas o antecederam, há quanto tempo a conta existe, como o dispositivo se comportou antes da tela de pagamento. A engenharia de variáveis é onde está a maior parte do trabalho real de machine learning para detecção de fraudes, e é a parte que as discussões genéricas sobre modelos costumam ignorar.

Treinamento com resultados rotulados. O modelo aprende ao analisar eventos históricos junto com o que se confirmou sobre eles. O aprendizado supervisionado em resultados de fraudes rotuladas exige que alguém, em algum momento, tenha marcado corretamente um caso como fraude. O teto de eficácia do modelo é a qualidade e a cobertura desses rótulos.

Pontuação em tempo real. Em produção, o mesmo conjunto de variáveis é reunido em tempo real e o modelo retorna uma pontuação nos milissegundos disponíveis antes que um pagamento seja autorizado. A detecção de fraudes em tempo real é uma restrição de latência para toda a infraestrutura, não uma propriedade exclusiva do modelo — as variáveis precisam ser calculadas a tempo, o que frequentemente é o limite restritivo.

O problema do rótulo. Aqui está o limite real. Um modelo só consegue aprender fraudes que já foram detectadas e rotuladas anteriormente. Fraudes que passaram sem detecção são invisíveis para ele, pois nada nos dados de treinamento indica que ocorreram. Isso não é uma falha de um modelo específico. É uma propriedade estrutural do aprendizado com base em resultados passados e limita o que você pode esperar que um modelo cubra.

O problema do rótulo é mais crítico onde os prejuízos demoram a aparecer ou nunca são atribuídos. A fraude amigável (first-party fraud) é o caso clássico: o próprio cliente é o autor, as disputas chegam meses depois e muitos casos acabam sendo registrados como perda de crédito em vez de fraude rotulada. Um modelo treinado com esses rótulos aprende uma imagem distorcida da realidade.

O que as regras ainda fazem melhor

As regras não são uma camada antiga que os modelos estão substituindo aos poucos. Quatro funções pertencem a elas e continuarão pertencendo.

Obrigações determinísticas. Um limite regulatório não é uma probabilidade. Uma exigência de sanções não é uma probabilidade. Quando uma instituição é obrigada a agir em um limite específico, esse limite precisa ser definido de forma exata. Tentar modelar isso seria incorreto e inexplicável.

Novas tipologias ainda sem rótulos. Um novo padrão de ataque surge em uma manhã de terça-feira. Uma regra pode ser criada naquela mesma manhã. Um modelo não pode ser treinado para isso, porque os exemplos rotulados ainda não existem e levará semanas para existirem. As regras são a forma como uma operação responde no período em que os modelos ainda não têm dados para aprender.

Intenção auditável. Uma regra detalha o que a instituição decidiu fazer, em uma linguagem que o regulador lê diretamente. Trata-se de um recurso diferente de uma pontuação associada a um limite. Quando a pergunta é "qual era a sua política?", a regra é a resposta no formato esperado.

Velocidade de mudança sob controle humano. O gestor de risco pode ajustar uma regra sem precisar de um ciclo de retreinamento do modelo e sem abrir chamados para a equipe de engenharia. Quando a resposta para "quem precisa mudar isso e até quando" é "a equipe de risco, até sexta-feira", essa decisão deve ficar em uma regra.

Nada disso exige um aprofundamento em criação de regras, ciclo de vida das regras ou como um motor de regras é construído. O ponto aqui é mais direto: as regras são metade de uma estrutura de decisão, e essas quatro funções são o motivo pelo qual essa metade é permanente.

A comparação que ninguém está realmente fazendo

O debate entre regras versus machine learning descreve uma discussão que as instituições em operação não estão tendo na prática.

Em uma conversa recente, uma empresa de pagamentos dos EUA descreveu sua arquitetura operacional de forma simples: um motor de regras interno rodando em produção, junto com camadas de parceiros e fornecedores que contribuem com modelos de machine learning. Ambos ao mesmo tempo. Isso não foi descrito como uma migração em andamento ou um acordo temporário. Foi descrito como o formato padrão do sistema.

Esse é o caso mais comum, não a exceção. É também por isso que as equipes que avaliam softwares de detecção de fraudes percebem que a questão de "regras ou modelos" já está resolvida quando chegam à lista de finalistas — o que elas realmente comparam é o quão bem cada plataforma executa ambos. O que significa que o principal argumento comercial dos fornecedores — qual é o mais preciso — não é o fator decisivo. Os critérios reais são quatro:

• Explicabilidade. Do que você precisa prestar contas, para quem e com qual velocidade?

• Latência. Quanto tempo a decisão tem e os dados necessários podem ser processados nesse intervalo?

• Disponibilidade de rótulos. Existem resultados rotulados suficientes para esta decisão?

• Autonomia de mudança. Quem precisa ser capaz de alterar a lógica e isso exige a atuação de um engenheiro?

O padrão maduro que surge desses critérios é o uso de regras como limites de proteção ao redor do resultado probabilístico. O modelo gera a pontuação. As regras limitam o que pode ser feito com essa pontuação — o que ela pode aprovar sozinha, o que deve ser escalado e o que ela nunca pode ignorar.

Uma estrutura para direcionar uma decisão

Diante de uma decisão específica de fraude, faça quatro perguntas em ordem. A primeira resposta que resolver a decisão encerra o processo.

1. Trata-se de uma obrigação ou de um julgamento? Obrigações são regras. Sempre. Se uma regulamentação, uma exigência de bandeira ou um acordo contratual especifica a ação em um determinado limite, isso é definido como regra e não passa por modelagem.

2. Existem resultados rotulados suficientes para isso? Sem rótulos, não há modelo, independentemente da intenção. Se as perdas nessa categoria demoram a aparecer, são atribuídas a outros fatores ou nunca foram analisadas, os dados de treinamento não descrevem o problema e um modelo treinado com eles trará um diagnóstico incorreto com aparência de certeza.

3. O que você precisa explicar e para quem? Explicar uma recusa para um agente de atendimento, para um regulador ou para um comitê interno de risco do modelo são três níveis de exigência totalmente diferentes. Esse nível define quanta interpretabilidade o mecanismo precisa suportar e se a explicação deve estar acessível para o analista que trata o caso ou se basta existir em um arquivo.

4. Quem precisa alterar isso e com qual velocidade? Se a equipe de risco precisa ajustar a lógica ainda esta semana sem depender de um ciclo de engenharia, trata-se de uma regra — independentemente de um modelo poder, em teoria, gerar uma pontuação melhor.

Na prática, a estrutura direciona as decisões desta forma:

Cada linha corresponde às mesmas quatro perguntas respondidas em ordem. A terceira coluna é a que as equipes mais costumam ignorar, e é justamente a que mais altera a resposta final.

Depois de direcionar a decisão, o próximo desafio é calibrar o limite em que ela opera — até que ponto tolerar uma pontuação antes que a fila de análise fique sobrecarregada. Essa é uma disciplina diferente do direcionamento inicial e que merece atenção dedicada.

Como os dois operam juntos na prática

A detecção e a tomada de decisão são etapas independentes. O que gera o sinal não precisa ser o que define o resultado — uma distinção que um consultor de conformidade contra crimes financeiros resumiu de forma clara ao separar a organização dos alertas do motor que os gera. Uma vez aceita essa separação, os padrões de integração tornam-se simples.

As regras limitam a saída do modelo. Valores mínimos, máximos, faixas de revisão obrigatórias e bloqueios imediatos que uma pontuação nunca pode ignorar. Um modelo pode sugerir a aprovação de um caso; uma regra decide que este cliente, nesta jurisdição, neste valor, passará por análise humana de qualquer forma.

Os modelos enriquecem as entradas das regras. Uma regra não precisa ser acionada apenas por um atributo bruto. Ela pode utilizar uma pontuação de risco calculada como uma de suas condições. É assim que uma política determinística aproveita as vantagens de um sinal probabilístico sem perder seu caráter definitivo.

Ambos devem estar na mesma infraestrutura. A Oscilar é uma plataforma unificada: estrutura de dados em tempo real, inteligência de dispositivo e comportamento, regras e gestão de casos no mesmo ambiente, com agentes nativos. A importância disso não é apenas ter uma solução completa. O ponto é que dividir a detecção e a tomada de decisão em sistemas separados gera retrabalho — o analista consulta a pontuação em uma ferramenta e aplica a política em outra, fazendo a conciliação manualmente. Manter a camada de decisão e a camada de sinal no mesmo local é também o que permite que os agentes de risco atuem em um caso já com a justificativa integrada.

O mesmo argumento de arquitetura se aplica um nível acima, ao rodar uma camada compartilhada de modelos e regras para fraude e PLD (Prevenção à Lavagem de Dinheiro), em vez de manter duas estruturas paralelas. Esse é um tema específico.

O que você deve a um regulador e a um cliente recusado

Esta é a parte que os materiais de comparação costumam omitir, e é onde o debate entre regras e modelos realmente se resolve na prática.

A explicabilidade não é uma propriedade do modelo declarada em um documento. É uma propriedade operacional, e o local para mensurá-la é a fila de análise.

O teste prático é direto: o analista que trata o caso consegue entender por que a decisão foi tomada, sem precisar reconstruí-la do zero? Não se trata de saber se "a categoria do modelo é explicável em teoria" ou se "documentamos a metodologia". Trata-se de o profissional com o caso aberto conseguir ler o motivo. Isso exige que a decisão leve códigos e atributos de explicabilidade diretamente para a gestão de casos, fazendo com que o motivo chegue junto com o alerta, em vez de ser buscado posteriormente no banco de dados por um especialista.

Por trás desses códigos está a atribuição de variáveis. Uma explicação consistente indica quais fatores de risco no comportamento analisado geraram aquela pontuação — por exemplo, a rapidez de uma sequência de transações, em vez de uma afirmação genérica de que a velocidade de transações faz parte do modelo. Uma pontuação sem justificativa própria não é uma explicação, não importa o que a documentação técnica prometa.

Uma objeção comum precisa ser respondida: a de que modelos mais complexos necessariamente prejudicam a interpretabilidade. Isso não é verdade. A mesma disciplina de explicabilidade pode ser aplicada a diferentes tipos de modelos. Tratar a perda de interpretabilidade como consequência natural da evolução dos modelos é uma escolha de construção de sistema, não uma regra da tecnologia.

Além disso, há o registro histórico. O que torna uma recusa baseada em modelo defensível meses depois é uma trilha de auditoria completa por decisão, com a justificativa armazenada e a supervisão humana integrada por padrão (human-in-the-loop), projetada para atender às diretrizes da SR 11-7. Essa é uma expectativa para a qual a plataforma é projetada, não um simples certificado que se obtém — e essa distinção precisa ficar clara, pois o regulador cobrará isso de você.

Como os modelos degradam e o que monitorar

As regras também perdem eficiência com o tempo. A diferença é que a regra degrada de forma visível — alguém percebe que ela está bloqueando tudo ou não está bloqueando nada. O modelo degrada silenciosamente, e essa assimetria é o argumento mais forte contra o uso de modelos sem monitoramento contínuo.

Desvio de conceito (Concept drift). Os padrões de fraude mudam. O comportamento que o modelo aprendeu deixa de descrever o cenário atual. Nenhum erro é gerado. A distribuição das pontuações muda sutilmente e a taxa de perdas aumenta meses depois.

Desvio de dados e variáveis. Uma alteração técnica nos sistemas de origem modifica uma entrada de dados sem aviso — um campo passa a chegar vazio, um parceiro altera um padrão de codificação ou um registro de data/hora muda de fuso horário. As variáveis perdem qualidade, o modelo degrada junto e nenhum alerta de erro é gerado no fluxo porque tecnicamente nada falhou.

A solução é um monitoramento que acompanhe ambos os cenários. A Oscilar acompanha desvios de dados, variáveis e conceitos, além dos indicadores de resultados (KPIs) por segmento. A análise por segmento é fundamental: um indicador consolidado aparentemente estável pode facilmente mascarar um segmento que já está falhando, e o monitoramento consolidado faz com que a operação só descubra o problema através dos prejuízos acumulados, e não pelos seus sistemas de controle.

Perguntas frequentes

O que é detecção de fraude por machine learning?

A detecção de fraude por machine learning avalia uma transação, login ou cadastro comparando suas características com padrões identificados em dados históricos rotulados. Ela retorna a probabilidade de o evento se parecer com uma fraude conhecida, e não uma decisão final. Uma camada de decisão separada — geralmente composta por regras — define o que será feito com essa pontuação.

Como o machine learning detecta fraudes?

Um modelo é treinado com eventos históricos marcados como fraude ou legítimos. Ele aprende quais combinações de variáveis — valor em relação ao histórico do cliente, velocidade das transações, comportamento do dispositivo, tempo de conta — diferenciam os dois casos. Na operação, essas variáveis são calculadas em tempo real para cada novo evento e o modelo retorna uma pontuação de risco em milissegundos.

O machine learning é melhor do que as regras para detecção de fraudes?

Nenhum é intrinsecamente melhor, pois respondem a perguntas diferentes. Um modelo estima a probabilidade de um evento ser fraude. Uma regra determina o que a instituição decidiu fazer a respeito. Estruturas maduras utilizam ambos, com regras servindo como limites de proteção para o resultado do modelo, e não como uma tecnologia obsoleta a ser eliminada.

Como decidir se uma análise de fraude deve ser feita por regra ou modelo?

Siga quatro perguntas em ordem. Trata-se de uma obrigação ou de um julgamento — obrigações são sempre tratadas por regras. Existem dados históricos rotulados em volume suficiente — sem rótulos, sem modelo. O que você precisa explicar e para quem. Quem precisa fazer alterações e com qual rapidez — se a equipe de risco precisa do ajuste nesta semana, deve ser uma regra.

Como explicar uma recusa por fraude baseada em machine learning para um regulador ou cliente?

Tornando o motivo operacional em vez de apenas documental. A decisão deve levar códigos de explicabilidade e atribuição de variáveis diretamente para a tela de gestão de casos, permitindo que o analista identifique os fatores de risco que influenciaram a pontuação naquela transação. Por trás disso, deve existir uma trilha de auditoria para cada decisão com a justificativa armazenada, garantindo a reconstrução do cenário meses depois.

O que considerar a partir de agora

Evite tratar o debate entre regras versus machine learning como uma escolha conceitual da sua instituição e passe a avaliá-lo como uma decisão prática para cada caso de uso. Obrigações, novos padrões de fraude sem dados históricos e qualquer ajuste que a equipe de risco precise fazer com agilidade devem ficar em regras. Julgamentos que contam com um histórico rico e rotulado devem ser direcionados para modelos, protegidos por limites de regras. E não importa qual mecanismo defina o resultado, a explicação precisa chegar de forma clara ao analista na fila de revisão.

Se você está avaliando como aplicar isso em sua própria estrutura, nossa abordagem para decisão de fraude em transações em tempo real é a demonstração prática das etapas apresentadas acima.