Case Study · Machine Learning

FraudShield ML Platform

An end-to-end machine learning platform for detecting fraudulent financial transactions and supporting risk-based fraud review workflows. Built on the IEEE-CIS Fraud Detection dataset (590,000+ transaction records), it goes beyond a notebook model to a full production-style system: data pipeline, threshold optimization, explainability, and a deployable FastAPI/PostgreSQL architecture.

April 2026 – June 2026 PythonXGBoostFastAPIPostgreSQLSHAPDocker
01

goal

Identify fraudulent transactions in highly imbalanced financial data while balancing two competing business priorities: catch as many fraudulent transactions as possible, without overwhelming analysts with excessive false positives.

Because fraud is rare, the project doesn't rely on accuracy alone. Instead, model performance is evaluated on fraud-class precision, recall, F1, ROC-AUC, PR-AUC, false-positive rate, and top-k fraud ranking.

02

results

590K+
TRANSACTIONS ANALYZED
88%+
FRAUD RECALL
<10%
FALSE-POSITIVE RATE
0.907
ROC-AUC
Threshold is a business tradeoff, not a fixed number. Early tuning explored two candidate thresholds: a strict one (0.425) catching 73.1% of fraud at a 9.31% false-positive rate, and a business-oriented one (0.325) catching 80.4% at 14.77% FPR. Further threshold tuning on the production configuration pushed this further, landing on 88%+ fraud recall while keeping the false-positive rate under 10%. Among the highest-risk transactions, precision is even stronger: 100% on the top 10, 92% on the top 100.
03

threshold_sweep

Moving the decision threshold trades recall against false positives. Watch it sweep from the strict candidate through business-oriented to the final production setting.

Strict · 73.1% recall · 9.31% FPR
Business · 80.4% recall · 14.77% FPR
Production · 88%+ recall · <10% FPR
04

ml_workflow

1

Data Exploration

Inspected dataset size, feature types, fraud class distribution, missing values, duplicate records, and the imbalance between legitimate and fraudulent transactions in the IEEE-CIS dataset.

2

Data Cleaning

Removed duplicates, dropped columns with extremely high missingness, filled missing numerical values with medians and missing categorical values with "Unknown." Cleaned data saved to Parquet (FastParquet) for faster reloads during experimentation.

3

Baseline Modeling

Logistic Regression baseline established a reference point: 0.09 precision, 0.79 recall, 0.16 F1, 0.829 ROC-AUC, 0.189 PR-AUC.

4

XGBoost Modeling

Boosted trees suit the nonlinear, imbalanced, tabular nature of fraud data, giving a significant improvement over Logistic Regression, especially on PR-AUC and F1.

5

Feature Engineering

  • Transaction hour, day, and week
  • Night-transaction flag
  • Log-transformed transaction amount
  • Round-amount and high-amount indicators
  • Card-frequency features
  • Email-domain indicators (Gmail, Yahoo, Hotmail, Outlook)
  • Address-match signal
6

Hyperparameter Tuning

Best configuration: n_estimators=300, max_depth=8, learning_rate=0.05, subsample=0.8, colsample_bytree=0.8, plus class-imbalance weighting via scale_pos_weight.

7

Threshold Optimization

Evaluated multiple decision-threshold strategies instead of defaulting to 0.50, including a strict false-positive-rate candidate (0.425 · 73.1% recall · 9.31% FPR) and a business-oriented candidate (0.325 · 80.4% recall · 14.77% FPR). Further tuning on the production configuration improved on both candidates, reaching 88%+ fraud recall while keeping the false-positive rate under 10%.

8

Explainability

XGBoost feature importance and SHAP explanations: global importance, bar/beeswarm/waterfall plots for individual high- and low-risk transactions, and top-k fraud ranking analysis, so analysts see why a transaction is flagged, not just that it is.

05

architecture

Raw Transaction Data ↓ Data Cleaning and Validation ↓ Feature Engineering ↓ XGBoost Fraud Model ↓ Threshold Optimization ↓ Saved Model Artifacts ↓ FastAPI Prediction Service ↓ PostgreSQL Database ↓ Fraud Alert Dashboard ↓ Analyst Review Workflow
06

schema

This design tracks not just predictions, but which model generated them, what threshold was used, and how alerts were handled. Every alert is traceable back to the exact model run that produced it.

07

stack

ML & Data Science
Python, Pandas, NumPy, Scikit-learn, XGBoost, SHAP, Matplotlib, Jupyter, FastParquet
Backend & API
FastAPI, Pydantic, REST API design, Joblib for model loading, JSON model metadata
Database
PostgreSQL, relational schema, SQL indexes across transactions, predictions, alerts, customers, model runs
Deployment
Docker, Docker Compose, Git/GitHub, environment-based configuration, containerized API + database services
Dashboard
Streamlit/React fraud-risk scoring interface, alert tracking, model-version history, prediction history
08

learnings

Imbalanced classification, ROC-AUC vs. PR-AUC, precision-recall tradeoffs, threshold tuning, XGBoost hyperparameter tuning, feature engineering for tabular data, model explainability with SHAP, PostgreSQL schema design for ML applications, and how to move from notebook experimentation to deployable, production-style software.