Credit Card Fraud Detection using Isolation Forest

Card fraud is a needle-in-a-haystack problem: in the well-known ULB dataset, only 492 of 284,807 transactions are fraudulent — 0.172%. Rule-based systems drown in false alarms, and supervised classifiers struggle because fraud patterns mutate while labeled examples stay rare. Anomaly detection flips the problem: instead of learning what fraud looks like, learn what normal looks like and flag what doesn't fit. Isolation Forest does this elegantly — it recursively partitions transactions on random features, and anomalies get isolated in far fewer splits than normal points, no labels required. This project implements that idea end to end: preprocessing of the ULB schema (Time, PCA-anonymized V1–V28, Amount), an Isolation Forest trained on legitimate transactions, contamination-based threshold tuning, and a monitoring dashboard with an anomaly map, alert feed and precision/recall tradeoff explorer. The report is honest about the hard parts — extreme imbalance, uninterpretable PCA features and concept drift — which is exactly what makes it strong viva material.

1. The ULB creditcard.csv is loaded; Time and Amount are standardized, V1–V28 used as-is (already PCA-scaled).
2. Data is split with stratification so the tiny fraud fraction is preserved in validation and test sets.
3. IsolationForest fits 200 random trees on legitimate transactions: each tree splits random features at random values until points isolate.
4. Each transaction's mean path length converts to an anomaly score — near 1 for anomalies, near 0.5 for normal.
5. A contamination fraction sets the score threshold; transactions above it are flagged.
6. The dashboard streams scored transactions, plots them on the anomaly map and routes high scores to the alert feed.

Tech stack:

• Python 3.10, scikit-learn (IsolationForest, metrics, train_test_split)
• pandas, NumPy (ULB schema handling, scaling, ledger tables)
• Matplotlib, Seaborn (score distributions, ROC/PR curves, anomaly maps)
• Flask dashboard (live monitor, transaction ledger, threshold tuner)
• Jupyter notebook (buyer-run training, threshold tuning, evaluation)
• ULB Credit Card Fraud Detection dataset (Kaggle mlg-ulb/creditcardfraud)

• [ULB dataset pipeline] Loading, scaling and stratified splitting of the 284,807-transaction Kaggle set, with the 0.172% fraud rate and PCA-anonymized V1–V28 schema documented.
• [Isolation Forest training] scikit-learn IsolationForest (200 trees, subsample 256) trained on legitimate transactions only — genuinely unsupervised, no fraud labels used in fitting.
• [Anomaly scoring API] Per-transaction scores in [0, 1] from mean path length, with median scoring latency measured in the notebook.
• [Live monitoring dashboard] Anomaly map over V1–V2, KPI cards, and a streaming alert feed showing flagged transactions as they arrive.
• [Transaction ledger] Sortable, filterable table of scored transactions with verdicts (fraud / review / legitimate) and score pills.
• [Threshold tuner] Contamination slider that moves the decision threshold live, showing how flagged counts, precision and recall trade off.
• [Evaluation notebook] Precision, recall, F1, ROC-AUC and PR curves computed on the held-out split during your build — no pre-claimed numbers anywhere.
• [Concept-drift discussion] The report covers why a 2013-trained model decays on new fraud patterns and how retraining windows address it.

• Complete source code (preprocessing, forest training, scoring API, Flask dashboard)
• Jupyter training and evaluation notebook (buyer-run: tuning, threshold selection, full metric computation)
• Project report PDF (background, algorithm theory, imbalance handling, evaluation, drift discussion)
• PPT presentation for final review
• Viva Q&A preparation document (isolation principle, contamination, precision vs recall, PCA features)
• Setup guide (environment, downloading the ULB dataset from Kaggle, running the dashboard)

• V1–V28 are PCA-transformed for cardholder confidentiality, so the model (and the analyst) cannot interpret what a "high V14" means in business terms — the report states this as a fundamental explainability limit.
• With only 0.172% fraud, precision is inherently painful: even a good detector produces false alarms, and the threshold tuner exists precisely to make that tradeoff visible rather than hidden.
• No accuracy or precision numbers are pre-claimed: every metric in the report comes from the notebook run on your own held-out split during your build.
• The dataset covers two days in September 2013 — fraud tactics have evolved since, so the model demonstrates the method, not a deployable 2026 fraud system; the report's drift section covers this.
• This is a transaction-scoring prototype, not a payment integration — it does not connect to gateways, block cards or handle real money.