Fraude em Pagamentos com Grafos: Do Link Prediction às GNNs em Produção

Diagrama do pipeline de detecção de fraude com grafos. Eventos de transação (cartão, device, IP) formam um grafo heterogêneo (centro-esquerda). Um cluster de fraude (em vermelho) é detectado por um motor de GNN (centro-direita), que gera um score de fraude alto (vermelho).

Resumo — Fraudadores não agem sozinhos. Eles operam em redes, usando um emaranhado de contas, cartões, dispositivos e e-mails para esconder suas trilhas. Modelos de ML tradicionais, que olham para transações de forma isolada, falham em ver a “conspiração”. A detecção de fraudes moderna é um problema de grafos. Este post explica como modelamos o ecossistema de pagamentos como um grafo heterogêneo e como evoluímos de heurísticas simples para GNNs (Graph Neural Networks) para encontrar os padrões que os fraudadores tentam esconder.

1. O Problema: Fraude é um Problema de Rede

Por que a detecção de fraudes é um problema de grafos? Porque a fraude é relacional. Um modelo tradicional pode ver uma transação e dizer: “O valor é baixo, o local é comum, o produto é normal. Parece legítimo.”

Esse modelo perde o contexto crucial:

O cartão usado nessa transação foi usado em 30 dispositivos diferentes na última hora.
O dispositivo usado nessa transação está ligado a 50 contas recém-criadas.
O e-mail da conta está conectado a 10 cartões que já foram reportados como roubados.

Isoladamente, cada entidade parece normal. Conectadas, elas formam um “bairro ruim” digital. A única forma de ver isso é modelando o problema como um grafo heterogêneo.

Nesse grafo, temos diferentes tipos de nós e arestas:

Nós (Entidades): Conta, Cartão, CPF/CNPJ, Dispositivo (device ID), Endereço IP, E-mail, Telefone, Merchant (Lojista).
Arestas (Relações): transaciona (conta $\rightarrow$ merchant), usa (conta $\rightarrow$ dispositivo), pertence (cartão $\rightarrow$ conta), compartilha (dispositivo $\rightarrow$ IP).

As arestas são temporais: elas possuem um timestamp (carimbo de tempo) de quando a relação ocorreu, o que é fundamental para a análise.

2. O Ponto de Partida: Baselines Fortes (Antes das GNNs)

Antes de pular para o deep learning, é crucial estabelecer baselines (pontos de comparação). Muitas vezes, heurísticas de grafos simples já capturam 80% do problema:

Heurísticas de Vizinhança (Features de Grafo): A forma mais simples de usar o grafo é criar features para um modelo tabular (como um XGBoost). Respondemos perguntas como:
- Quantos cartões usaram este Dispositivo nos últimos 7 dias?
- Quantos IPs únicos esta Conta usou nas últimas 24 horas?
- Qual o valor médio transacionado pelos outros dispositivos que compartilharam o IP desta conta? (agregação k-hop)
Personalized PageRank (PPR): Como vimos no post sobre o Twitter, o PPR é um algoritmo de “proximidade”. Em fraudes, nós o usamos para medir a “culpa por associação”:
- Começamos com um conjunto de nós “sementes” (fraudes já confirmadas).
- Rodamos um PPR a partir desses nós.
- O resultado é um score para todos os outros nós do grafo (contas, dispositivos, IPs) que mede sua “proximidade” com fraudes conhecidas. Esse score é uma feature incrivelmente poderosa.

3. A Revolução das GNNs: Aprendendo Padrões Complexos

As heurísticas são poderosas, mas são manuais. Nós, humanos, temos que pensar na regra (“quantos cartões por dispositivo?”).

E se um modelo de ML pudesse aprender sozinho qual é o padrão de uma fraude? E se ele aprendesse que o padrão perigoso não é “50 cartões em 1 dispositivo”, mas sim “um dispositivo conectado a 3 contas novas, que usaram 5 cartões diferentes, que transacionaram em 10 merchants que nunca foram vistos antes”?

Isso é o que as Graph Neural Networks (GNNs) fazem.

Uma GNN (como a GraphSAGE ou LightGCN) aprende um embedding (um vetor “DNA”) para cada nó, baseado na agregação das informações de sua vizinhança. Para grafos heterogêneos como o de pagamentos, arquiteturas como R-GCN ou HAN são usadas, pois elas aprendem pesos diferentes para tipos de arestas diferentes (ex: a GNN aprende que uma aresta compartilha_dispositivo é 10x mais suspeita que uma aresta usa_mesmo_merchant).

