Fraud Sentinel: detecção de fraudes com Machine Learning, Deep Learning e análise de anomalias
- #Machine Learning
- #Python
- #FastAPI
Detectar fraudes em cartões de crédito parece, à primeira vista, um problema comum de classificação: receber uma transação e decidir se ela é legítima ou fraudulenta. Na prática, o desafio é muito mais interessante. Quando apenas uma fração mínima dos registros pertence à classe que realmente importa, um modelo pode alcançar mais de 99% de acurácia sem detectar uma única fraude.
Foi a partir desse cenário que desenvolvi o **Fraud Sentinel**, um sistema ponta a ponta para detecção de anomalias e fraudes em transações de cartão de crédito. O projeto combina engenharia de dados, machine learning supervisionado, métodos de detecção de novidade, deep learning, API REST, dashboard interativo e relatórios automáticos.
O código-fonte e toda a documentação estão disponíveis no [repositório do projeto no GitHub](https://github.com/davidsonsilva/desafio-dio-fraudes-cartao-credito).
O problema: encontrar 492 fraudes em quase 285 mil transações
O projeto utiliza o dataset público [Credit Card Fraud Detection](https://www.kaggle.com/datasets/mlg-ulb/creditcardfraud), composto por **284.807 transações**, das quais somente **492 são fraudes**. Isso representa aproximadamente **0,173%** do total.
Esse desbalanceamento muda completamente a forma de desenvolver e avaliar a solução. A acurácia deixa de ser uma métrica confiável, porque a classe majoritária domina o resultado. Por isso, defini como indicadores principais:
- **PR-AUC**, para medir a qualidade do ranking em uma classe positiva rara;
- **recall**, para observar quantas fraudes foram efetivamente detectadas;
- **precisão**, para controlar o volume de falsos alertas;
- **F1**, para equilibrar precisão e recall;
- **matriz de confusão**, para entender o impacto operacional das decisões.
Mais do que treinar um classificador, o objetivo foi construir um processo reproduzível e auditável, capaz de comparar abordagens diferentes sob o mesmo contrato de dados.
Uma arquitetura ponta a ponta
Estruturei o sistema para que treinamento e inferência compartilhassem exatamente as mesmas transformações. O fluxo começa com a validação do dataset, passa pela divisão estratificada entre treino e teste, cria novas variáveis, aplica escalonamento e treina dez modelos.
O melhor modelo é selecionado com base em PR-AUC e F1. Em seguida, o pipeline salva um artefato versionado contendo:
- o modelo vencedor;
- a engenharia de features ajustada;
- o scaler utilizado;
- o limiar de decisão;
- as colunas esperadas na entrada;
- as métricas dos dez modelos;
- informações sobre o dataset e a versão do artefato.
Esse mesmo arquivo é consumido pela linha de comando, pela API FastAPI e pelo dashboard Streamlit. Assim, não existem três implementações diferentes da lógica de previsão.
Engenharia de mais de 100 features
As transações originais possuem `Time`, `Amount` e 28 variáveis anonimizadas resultantes de PCA. A partir dessas entradas, implementei mais de 100 features derivadas.
Entre as principais transformações estão:
- representação cíclica do horário por seno e cosseno;
- identificação do período noturno;
- transformações logarítmica e quadrática do valor;
- análise de centavos e valores arredondados;
- interações entre valor e variáveis PCA;
- módulo e quadrado de `V1` a `V10`;
- interações par a par entre as primeiras variáveis PCA;
- média, desvio-padrão, máximo absoluto e norma L2 das 28 componentes.
Depois da engenharia de features, uso o `RobustScaler`, que é menos sensível a valores extremos do que uma padronização convencional.
Um cuidado importante foi ajustar todas as transformações somente com o conjunto de treino. Dessa forma, informações do teste não vazam para o treinamento.
Dez modelos, três estratégias de desbalanceamento
Em vez de depender de um único algoritmo, construí um catálogo com dez abordagens supervisionadas e não supervisionadas:
1. Regressão Logística;
2. Random Forest;
3. Extra Trees;
4. HistGradientBoosting;
5. XGBoost;
6. rede neural TensorFlow/Keras;
7. Isolation Forest;
8. Local Outlier Factor;
9. One-Class SVM;
10. PCA por erro de reconstrução.
O tratamento do desbalanceamento varia conforme o tipo de estimador.
Os modelos clássicos do scikit-learn utilizam **SMOTE**, aplicado somente ao conjunto de treino. O XGBoost recebe `scale_pos_weight`, calculado a partir da proporção entre classes. A rede neural Keras é treinada com class weights e early stopping. Já os modelos de novidade aprendem apenas com transações normais.
Essa separação evita uma prática problemática: aplicar simultaneamente reamostragem e pesos de classe sem avaliar se as duas correções estão amplificando demais a classe minoritária.
Um threshold adaptado ao problema
Classificadores normalmente utilizam 0,5 como limiar padrão. Em detecção de fraude, esse valor raramente representa o melhor equilíbrio operacional.
No Fraud Sentinel, cada modelo gera um score contínuo. A partir da curva precision-recall, o sistema procura o threshold que maximiza F1 entre os pontos que atendem a um recall mínimo configurável. Quando a restrição não pode ser atingida, o melhor F1 disponível é utilizado.
Com isso, o limiar deixa de ser uma constante arbitrária e passa a fazer parte do processo de calibração.
Da experimentação para uma aplicação utilizável
Quis evitar que o resultado terminasse apenas em um notebook. Por isso, disponibilizei diferentes formas de utilizar o modelo.
Dashboard com Streamlit
O dashboard apresenta o modelo selecionado, a quantidade de features, o limiar e o número de fraudes utilizadas no treinamento. Também permite enviar um CSV, classificar várias transações, ordenar os maiores riscos e exportar os resultados.
Dashboard do Fraud Sentinel após o treinamento demonstrativo
Na execução demonstrativa registrada acima, a regressão logística foi selecionada entre os dez modelos, com **111 features** e **50 exemplos fraudulentos sintéticos**. Esses números validam a integração técnica, mas não devem ser interpretados como desempenho final no dataset real.
API REST com FastAPI
A API utiliza Pydantic para validar as 30 variáveis de entrada e oferece endpoints para:
- verificar a saúde do serviço;
- consultar informações do modelo;
- classificar uma transação;
- classificar lotes de até mil transações;
- registrar feedback confirmado.
A documentação OpenAPI é gerada automaticamente e pode ser testada pelo Swagger UI.
Relatórios em PDF
O projeto também gera um relatório dinâmico com a comparação dos modelos, métricas, threshold e informações do treinamento. Além dele, produzi um relatório técnico versionado com a arquitetura e as decisões de desenvolvimento.
Autoaprendizado sem perder rastreabilidade
Um sistema de fraude precisa evoluir quando surgem novos padrões, mas atualizar o modelo silenciosamente após cada feedback seria arriscado.
Por isso, o endpoint de feedback apenas registra transações confirmadas em um arquivo auditável. Esses exemplos são incorporados ao próximo ciclo de treinamento com o dataset real. O modelo ativo continua imutável até que um novo treinamento seja executado e validado.
Essa abordagem é menos automática, mas muito mais segura e explicável.
O que aprendi com o projeto
O principal aprendizado foi que trabalhar com dados desbalanceados exige decisões em várias camadas. Não basta adicionar SMOTE e continuar usando acurácia como critério.
Foi necessário pensar em:
- métricas coerentes com a raridade da classe positiva;
- prevenção de vazamento de dados;
- estratégias específicas para cada família de modelo;
- calibração do limiar;
- custo de falsos positivos e falsos negativos;
- compartilhamento consistente das transformações;
- persistência e versionamento do artefato;
- separação entre feedback coletado e modelo publicado.
Também ficou evidente o valor de transformar um experimento de data science em um produto verificável. A API, o dashboard, os testes e os relatórios tornam o projeto mais fácil de demonstrar, revisar e evoluir.
Limitações e próximos passos
O Fraud Sentinel é um projeto educacional e não uma solução pronta para operar decisões financeiras reais.
Entre as principais limitações estão:
- as variáveis PCA são anonimizadas, o que restringe explicações semânticas;
- a demonstração utiliza uma divisão estratificada aleatória, enquanto produção deveria considerar validação temporal;
- ainda não existe monitoramento automático de data drift e concept drift;
- o feedback precisaria de autenticação, autorização e revisão humana;
- latência, throughput e custo precisariam ser medidos no ambiente de implantação.
Como evolução, pretendo explorar explicabilidade com SHAP, rastreamento de experimentos, validação temporal e monitoramento contínuo da distribuição dos scores.
Tecnologias utilizadas
O projeto foi desenvolvido com:
- Python;
- pandas e NumPy;
- scikit-learn e imbalanced-learn;
- XGBoost;
- TensorFlow/Keras;
- FastAPI e Pydantic;
- Streamlit;
- ReportLab;
- pytest e Ruff.
Conclusão
O Fraud Sentinel mostra como um problema clássico de data science pode ser tratado como um sistema completo. O projeto vai da validação dos dados à inferência, passando por engenharia de features, comparação de modelos, calibração, API, interface e documentação.
Mais do que encontrar o algoritmo com a melhor métrica, o trabalho foi construir uma solução consistente, reproduzível e honesta sobre seus resultados e limitações.
Se quiser conhecer a implementação, executar o modo demonstrativo ou consultar o relatório técnico, acesse o projeto no GitHub:
https://github.com/davidsonsilva/desafio-dio-fraudes-cartao-credito
