FraudShield: Real-Time Payment Fraud Detection

Real-time card fraud scoring that catches 99% of fraud at a 0.3% false-alarm rate, explains every decision, and retrains the moment fraudsters change tactics.

Comment

Overview

FraudShield scores card payments in real time and decides approve, review or block. It keeps false alarms low, explains every decision, and adapts when a new fraud pattern appears. It answers DN-FN-01 (Real-Time Payment Fraud Detection).

Problem statement

Fraud teams lose in three ways: fraud they miss, good customers they wrongly block, and drift. Fraudsters change tactics, and a model trained last quarter goes blind to this quarter's pattern. Most demos optimise one accuracy number. We treat all three costs together.

Solution and methodology

  • Data: a synthetic portfolio of 80,000 card payments over 60 days with a 2% fraud rate and four typologies: account takeover, card testing, night cash-out, and a new mobile-travel pattern that only appears from day 45. It is synthetic because no real payment data was available, and we say so everywhere.
  • Features (causal only): per-card velocity over 1h and 24h, amount vs. the card's running average, geo mismatch, new device, merchant risk, hour, and account age. Only information available at payment time is used.
  • Model: class-balanced gradient boosting (HistGradientBoosting) blended with an Isolation Forest, so behaviour never seen in training still raises the score.
  • Validation: strictly time-ordered: train (first 65%), validation (65–75%), test A (75–87.5%), test B (87.5–100%). The threshold is chosen on validation only, to minimise missed fraud dollars plus $5 per manual review.
  • Drift: a static model trained on early data vs. an adaptive model retrained once test-A labels arrive.
  • Explainability: per-transaction occlusion attribution on the log-odds scale, plus permutation importance globally.

Demonstration

The dashboard (see video and live link) has:

  • Overview: the headline finding, KPIs, recall by fraud typology (static vs. adaptive), PR curve, feature importance.
  • Alert queue: every flagged payment with filters. Open one to see why it was flagged and record a verdict. Verdicts persist and become the labels for the next retrain.
  • Score a payment: enter any payment or load a preset and get approve, review or block with reasons. Inputs are validated server-side.
  • Threshold & cost: drag the threshold and watch fraud stopped, false alarms and total cost update.
  • Fairness: false-positive rate and recall by channel and home country.

API: GET /api/metrics · GET /api/stream · GET /api/explain/<txn_id> · POST /api/review/<txn_id> · POST /api/score

Impact and validation

On the final, unseen period (test B), the adaptive model:

  • catches 99.2% of fraud at 92.2% precision, with 30 false alarms in 9,644 genuine payments (0.31% FPR)
  • reaches PR-AUC 0.991 (random baseline 0.036)
  • stops $78.5k of $78.6k fraud, for a total cost (missed fraud + reviews) of $310, vs. $45,186 for the static model

On the new mobile-travel pattern, the static model's recall is 1.6%. After one retrain it is 100%. Fairness: false-positive rates stay under 1% for every channel and home country with enough data. No protected attributes are used.

Caveats: this is a single synthetic dataset with one random seed, and the drift scenario is constructed. The near-perfect adaptive recall shows that the retraining loop works. It is not a real-world benchmark.

Team contributions

Built by KingDavid Onoja: synthetic data generator, feature engineering, models, time-ordered validation and drift experiment, explainability, fairness analysis, the Flask API, the analyst dashboard, and deployment.

Built With

Share this project:

Updates

Submission history