O modelo pode ser treinado para duas tarefas:

Classificação de Nós: O nó Conta XYZ é fraudulento?
Classificação de Arestas: A Transação ABC é fraudulenta?

4. A Métrica que Importa: AUPRC (Não se Engane com a Acurácia)

Este é o ponto mais crítico na avaliação de um modelo de fraude: o desbalanceamento de classes é severo. Em um sistema de pagamentos saudável, a esmagadora maioria das transações (muitas vezes 97%, 99%, ou mais, dependendo do contexto) são legítimas.

Se você criar um modelo que simplesmente diz “tudo é legítimo”, ele terá uma acurácia altíssima (97%-99%+), mas será 100% inútil.

Em cenários assim, a Acurácia e a ROC-AUC são métricas enganosas. A métrica que realmente importa é a AUPRC (Area Under the Precision-Recall Curve), ou “Área sob a Curva de Precisão-Recall”.

Recall: De todas as fraudes reais que aconteceram, quantas o seu modelo conseguiu pegar?
Precision (Precisão): De todas as transações que o seu modelo marcou como fraude, quantas eram realmente fraude?

Há um trade-off: para pegar mais fraudes (aumentar o Recall), você inevitavelmente vai bloquear mais transações legítimas (diminuir a Precisão), o que irrita bons clientes. O AUPRC mede a qualidade desse trade-off. O objetivo de negócio é encontrar o “ponto de equilíbrio” (limiar de score) que maximize a detecção de fraude (Recall) ao mesmo tempo que minimiza o impacto em clientes legítimos (a Taxa de Falsos Positivos, ou FPR).

5. Armadilhas de Produção: Vazamento de Dados e Drift

Colocar um modelo de grafos em produção para fraudes é um campo minado. As duas maiores armadilhas são:

Vazamento de Dados (Leakage): É o erro mais fácil de cometer.
- Vazamento Temporal: Você não pode treinar seu modelo com dados do futuro. A separação treino/validação/teste deve ser feita por tempo (ex: treinar com Janeiro-Março, validar com Abril, testar com Maio).
- Vazamento de Vizinhança: Se uma transação de teste em Maio compartilha o mesmo dispositivo que uma transação de treino em Janeiro (que era fraude), o modelo “vê” a resposta. Você deve garantir que seus conjuntos de treino e teste sejam separados não apenas por tempo, mas também por “componentes” do grafo.
Drift (Mudança de Padrão): Os fraudadores não dormem. O padrão de fraude que seu modelo aprendeu em Maio será diferente do padrão de Julho. Os fraudadores se adaptam.
- Solução: Re-treinamento constante (diário ou semanal), monitoramento de data drift (as features de entrada estão mudando?) e model drift (a performance do modelo está caindo?).

Conclusão

Grafos não são apenas “mais uma ferramenta” para detecção de fraudes; eles são a representação correta do problema. A fraude é um fenômeno de rede. Ao modelar o problema como um grafo heterogêneo e temporal, podemos usar desde heurísticas simples e poderosas (como PPR) até arquiteturas de GNNs sofisticadas para encontrar os padrões de “culpa por associação” que os fraudadores tentam esconder.

Referências

Surveys (Visão Geral):

Liu, Z. et al. (2021). Graph Neural Networks for Anomaly Detection in Financial Networks. arXiv:2108.06798. (Um survey focado em GNNs para redes financeiras).
Zha, D. et al. (2020). Data Mining for Financial Fraud Detection: A Survey. arXiv:2008.09459. (Uma visão geral mais ampla das técnicas de mineração de dados para fraude).

Arquitetura, Métricas e Prática:

(GNNs na Indústria): NVIDIA Technical Blog (2025). Supercharging Fraud Detection in Financial Services with Graph Neural Networks. (Um excelente post técnico que discute a combinação de GNNs com XGBoost para fraude, muito alinhado com a prática da indústria).
(AUPRC e Desbalanceamento): Hancock, J. T., & Filar, J. (2023). Evaluating classifier performance with highly imbalanced Big Data. Journal of Big Data. (Uma referência acadêmica crucial que valida por que o AUPRC é uma métrica superior ao ROC-AUC em cenários de fraude).
(Exemplo de Arquitetura GNN): Tang, J. et al. (2022). Rethinking Graph Neural Networks for Anomaly Detection. ICML 2022. (Um paper que analisa por que certas arquiteturas de GNN funcionam para detecção de anomalias).

Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br

GrafoLab

posts recentes

mais visitados