Credit Card Fraud Detection using Machine Learning

Credit card fraud is a needle-in-a-haystack problem: in the standard public dataset, only 492 of 284,807 transactions are fraudulent — 0.172%. A model that predicts "legitimate" every time scores 99.83% accuracy and catches nothing, which is exactly why this project is such a good teacher: it forces honest evaluation. This project trains an XGBoost fraud scorer on the Kaggle credit-card dataset, handles the imbalance with SMOTE on the training fold plus class weighting, evaluates with PR-AUC and recall-at-fixed-precision instead of accuracy, and derives a block/step-up/clear threshold policy from the validation fold. The web demo scores any entered transaction and explains the top risk signals — unusual amount, card-not-present channel, rapid repeats, distance from home. The methodology is documented for the viva, including why accuracy is banned from the report.

1. The 284,807 transactions are loaded (V1–V28 PCA features, Time, Amount, Class); Amount is log-scaled and Time is converted to hours.
2. Data is split with stratification and time-awareness: the test fold preserves the natural 0.172% fraud rate.
3. SMOTE oversampling is applied to the training fold only, combined with XGBoost's scale_pos_weight.
4. An XGBoost classifier (300 trees, max depth 6) is trained with stratified 5-fold cross-validation.
5. The test fold is scored once: PR-AUC, ROC-AUC, and recall at 90/95% precision are computed — accuracy is reported only to demonstrate why it is meaningless here.
6. Validation-fold analysis sets the policy thresholds: ≥0.80 auto-block, 0.50–0.80 step-up authentication, <0.50 clear.
7. In the web demo, an entered transaction is featurized identically and the saved model returns the fraud probability with ranked risk-signal contributions.

Tech stack:

• Python 3, XGBoost, scikit-learn
• imbalanced-learn (SMOTE)
• Kaggle credit-card-fraud dataset
• pandas, NumPy, Matplotlib
• Jupyter Notebook (training)
• HTML/CSS/JavaScript (scorer demo)

Dataset & model details

• Dataset: Credit Card Fraud Detection (Kaggle) — 284,807 transactions from European cardholders over two days in September 2013, 492 frauds (0.172%). Features V1–V28 are PCA-anonymized; Time and Amount are given. Released by the ULB Machine Learning Group.
• Task: Binary classification; input = 30 features (V1–V28, time, log-amount), output = fraud probability.
• Model: XGBoost — 300 trees, max depth 6, learning rate 0.05, scale_pos_weight set from the imbalance ratio, SMOTE applied to the training fold.
• Metrics: PR-AUC ~0.97 (design target for the built-to-order training run), recall at 95% precision, ROC-AUC. Accuracy is deliberately excluded as a success metric. No metric is claimed as measured until the training run is executed for the order.

• [Imbalance-first methodology] SMOTE on the training fold only, class weighting, and stratified time-aware splits — the test fold keeps the natural 0.172% fraud rate.
• [Live fraud scorer demo] Enter amount, merchant, channel and context; get a fraud probability with the top contributing risk signals explained.
• [PR-curve evaluation] Precision-recall AUC as the primary metric, with recall reported at 95% precision — the operating language of real fraud teams.
• [Threshold policy] Block / step-up-auth / clear thresholds tuned on the validation fold and documented with their precision-recall tradeoffs.
• [XGBoost model] 300 gradient-boosted trees on the 28 PCA features plus time and log-amount, benchmarked against logistic regression.
• [Full training notebook] Preprocessing, SMOTE, model training, cross-validation and metric plots in one reproducible notebook.
• [Flagged-transaction view] The demo shows a realistic operations table of scored transactions with actions taken.

• Complete training & evaluation Jupyter notebook
• Trained XGBoost model file with preprocessing pipeline
• Fraud scorer web demo (score, explanations, operations table)
• PR/ROC curves, threshold analysis and calibration plots
• Project report PDF (background, imbalance theory, methodology, results)
• PPT presentation for final review
• Viva Q&A preparation document (SMOTE, PR-AUC vs accuracy, thresholds, PCA features)

• ~0.97 PR-AUC is a design target for the training run, stated honestly — the report documents the actual achieved figure.
• V1–V28 are PCA-anonymized, so feature-level explanations use transaction context (amount, channel, velocity) rather than raw feature meanings.
• The data covers two days in 2013; real deployments face concept drift and need retraining pipelines, discussed in the report.
• The demo scores single transactions; production systems also use sequence and graph features, listed as future scope.
• Blocking thresholds trade fraud caught against customer friction — the report quantifies both sides.