Fraud scoring para PIX: como montar um modelo de risco em Python

O Banco Central do Brasil processa rotineiramente mais de 160 milhões de transações Pix em um único dia. O dinheiro troca de mãos em menos de três segundos. A velocidade que revolucionou o varejo e a inclusão financeira no país também se tornou a maior arma do crime organizado. O roubo a banco com explosivos deu lugar à engenharia social, ao phishing e ao sequestro relâmpago digital. Se você opera uma fintech, um e-commerce ou uma subadquirente, preste atenção aqui: o seu motor de regras baseado em 'se/então' construído em 2019 já está morto.

Nós acompanhamos diariamente as trincheiras do compliance e da prevenção a perdas em gigantes como Nubank, Mercado Pago e Stone. O consenso é absoluto. Tentar segurar fraude no Pix com regras estáticas como 'bloqueie transferências acima de R$ 5.000 após as 22h' destrói a experiência do usuário. O cliente legítimo fica frustrado, xinga no Reclame Aqui e transfere o dinheiro para o concorrente. Você precisa de inteligência matemática. Você precisa de um modelo de Machine Learning capaz de cruzar centenas de variáveis em milissegundos.

Hoje, vamos abrir a caixa preta. Mostraremos como estruturar um modelo de fraud scoring para Pix útilizando Python. Focaremos no que realmente importa: a criação de features comportamentais e temporais que diferenciam um usuário pagando a conta do bar de um golpista esvaziando uma conta invadida.

O que o BACEN exige e o que o mercado prática

Antes de codar, precisamos entender as regras do jogo. A Resolução BCB nº 103 e o Mecanismo Especial de Devolução (MED) forçaram as instituições financeiras a assumirem maior responsabilidade sobre fraudes. Quando um 'golpe do Pix' ocorre, o banco recebedor (onde está a conta laranja) e o banco emissor precisam se comúnicar rápidamente via infraestrutura do Sistema de Pagamentos Instantâneos (SPI).

O BACEN determina que as instituições podem reter uma transação Pix por até 30 minutos (durante o dia) ou 60 minutos (à noite) se houver suspeita fundada de fraude. Na prática, reter transações de forma massiva mata o principal benefício do produto. A meta operacional de qualquer equipe de Risco é aprovar ou negar 99% das transações em menos de 500 milissegundos. Deixamos a retenção de 30 minutos apenas para os casos que caem na 'zona cinzenta' do score de fraude, exigindo revisão manual humana.

Instituições de ponta operam com modelos de aprovação em cascata (waterfall). Primeiro, listas de bloqueio duro (blocklists de chaves Pix, CPFs com apontamento no COAF, IPs conhecidos por fraude). Segundo, o modelo de Machine Learning. Terceiro, regras de negócio específicas para limites diários estabelecidos pelo usuário. Nosso foco neste artigo é o segundo passo: o cérebro da operação.

A anatomia de uma fraude via Pix

Para ensinar uma máquina a detectar fraudes, precisamos traduzir o crime para a linguagem dos dados. Observamos que as fraudes de Pix no Brasil se dividem majoritariamente em três vetores.

O primeiro é o Account Takeover (ATO) clássico. O fraudador rouba o celular desbloqueado da vítima ou consegue acesso via malware/phishing. O comportamento aqui é agressivo: o fraudador tenta limpar a conta o mais rápido possível antes que a vítima ligue para o banco. O valor transacionado foge do padrão histórico daquele usuário.

O segundo vetor é a Engenharia Social (Golpe do WhatsApp, falso funcionário do banco). A vítima, enganada, realiza a transferência por conta própria do seu dispositivo usual. Este é o pesadelo dos modelos de fraude, pois a biometria comportamental (como o usuário segura o celular, velocidade de digitação) e o Device ID são idênticos aos de uma transação legítima. A detecção aqui depende quase inteiramente da análise da conta de destino (a conta laranja).

O terceiro é o autogolpe ou fraude amiga. O usuário faz o Pix, recebe o produto ou serviço e depois aciona o banco alegando que foi hackeado, tentando usar o MED para reaver o dinheiro.

Construindo o motor: Features temporais e comportamentais

O segredo de um modelo de risco não está no algoritmo, mas na qualidade dos dados que o alimentam. Em Python, útilizamos a biblioteca Pandas para realizar o Feature Engineering. Transformamos os dados brutos transacionais em indicadores de comportamento.

Velocidade e Recência (Velocity Features)

Fraudadores têm pressa. Um comportamento clássico de conta laranja é receber múltiplos depósitos de origens diferentes em um curto intervalo de tempo, seguido de um saque ou transferência total. Precisamos calcular a velocidade das transações.

Em Python, você construiria variáveis de agregação em janelas de tempo curtas. Exemplo conceitual:

import pandas as pd

# Assumindo um DataFrame 'df' ordenado por timestamp
# Calculando a quantidade de Pix enviados na última hora
df['pix_count_1h'] = df.groupby('account_id')['transaction_amount'].transform(
    lambda x: x.rolling('1H').count()
)

# Somatório do valor enviado nas últimas 24h
df['pix_sum_24h'] = df.groupby('account_id')['transaction_amount'].transform(
    lambda x: x.rolling('24H').sum()
)

A relação entre o valor da transação atual e a média histórica do cliente também é vital. Se um cliente que faz Pix médios de R$ 50 repentinamente tenta transferir R$ 8.000, o modelo precisa acender um alerta.

Análise de Rede e Dispositivo

