FraudShield AI

Enterprise Financial Fraud Detection Platform

Detect suspicious financial transactions in real time using an XGBoost machine learning model trained on over 6.3 million PaySim transactions.

⚡ Real-Time AI

🧠 XGBoost ML

📊 PaySim Dataset

🚀 FastAPI Backend

⏳ Checking API…

6.3M+

Transactions

—

Fraud Recall

—

ROC-AUC

Checking model status…

ClassifierXGBoost

Features—

Model version—

Threshold—

Last inference—

Transaction details

🔄 Transaction type

💰 Amount

🏦 Sender balance before

🏦 Receiver balance before

Account & behavior signals read by the model, not just the balances above

⏱ Hours since sender's last transaction

📈 Sender's transactions in last 24h

🆕 Destination account

Quick test scenarios

🛡

No analysis yet

Fill in the transaction above, or load a quick scenario, to see a live risk analysis with model explainability.

📊 Model Insights

Loading live metrics from the API…

📊

Fetching real analytics from GET /model/info…

📖 About FraudShield AI

FraudShield AI is an enterprise-inspired financial fraud detection platform developed using Python, FastAPI, XGBoost, and modern web technologies.

The system analyzes financial transactions in real time using an XGBoost machine learning model trained on 6.3 million+ PaySim transactions, generating fraud probability, confidence scores, risk levels, and explainable insights within milliseconds.

It combines machine learning with an interactive dashboard to help analysts identify suspicious transactions through intelligent risk scoring, interpretable explanations, and business-friendly recommendations.

📂 GitHub Repository 🚀 Live API Docs

⚙️ How It Works

Every transaction moves through the same five-stage pipeline, end to end in under 100ms:

1

Transaction submitted via API

2

10 features engineered (log-scaled balances, drain & anomaly flags, ratios)

3

XGBoost scores fraud probability

4

Risk level assigned (Low → Critical)

5

A rule-based engine writes a plain-English summary

🚧 Limitations & Roadmap

The current model is trained on the synthetic PaySim dataset, which mimics real transaction patterns but isn't real financial data — accuracy numbers here reflect performance on synthetic fraud, not a production population.

Planned next steps:

Validate against a real-world fraud dataset (e.g. IEEE-CIS)
The live decision threshold is 0.984 (F1-optimal on this dataset), not a naive 0.5 cutoff — a cost-weighted alternative (~0.66, under assumed false-positive/false-negative costs) is also computed on every training run but not yet deployed; revisit if the production class balance or cost assumptions shift
Rate limiting and optional API-key auth are already in place — decide when/whether to turn key auth on for the public demo

🛠 Engineering Notes

The debugging and design decisions behind this model — not just the finished pipeline.

🕳 The label leak that produced a 0.9999 AUC

The first version of this model scored a suspicious 0.9999 ROC-AUC. The cause: PaySim's fraud rows always drain the origin account to exactly zero, and the original feature set included newbalanceOrig / newbalanceDest — the account balances after the transaction. The model wasn't learning fraud patterns, it was reading the answer off post-transaction state that wouldn't exist at approval time in a real system. Both fields were dropped entirely.

🔁 Replacing a leaky feature with a prospective one

Rather than lose the signal outright, would_drain_orig replaced the leaky balance fields — computed as oldbalanceOrg − amount, which is known before a transaction is approved. Same underlying idea (does this transaction empty the sender's account), none of the leakage.

🔍 Verifying the replacement wasn't a subtler leak

would_drain_orig alone ended up carrying 57% of feature importance — above the pipeline's own automated 40% dominance warning. Rather than trust that, a verification script cross-tabbed it against the real outcome on the full dataset:

fraud rate @ drain=1: 0.404% fraud rate @ drain=0: 0.0044% 97.7% of fraud has drain=1 only 0.4% of drain=1 rows are fraud

High recall, low precision, no leak: draining the account is common among legitimate large transfers too, so it isn't a near-deterministic label proxy the way the original leak was — it's a strong, honest risk signal on a very rare event, not a shortcut. That's why 57% is trusted rather than treated as a red flag.

🧾 Real metrics, not a hardcoded badge

The README used to carry a static 0.9997 ROC-AUC figure that quietly went stale the moment the leaky features were removed. train.py now writes real metrics to models/metrics.json on every run — precision, recall, F1, the confusion matrix, feature importance, even the ROC/PR curve points — and GET /model/info serves that file directly, so what's shown here can't drift out of sync with what's actually deployed.

⚖️ Two explanations, kept deliberately separate

Every prediction carries both a rule-based summary and real per-prediction SHAP attribution (via XGBoost's native pred_contribs, no extra dependency needed). They're shown as distinct panels on purpose: the rules are fast, deterministic sanity checks; SHAP is what the model itself actually weighed for that specific transaction. Collapsing them into one explanation would hide which kind of "why" you're looking at.

📏 One threshold, two candidates

The deployed decision threshold is 0.984, chosen by max-F1 on the precision-recall curve. A cost-weighted alternative (~0.66) is also computed on every training run, using a simulated cost of 5 for a false positive and 100 for a missed fraud — illustrative numbers picked to demonstrate the mechanism, not figures calibrated against any real review cost or fraud-loss data. Swapping between the two is a one-line config change (THRESHOLD_STRATEGY), deliberately left as an explicit decision rather than silently auto-selected — and a real deployment would replace the cost constants with real numbers before switching to it.

🔖 Model versioning without a database

Every prediction reports a content-hashed model_version — a short SHA-256 of the deployed model file — so it always reflects exactly which weights produced that score, and can't silently drift out of sync the way a manually bumped version string could. An append-only model_registry.jsonl keeps the last several training runs (version, metrics, row counts, timestamp), giving basic rollback / A-B comparison without standing up a database.

☁️ Railway → Render

The backend originally deployed to Railway; after the trial period expired it was migrated to Render's free tier. The tradeoff: Render's free instances spin down after 15 minutes idle, so the first request after a lull takes ~30–50s to wake up — documented in the README and reflected in this UI's own status panel (which retries with backoff rather than reporting "down" during that window).

👨‍💻 Developer

♥ Aarya Shirsath

B.Tech Computer Science Engineering

AI • Machine Learning • Full Stack Development

💻 Tech Stack

Python
FastAPI
XGBoost
HTML
CSS
JavaScript

🎯 Project Goal

FraudShield AI is an intelligent fraud detection platform that analyzes financial transactions in real time using Machine Learning to identify suspicious activities and improve financial security.

🚀 Highlights

✔ Built on the PaySim financial transaction dataset (6.3M+ records)

✔ Real-time fraud prediction using XGBoost

✔ Automated, rule-based transaction explanations

✔ REST API powered by FastAPI

✔ Modern responsive frontend using HTML, CSS & JavaScript

🛡 FraudShield AI • Real-Time Financial Fraud Detection

Designed & Developed by Aarya Shirsath