Treinei seis modelos de detecção de fraude — e o melhor deles não está em produção

Um projeto de fim de curso se transformou em uma lição valiosa sobre a distância entre métricas de avaliação e decisões de produção. O engenheiro Benjamin Nweke treinou seis modelos de machine learning para detectar fraude em transações bancárias usando o mesmo conjunto de dados, registrou cada execução — e descobriu que o modelo com as melhores métricas não é o que está rodando em produção.

O projeto NairaShield

O NairaShield é um sistema de detecção de fraude baseado em IA, construído como projeto de conclusão de curso. Começou como um problema clássico de classificação e terminou como um pipeline de apoio à decisão. A virada veio do orientador, que enxergou semelhança com um projeto de combate à lavagem de dinheiro de um colega e empurrou o autor a ir além do algoritmo: pensar no que acontece depois que uma transação é sinalizada.

O treinamento uniu dois conjuntos públicos com esquemas incompatíveis — PaySim (simulação de dinheiro móvel) e IEEE-CIS — mapeados para um esquema único. Como fraude é rara nos dois datasets, o autor usou SMOTE para sobreamostrar a classe minoritária apenas no split de treino, com fallback de interpolação manual quando a biblioteca não estava disponível.

Seis modelos, uma planilha que se contradiz

Foram treinados Random Forest, Regressão Logística, XGBoost (baseline e ajustado) e LightGBM (baseline e ajustado), todos passando pelo mesmo helper de avaliação para que os números fossem comparáveis. Os resultados revelaram três pontos nem sempre óbvios:

• A Regressão Logística teve o maior recall (0,95), mas também a pior precisão (0,14) — a maioria dos casos sinalizados era falso positivo.
• Ajustar o XGBoost melhorou levemente o AUC-PR, mas piorou a precisão em relação ao baseline.
• O LightGBM baseline foi o melhor em AUC-PR de todos — mas a API de produção continua usando o XGBoost (ajustado), escolhido antes de a comparação do LightGBM ser concluída.

O desfecho é o coração do artigo: o modelo no topo do ranking não é o que toma as decisões. É uma decisão que, olhando agora, o autor admite que “vale revisitar”.

Explicabilidade e o que vem depois do alerta

Para tornar os números auditáveis, cada predição sinalizada carrega uma explicação SHAP com as features que empurraram o caso para fraude — porque “o modelo disse que sim” não é resposta que banco ou regulador aceite. E, atendendo ao pedido do orientador, o sistema ganhou um Centro de Notificação Regulatória: uma camada de revisão com perfis inspirados no Banco Central da Nigéria, no EFCC e no NDIC, cada um com login próprio e fila de transações sinalizadas.

A confiança não é tratada como sim/não. O limiar base é 0,50, mas o que vem depois se divide em faixas: abaixo de 0,50 passa sem alarme; entre 0,50 e 0,80 fica sinalizado mas não bloqueado, indo para verificação OTP; de 0,80 para cima bloqueia; e em 0,85 um alerta imediato sai por SMS ou e-mail em uma thread em segundo plano.

O que aprender com isso

O projeto ilustra uma verdade prática para quem trabalha com dados: hiperparâmetros otimizam a métrica que você apontar, não necessariamente a que importa quando o modelo toma decisões reais. Em detecção de fraude, recall alto com precisão baixa significa equipes de revisão afogadas em falsos positivos. A escolha de produção raramente é sobre o melhor score — é sobre custo de erro, explicabilidade e fluxo de trabalho regulatório.