Detecção de Fraude em Pagamentos com ML: O Que Realmente Funciona

💡 TL;DR (Too Long; Didn't Read)

ML de fraude em 90 segundos:

Fraude em pagamentos é o problema difícil de ML de livro-texto: desbalanceamento extremo de classes (fraude é rara), adversarial (atacantes se adaptam ao seu modelo) e rótulos atrasados e ruidosos (você descobre a verdade semanas depois, via chargebacks).

A maior parte do ganho está nas features, não no modelo — velocidade, sinais de dispositivo e comportamento, e relações de grafo batem uma arquitetura mais elaborada sobre campos crus de transação.

Chargebacks são rótulos ruins: atrasados, incompletos e misturando fraude com disputa. Seu modelo só é tão bom quanto seu pipeline de rótulos.

O trade-off precisão/recall é uma decisão de negócio — toda fraude capturada custa algumas recusas falsas, e recusas falsas têm custo real, muitas vezes maior.

Regras e ML coexistem: regras para o conhecido e o explicável, ML para os padrões, e um step-up (3DS, PIN online) em vez de uma recusa dura quando possível.

Detecção de fraude em pagamentos é onde muita ambição de aprendizado de máquina vai ser humilhada. No papel parece um problema limpo de classificação binária: transação entra, fraude-ou-não sai. Na prática é o tipo mais difícil de ML — as classes são selvagemente desbalanceadas, o adversário se adapta ativamente ao que você implanta, e você só descobre se estava certa semanas depois, por um canal de rotulagem que mente para você. A boa notícia é que a área aprendeu o que de fato move a agulha, e a maior parte disso não é o modelo. Este é um tour prático pelo que funciona: as features que carregam o sinal, por que seus rótulos são o verdadeiro gargalo, como pensar sobre o limiar, e por que a resposta nunca é "só ML". Fica na interseção dos pagamentos que esta série decodificou com a fronteira da IA — e é honesto sobre onde a IA ajuda e onde não.

Três coisas que tornam este problema difícil

Desbalanceamento. Fraude é uma fração minúscula das transações — muitas vezes bem abaixo de 1%. Um modelo que prevê "não é fraude" para tudo tem 99%+ de acurácia e é completamente inútil. Acurácia não significa nada aqui; você vive no mundo de precisão, recall e o trade-off entre eles, e precisa projetar para o positivo raro: amostragem cuidadosa, ponderação de classes e métricas que não deixem a classe majoritária esconder a falha.

Deriva adversarial. Seu modelo de fraude não está classificando um fenômeno estacionário; está jogando contra oponentes que o sondam e se adaptam. Um padrão altamente preditivo hoje se torna inútil no momento em que fraudadores notam que você está pegando aquilo e mudam de tática. Isso significa que um modelo de fraude nunca está "pronto" — ele decai, às vezes rápido, e a maquinaria operacional para detectar deriva e retreinar importa mais que a qualidade do modelo inicial.

Rótulos atrasados e ruidosos. Este é o que surpreende as pessoas. Você não sabe que uma transação foi fraude quando ela acontece. Você descobre quando um chargeback chega — muitas vezes semanas depois — e mesmo então o rótulo é ruidoso, o que nos traz ao verdadeiro gargalo.

Chargebacks são rótulos terríveis (e são o que você tem)

O rótulo de "isto foi fraude" vem majoritariamente de chargebacks, e chargebacks são uma verdade fundamental profundamente imperfeita. Eles são atrasados — chegam semanas ou meses depois da transação, então seus dados de treino sobre a fraude de hoje já estão obsoletos quando você os tem, e seu modelo está sempre lutando a guerra passada. São incompletos — muita fraude nunca sofre chargeback (valores pequenos, não percebidos), então seus negativos estão contaminados com positivos não rotulados. E são misturados — um chargeback pode significar fraude verdadeira, ou "fraude amigável" (um portador real disputando uma compra legítima), ou uma disputa com o lojista, ou um problema de entrega. Seu "rótulo de fraude" é na verdade "alguém disputou isto, por uma de várias razões".

A consequência prática é a frase mais importante deste artigo: seu modelo de fraude só é tão bom quanto seu pipeline de rótulos. Tempo gasto tornando rótulos mais rápidos (sinais parciais antes do chargeback chegar), mais limpos (separando fraude verdadeira de fraude amigável e disputas) e mais completos (desfechos de análise manual, feeds de fraude confirmada) compra mais desempenho real que qualquer upgrade de modelo. Times que se obcecam com arquitetura e ignoram rótulos estão otimizando a ponta errada.

As features carregam o sinal

O achado mais confiável em ML de fraude aplicado é que engenharia de features bate sofisticação de modelo. Os campos crus da transação — valor, PAN, lojista, hora — carregam surpreendentemente pouco por si. O sinal vive em features derivadas:

Velocidade. Quantas transações neste cartão/dispositivo/IP no último minuto, hora, dia? Rajadas súbitas são um dos sinais mais antigos e melhores — o clássico "cartão testado com valores pequenos e depois usado forte".
Comportamento e dispositivo. Este dispositivo, localização e padrão são consistentes com o histórico deste portador? Uma primeira transação de um dispositivo novo, num país novo, às 3 da manhã, é um risco diferente do mesmo valor na loja habitual do portador.
Relações de grafo. Fraude raramente é uma transação solitária; ela se agrupa. Dispositivos, endereços ou cartões compartilhados entre contas revelam quadrilhas que features por transação perdem completamente. Features de grafo são de onde vem muito do ganho moderno.
Agregações por entidade. Estatísticas móveis por cartão, por lojista, por BIN — as distribuições em que uma dada entidade normalmente vive, para você sinalizar desvios delas.

Uma árvore com gradient boosting sobre features ricas vai bater uma rede profunda sobre features magras quase sempre. Gaste seu esforço onde o sinal está.

O limiar é uma decisão de negócio, não uma métrica

Uma vez que você tem um score de risco, precisa escolher onde agir — e isso não é uma questão de ML, é de negócio. Toda transação fraudulenta que você captura vem ao custo de algumas recusas falsas: bons clientes cujas compras legítimas você bloqueia. E recusas falsas são caras — muitas vezes mais caras que a fraude, porque um bom cliente recusado pode abandonar a compra, perder confiança e não voltar. O trade-off precisão/recall é, na verdade, um trade-off de reais: o custo das perdas por fraude de um lado, o custo da boa receita perdida do outro, e o limiar é onde você decide o equilíbrio.

A jogada madura é escapar do binário. Em vez de aprovar-ou-recusar, adicione um meio: um step-up. Uma transação de risco médio não precisa ser recusada — pode ser desafiada com 3-D Secure, um PIN online ou uma biometria de dispositivo. Um portador genuíno passa o desafio e completa; um fraudador normalmente não consegue. Step-up converte uma decisão de recusa perde-perde numa recuperável, e é por isso que a maquinaria de CVM e autenticação desta série é parte da pilha de fraude, não algo separado dela.

Regras e ML coexistem — de propósito

Há uma tentação recorrente de substituir o motor de regras por "só o modelo". Resista. Regras e ML fazem cada um algo que o outro não faz. Regras codificam o conhecido, o mandatório e o explicável: bloqueios duros em cartões de fraude confirmada, exigências regulatórias e a lógica "se X então sempre Y" que um time de conformidade precisa poder apontar. ML captura os padrões difusos que nenhum humano escreveria. Uma regra é auditável e instantânea de mudar quando um ataque novo aparece; um modelo é poderoso mas opaco e lento de retreinar. Sistemas de fraude em produção rodam os dois — regras como a camada rápida, explicável e de restrição dura, ML como a camada de padrões alimentando um score — e o próprio score muitas vezes realimenta as regras ("se score do modelo > t e regra de velocidade dispara, faça step-up"). A arquitetura é híbrida porque o problema tem estrutura conhecida e desconhecida.

Onde a fronteira da IA realmente ajuda (e onde o hype não)

Como este é o canto Pagamentos×IA da série, a avaliação honesta: os avanços duráveis em ML de fraude são pouco glamorosos — melhores features, melhores rótulos, sinais de grafo, laços de retreino mais rápidos, boa detecção de deriva. Modelagem mais nova pode ajudar nas margens (modelos de sequência sobre o histórico de transações de um portador, redes neurais de grafo sobre o grafo de relações), mas ajudam em cima de engenharia sólida de features e rótulos, não em vez dela. E a mesma dinâmica adversarial que governa o resto da segurança de IA se aplica aqui: um modelo mais poderoso também é uma coisa mais poderosa para atacantes sondarem e evadirem. Os times que ganham não são os com a arquitetura mais elaborada; são os com os rótulos mais limpos, as features mais ricas e a disciplina operacional para manter ambos atualizados contra um adversário que se adapta — o mesmo fosso de "correção mantida ao longo do tempo" que atravessa esta série inteira.

Onde isto se encaixa

Detecção de fraude é a camada de risco embrulhada em torno de tudo que Payments Under the Hood decodificou: ela pontua as transações, decide quando exigir o step-up que invoca CVM, e seus rótulos vêm do lado de disputa do fluxo de mensagens. As garantias criptográficas do chip reduzem estruturalmente a fraude com cartão presente; ML é como você combate o que resta, especialmente cartão não presente.