A fraude não é um problema novo, mas a escala a que acontece hoje é. Cada pagamento online, abertura de conta ou pedido de reembolso é uma oportunidade para quem tenta enganar o sistema — e as regras fixas que durante anos travaram os esquemas mais óbvios já não chegam. Quem comete fraude adapta-se depressa, testa limites e esconde-se no meio de milhões de transações legítimas.
É aqui que o machine learning entra. Em vez de depender de uma lista de regras escritas à mão — bloquear se o valor for superior a X —, um modelo aprende com o histórico aquilo que distingue uma operação normal de uma suspeita, e continua a ajustar-se à medida que os padrões mudam. Bem aplicado, apanha esquemas que nenhuma regra anteciparia; mal aplicado, trava clientes legítimos e deixa passar os verdadeiros fraudadores.
Este guia percorre as decisões que separam um sistema de deteção de fraude útil de um que só gera ruído: que tipo de modelo usar, que dados alimentam a decisão, como lidar com o facto de a fraude ser rara e como saber se o modelo está mesmo a ajudar.
Porque é que a fraude é tão difícil de apanhar
Antes de escolher um algoritmo, vale a pena perceber contra o que estamos a lutar. A deteção de fraude tem quatro características que a tornam diferente de um problema de previsão vulgar.
- É rara. Em muitos negócios, menos de 1% das transações são fraudulentas. Um modelo que diga sempre "isto é legítimo" acerta em 99% das vezes e, ainda assim, é completamente inútil.
- O adversário adapta-se. Ao contrário de prever vendas, aqui há alguém do outro lado a mudar de tática assim que perceber que um caminho foi fechado.
- O custo de errar é assimétrico. Deixar passar uma fraude custa dinheiro; bloquear um cliente legítimo custa confiança e, muitas vezes, o próprio cliente. Nem sempre pesam o mesmo.
- A decisão é urgente. Um pagamento tem de ser aprovado ou recusado em milissegundos, não no dia seguinte.
Qualquer abordagem séria à fraude tem de responder a estas quatro pressões ao mesmo tempo. É por isso que copiar um modelo de outro contexto raramente funciona.
Aprendizagem supervisionada vs não supervisionada
Há dois grandes caminhos, e os melhores sistemas costumam combinar os dois.
Na aprendizagem supervisionada, treinamos o modelo com casos passados já rotulados como fraude ou não fraude. Modelos como gradient boosting (por exemplo, XGBoost ou LightGBM) ou florestas aleatórias funcionam bem quando existe um histórico fiável de fraudes confirmadas. A limitação é óbvia: só aprendem a reconhecer aquilo que já vimos antes.
Na aprendizagem não supervisionada, o modelo não recebe rótulos — procura apenas aquilo que foge ao normal. Técnicas como isolation forest, autoencoders ou clustering assinalam comportamentos anómalos, mesmo que nunca tenham sido vistos. É a melhor defesa contra esquemas novos, mas gera mais falsos alarmes, porque "estranho" não é sinónimo de "fraudulento".
Na prática, muitas equipas usam um modelo supervisionado para os padrões conhecidos e uma camada não supervisionada para apanhar o que é genuinamente novo, deixando os casos mais ambíguos para revisão humana.
As features que fazem a diferença
Um modelo de fraude é tão bom quanto os dados que recebe. E, quase sempre, o valor não está na transação isolada, mas no contexto em que ela acontece. As features mais úteis costumam ser construídas a partir do comportamento ao longo do tempo:
- Velocidade: quantas transações partiram deste cartão, dispositivo ou IP na última hora? Um salto súbito é um sinal clássico.
- Desvio do hábito: este cliente costuma comprar a esta hora, neste país, neste valor? A comparação com o seu próprio histórico vale mais do que qualquer limite absoluto.
- Ligações partilhadas: este dispositivo está associado a dezenas de contas diferentes? Vários cartões apontam para a mesma morada?
- Fricção temporal: quanto tempo passou entre criar a conta e a primeira compra de valor elevado?
Reparar que nenhuma destas features é o valor da compra em si. É a engenharia de features — transformar dados em bruto em sinais com significado — que separa um modelo medíocre de um bom.
O problema dos dados desequilibrados
Voltemos ao facto de a fraude ser rara. Se treinarmos um modelo com dados em que 99,5% dos casos são legítimos, ele aprende depressa que a aposta mais segura é dizer sempre "legítimo". A exatidão (accuracy) global fica ótima e o modelo não deteta nada.
Há várias formas de contornar isto: reamostrar os dados (reduzir os casos legítimos ou sobre-representar os fraudulentos, com técnicas como SMOTE), atribuir mais peso aos erros de fraude durante o treino, ou — o mais importante — deixar de olhar para a exatidão e escolher métricas que reflitam o que interessa.
Precisão, recall e o custo de errar
Duas métricas dominam a conversa em fraude, e é essencial perceber a tensão entre elas.
- Recall (sensibilidade): de todas as fraudes que aconteceram, quantas o modelo apanhou? Um recall baixo significa dinheiro a escorrer pela porta.
- Precisão: de todos os alertas que o modelo levantou, quantos eram mesmo fraude? Uma precisão baixa significa clientes legítimos bloqueados e uma equipa de revisão afogada em falsos alarmes.
Subir uma quase sempre baixa a outra. Onde colocar o limiar de decisão não é uma pergunta técnica — é de negócio. Quanto custa uma fraude não detetada? E um cliente irritado por ver o cartão recusado ao almoço? A resposta define o ponto de equilíbrio, e é por isso que a curva precisão-recall diz muito mais do que uma única percentagem de exatidão.
Tempo real vs análise em lote
Nem toda a fraude precisa da mesma velocidade de resposta. Autorizar um pagamento com cartão exige uma decisão em tempo real, em poucas dezenas de milissegundos — o que impõe limites ao modelo e à infraestrutura. Já detetar contas falsas criadas em massa, ou redes de conluio, pode ser feito em lote (batch), correndo análises mais pesadas de hora a hora ou de noite.
Muitos sistemas combinam as duas camadas: uma decisão rápida no momento, seguida de uma análise mais profunda que revê, confirma ou reverte casos e, sobretudo, alimenta o modelo com novos exemplos.
Quando o modelo começa a falhar
Um modelo de fraude não é um projeto que se entrega e esquece. Porque o adversário se adapta, o desempenho degrada-se naturalmente com o tempo — é o chamado concept drift. Aquilo que era um sinal forte de fraude há seis meses pode ser hoje comportamento perfeitamente normal.
Por isso, monitorizar o modelo em produção é tão importante como treiná-lo. Vale a pena acompanhar a taxa de alertas, a precisão confirmada pela equipa de revisão e a evolução das features ao longo do tempo. Um cuidado subtil mas crítico: a fraude que o modelo bloqueia nunca chega a confirmar-se como fraude, o que pode enganar as métricas. Sem uma amostra de controlo e sem o retorno de quem investiga os casos, o modelo fica cego ao seu próprio erro.
Mini-caso: apanhar mais fraude sem irritar clientes
Uma empresa de pagamentos online dependia de um conjunto de regras fixas: bloqueava compras acima de um valor, ou vindas de certos países. Apanhava cerca de 60% da fraude, mas ao custo de recusar muitas compras legítimas — a taxa de falsos positivos rondava os 5%, e o apoio ao cliente vivia cheio de reclamações.
A equipa introduziu um modelo de gradient boosting alimentado por features de velocidade e desvio de hábito, mantendo as regras antigas apenas como rede de segurança para os casos óbvios. Definiram o limiar não para maximizar a deteção, mas para manter os falsos positivos abaixo de 1%. Ao fim de três meses, a deteção de fraude subiu para perto de 85% e as compras legítimas recusadas caíram para menos de metade. O ganho não veio de um algoritmo mágico, mas de melhores features e de um limiar escolhido a pensar no negócio, não só na estatística.
Na prática
Detetar fraude com machine learning não é comprar o modelo mais sofisticado, é desenhar um sistema que respeita a natureza do problema: a raridade dos casos, o adversário que se adapta e o custo real de cada tipo de erro. Comece pelas features certas, escolha métricas que reflitam o negócio — precisão e recall, não exatidão —, combine modelos supervisionados e não supervisionados, e trate a monitorização como parte do produto, não como um extra.
E não descarte as regras: as melhores defesas combinam a rapidez de uma regra simples para o óbvio com a subtileza de um modelo para o resto. O objetivo nunca é apanhar 100% da fraude a qualquer preço — é encontrar o equilíbrio em que se perde menos dinheiro sem afastar quem, no fim, sustenta o negócio: os clientes de boa-fé.