A geolocalização e o reconhecimento de dispositivo (Device Fingerprinting) mudam o jogo. Se um Pix é originado de um aparelho que nunca acessou aquela conta antes, o risco dispara. Cruzamos isso com a idade da conta. Contas criadas há menos de 72 horas têm uma propensão à fraude exponencialmente maior.

Outra feature matadora é a 'distância geográfica da última transação'. Se o cliente fez um Pix pagando um restaurante em São Paulo às 12h00 e, às 12h15, tenta fazer um Pix com geolocalização registrada em Fortaleza, temos um problema físico óbvio (viagem impossível).

O peso da chave Pix destino

Você precisa avaliar quem está recebendo o dinheiro. A chave Pix de destino é nova? Ela já foi reportada no DICT (Diretório de Identificadores de Contas Transacionais) do BACEN por envolvimento em fraudes anteriores?

Criamos variáveis como is_first_transfer_to_receiver (booleano que indica se o emissor já transferiu dinheiro para aquele recebedor antes). No mundo real, a esmagadora maioria das fraudes ocorre em transferências para contas com as quais a vítima nunca interagiu.

Treinando o modelo de risco (Machine Learning)

Com as features prontas, entra a modelagem. No ecossistema financeiro brasileiro, quando falamos de dados tabulares estruturados e necessidade de baixa latência, o rei indiscutível é o XGBoost (Extreme Gradient Boosting), seguido de perto pelo LightGBM.

Redes neurais profundas (Deep Learning) são fantásticas para imagens e textos, mas frequentemente perdem para algoritmos baseados em árvores de decisão em dados transacionais, além de serem mais pesadas para inferência em tempo real.

Lidando com o desbalanceamento brutal

Fraude é um evento raro. Em uma carteira saudável, menos de 0,1% das transações Pix são fraudulentas. Se você treinar um modelo padrão nesse dataset, ele simplesmente aprenderá a aprovar tudo e terá 99,9% de acurácia (e 100% de falha em pegar fraudes).

Para resolver isso no XGBoost usando Python, não recomendamos técnicas de oversampling artificial como SMOTE, pois elas criam ruídos irreais em dados financeiros complexos. A abordagem profissional é útilizar o parâmetro scale_pos_weight diretamente no algoritmo, que aplica um peso maior aos erros cometidos na classe minoritária (fraude).

import xgboost as xgb
from sklearn.model_selection import train_test_split

# Calculando a proporção para o peso da classe positiva
ratio = float(np.sum(y_train == 0)) / np.sum(y_train == 1)

# Configurando o modelo
model = xgb.XGBClassifier(
    max_depth=5,
    learning_rate=0.05,
    n_estimators=300,
    scale_pos_weight=ratio,
    objective='binary:logistic',
    eval_metric='auc'
)

model.fit(X_train, y_train)

A métrica de avaliação não pode ser Acurácia. Usamos ROC-AUC para medir a capacidade geral de separação do modelo, mas a métrica de negócio real é o Precision-Recall. Focamos no Recall (taxa de captura de fraudes) mantendo a Precision em um nível aceitável para não explodir os falsos positivos.

Arquitetura de decisão em tempo real

Ter um modelo validado em um Jupyter Notebook não serve para nada se ele não puder pontuar uma transação em tempo real. A arquitetura de implantação é onde muitos projetos de Data Science morrem.

Para o fluxo do Pix, o sistema precisa ler o evento, buscar as features históricas do cliente, rodar o modelo e devolver a resposta. Tudo isso enquanto o relógio do BACEN corre.

Na prática, as empresas útilizam Apache Kafka ou AWS Kinesis para ingestão de eventos de mensageria. As features calculadas em lote (como a média de gastos dos últimos 30 dias) ficam armazenadas em bancos de dados em memória, ultrarrápidos, como o Redis. Quando a transação chega, a API em Python (usando FastAPI, por exemplo) puxa o dado do Redis, junta com o dado do evento atual (valor da transação, hora do dia), monta o vetor de features e passa pelo modelo exportado.

Se o score de fraude retornado for alto (ex: > 0.85), a transação é negada com código de erro específico. Se for médio (ex: 0.70 a 0.85), a transação é direcionada para a fila de retenção para análise manual ou para um desafio de autenticação adicional (Step-up authentication, pedindo biometria facial). Se for baixo, a transação segue livre para o SPI.

Implicações práticas para sua operação

Implementar um motor de machine learning próprio muda a dinâmica econômica da sua empresa. Cada fraude evitada é dinheiro direto no caixa (loss avoidance). Mas há um custo invisível e perverso que o modelo combate: o falso positivo.

Se o seu motor de regras atual bloqueia 5 transações legítimas para pegar 1 fraude, você está destruindo o Lifetime Value (LTV) do seu cliente. Um modelo preditivo bem calibrado em Python consegue inverter essa lógica, aumentando a taxa de aprovação (Approval Rate) sem aumentar a inadimplência ou perda por fraudes (Chargeback/MED rate).

Além disso, o regulador está observando. O Banco Central aplica multas pesadas e pode até suspender a licença de operação de participantes do Pix que apresentam índices de fraude acima dos limites aceitáveis. Ter um modelo estatisticamente defensável é um escudo regulatório.

O mercado de pagamentos no Brasil não perdoa amadores. Com a chegada de inovações como o Pix Automático (agendamento recorrente) e o Pix Garantido (crédito), a complexidade das fraudes apenas aumentará. O fraudador já usa automação e scripts para testar vulnerabilidades em larga escala. A única forma de vencer uma máquina é com outra máquina. Construir seu próprio modelo de risco em Python não é mais um diferencial competitivo. É o ingresso básico para continuar operando no mercado financeiro brasileiro.