🛡️ Detecção de Fraude em Transações (IEEE-CIS)

Pipeline de Machine Learning para identificar transações fraudulentas em dados financeiros reais e fortemente desbalanceados, combinando um modelo supervisionado (LightGBM) com detecção de anomalia não-supervisionada (Isolation Forest). O projeto é avaliado com as métricas corretas para fraude (PR-AUC, e não acurácia) e escolhe o limiar de decisão por custo de negócio.

Por que isso importa: detecção de fraude é um dos maiores casos de uso de dados em fintechs e bancos (Nubank, Stone, Mercado Pago, Itaú…). O desafio não é "acertar na média" — é encontrar ~3,5% de fraudes escondidas em centenas de milhares de transações legítimas sem irritar o cliente bom com falsos positivos. Acurácia aqui é uma armadilha: um modelo que chuta "tudo legítimo" acerta 96,5% e não serve para nada.

❓ Perguntas de negócio

1. Quais sinais mais separam uma transação fraudulenta de uma legítima?
2. Qual modelo entrega o melhor recall de fraude sem disparar bloqueios demais?
3. Onde posicionar o limiar de decisão para minimizar o custo financeiro total?
4. Um detector não-supervisionado consegue pegar fraudes que o supervisionado perde?

📊 Dados

• Fonte: IEEE-CIS Fraud Detection (Vesta Corporation, via Kaggle)
• 590.540 transações, 433 colunas em duas tabelas (transaction + identity) unidas por TransactionID
• Alvo isFraud desbalanceado: 3,5% de fraude (~28 legítimas para cada fraude)
• Mistura de features interpretáveis (valor, produto, cartão, e-mail, dispositivo) e anonimizadas (V*, C*, D*, M*); dataset esparso (215 colunas com >50% de nulos)

Os dados não são versionados (ver .gitignore). Use python src/baixar_dados.py.

🔬 Metodologia

• Validação temporal: split treino/validação por TransactionDT (80/20) — em fraude, o futuro não pode vazar para o passado.
• Desbalanceamento: avaliação por PR-AUC, precision@k e recall — nunca acurácia.
• Modelo supervisionado: LightGBM (trata nulos e categóricas nativamente).
• Modelo não-supervisionado: Isolation Forest, medindo o quanto se detecta sem rótulo.
• Decisão por custo: o limiar é escolhido minimizando o custo esperado (fraude perdida × bloqueio indevido), não fixado em 0,5.
• Explicabilidade: SHAP para entender por que o modelo sinaliza cada transação.

📈 Resultados

Desempenho dos modelos (conjunto de validação — futuro)

Modelo	PR-AUC	ROC-AUC
LightGBM (supervisionado)	0,586	0,924
Isolation Forest (não-supervisionado)	0,103	0,731
Baseline (acaso = prevalência)	0,034	0,500

O LightGBM tem PR-AUC ~17× melhor que o acaso. O detector não-supervisionado, mesmo sem usar o rótulo, fica 3× acima do acaso — confirma que fraude é anômala, mas perde para o modelo supervisionado (fica como camada complementar).

Decisão por custo: o limiar não é 0,5

Cada erro custa diferente: uma fraude que passa perde o valor da transação; um bloqueio indevido custa atrito com o cliente. Varrendo o limiar para minimizar o custo total, o ótimo fica em 0,019 — muito abaixo do 0,5 ingênuo:

Métrica no limiar ótimo	Valor
Recall (fraudes capturadas)	83,1%
Precisão dos alertas	18,6%
precision@1% (fila de revisão)	90,9%
Economia vs. limiar 0,5	US$ 276 mil (−61%)

Em outras palavras: ajustar o limiar pelo custo de negócio reduz o prejuízo em 61% frente ao corte padrão, capturando 83% das fraudes.

Por que o modelo decide (SHAP)

As features mais influentes são coerentes com a EDA: o tipo de cartão (card6: crédito > débito), o valor, os contadores C* da Vesta e os domínios de e-mail.

Insights da EDA

A fraude tem um padrão temporal forte (dispara na madrugada/manhã) e se concentra em certos produtos (o produto C tem 11,7% de fraude vs. 2,0% do produto W):

🗂️ Estrutura do projeto

DeteccaoFraude/
├── data/
│   ├── raw/            # CSVs do Kaggle (gitignored)
│   └── processed/      # parquet preparado (gitignored)
├── notebooks/
│   ├── 01_eda.ipynb           # análise exploratória (+ versão .py jupytext)
│   └── 02_modelagem.ipynb     # modelagem, métricas, custo, SHAP
├── src/
│   ├── baixar_dados.py        # download do dataset via Kaggle API
│   ├── preparar_dados.py      # merge + feature engineering
│   └── treinar_modelos.py     # treino e serialização dos modelos
├── models/             # lgbm_fraude.joblib, isolation_forest.joblib, metadados.json
├── reports/figures/    # gráficos
├── requirements.txt
└── README.md

▶️ Como reproduzir

# 1. Ambiente
python -m venv .venv
.venv\Scripts\activate          # Windows
pip install -r requirements.txt

# 2. Credenciais do Kaggle (uma vez só)
#    kaggle.com -> Settings -> API -> "Create New API Token"
#    salve o token em ~/.kaggle/ (kaggle.json ou access_token) e aceite
#    as regras em kaggle.com/competitions/ieee-fraud-detection/rules

# 3. Pipeline
python src/baixar_dados.py      # baixa os dados
python src/preparar_dados.py    # merge + features -> data/processed/
python src/treinar_modelos.py   # treina e salva os modelos

# 4. Notebooks: notebooks/01_eda.ipynb e notebooks/02_modelagem.ipynb

🧰 Stack

Python · pandas · scikit-learn · LightGBM · Isolation Forest · SHAP · imbalanced-learn · Matplotlib/Seaborn

---

Projeto de portfólio em Ciência de Dados — github.com/augmatos