Fraud detection identifies malicious transactions or behaviors among legitimate ones. It is an adversarial problem - fraudsters actively adapt to your defenses. Success requires real-time scoring, extreme class imbalance handling, and continuous model updates.

Where It Is Used

Fraud detection protects revenue and trust across industries:

Payments: Credit card fraud, unauthorized transactions
Banking: Account takeover, money laundering, synthetic identity
E-commerce: Promo abuse, fake reviews, return fraud
Insurance: Claims fraud, staged accidents
Advertising: Click fraud, impression fraud, attribution fraud
Gaming: Cheating detection, bot accounts

Products: Stripe Radar, PayPal risk engine, Visa Advanced Authorization, Amazon fraud prevention.

Typical Data You Will See

Aspect	Typical Values
Transaction volume	10K to 100M transactions/day
Fraud rate	0.01% to 1% of transactions
Latency requirement	< 100ms for real-time scoring
Features	100 to 1000+ signals
Label delay	Hours to weeks for confirmed fraud

Common table structure:

txn_id | user_id | amount | merchant | device | ip | timestamp | is_fraud

Feature categories: - Transaction attributes (amount, type, location) - User history (velocity, patterns, tenure) - Device/network signals (fingerprint, IP reputation) - Behavioral biometrics (typing patterns, mouse movements) - Graph features (network connections, shared attributes)

What You Do in Practice

Define fraud types - What counts as fraud? Different models for different fraud types?
Establish label quality - How is fraud confirmed? What is the label delay?
Build feature pipeline - Real-time and batch features with consistent computation
Handle class imbalance - Sampling strategies, loss functions, threshold tuning
Train initial model - Gradient boosting with engineered features
Add graph features - Connections, shared devices, network patterns
Implement rules layer - Hard blocks for obvious patterns
Deploy multi-layer system - Rules + ML scores + human review queue
Monitor for drift - Fraud patterns change; model staleness is dangerous
Close feedback loop - Confirmed frauds train next model; adversarial retraining

Baseline First

Start with rules-based system before ML:

Velocity rules: > N transactions in T minutes
Amount thresholds: Unusual transaction size
Geographic rules: Impossible travel, high-risk countries
Device rules: Known bad devices, multiple accounts per device
Behavioral rules: First transaction anomalies, pattern breaks

Why rules first: - Interpretable and auditable - Fast to deploy and update - Catches obvious fraud immediately - Provides training signal for ML

ML layer adds: nuanced scoring, pattern generalization, handling of novel attack vectors.

Common Models and When to Choose

Model	Best For	Training Time	Interpretability
Rules engine	Known patterns, regulatory needs	N/A	High
Logistic Regression	Baseline, interpretability	Minutes	High
XGBoost/LightGBM	Best default, tabular features	Hours	Medium
Neural Network	Complex patterns, large data	Hours-Days	Low
Isolation Forest	Unsupervised, new fraud patterns	Hours	Low
Graph Neural Network	Network fraud, coordinated attacks	Days	Low
Autoencoders	Anomaly detection, reconstruction error	Hours	Low

Production systems typically combine: Rules (hard blocks) + ML score (risk ranking) + Manual review (high-risk queue).

Feature Engineering Patterns

Velocity features: - Transaction count in 1h, 24h, 7d, 30d - Unique merchants, unique devices - Amount sum, max, mean over windows - Acceleration (this window vs previous)

Behavioral deviation: - Current amount / user average amount - Time since last transaction - Distance from typical location - New device flag, new merchant flag

Network features: - Accounts sharing device/IP/address - Graph distance to known fraud - Community detection scores - PageRank-style influence scores

Device and session: - Device fingerprint match - Browser/OS anomalies - Session duration patterns - JavaScript rendering consistency

External enrichment: - IP reputation scores - BIN/card reputation - Email domain age - Phone number verification

Evaluation and Metrics

Primary metrics:

Metric	Description	Typical Target
Precision at threshold	% of blocked transactions that are fraud	> 50%
Recall at threshold	% of fraud caught	> 80%
False positive rate	% of good transactions blocked	< 1%
Detection rate by amount	% of fraud dollars caught	> 90%
AUC-PR	Area under precision-recall curve	> 0.5

Business metrics: - Fraud loss rate (fraud amount / total amount) - Customer friction (false positive impact) - Manual review volume - Time to detection

Pitfalls: - Optimizing for AUC ignores business costs (false positive cost != false negative cost) - Delayed labels mean evaluation on stale data - Fraudsters adapt after model deployment - Aggregated metrics hide segment-level failures

Failure Modes and Debugging Checklist

[ ] Label leakage: Using features derived from fraud investigation
[ ] Label delay: Model evaluated on unconfirmed labels
[ ] Adversarial adaptation: Fraudsters learned model thresholds
[ ] Population shift: New user segment with different patterns
[ ] Feature staleness: Real-time features not updating
[ ] Threshold decay: Operating point no longer optimal
[ ] Cold start: New users have no history, high FP rate
[ ] Coordinated attack: Graph patterns missed by per-transaction model

Production Checklist

Before deployment: - [ ] Evaluated on confirmed labels only - [ ] Performance checked across segments (new users, high-value, etc.) - [ ] Latency requirements met (< 100ms p99) - [ ] Fallback behavior defined (if model fails, default allow or block?) - [ ] Manual review queue capacity planned - [ ] Explainability available for review queue

After deployment: - [ ] Real-time score distribution monitoring - [ ] Fraud rate tracking by score bucket - [ ] Alert on score distribution shift - [ ] Daily/weekly model performance review - [ ] Regular retraining (weekly or triggered by drift) - [ ] Red team exercises (simulate attacks)

Compliance: - [ ] Model decisions auditable - [ ] Adverse action reasons available - [ ] Bias monitoring by protected attributes - [ ] Regulatory reporting in place

Tools and Stack

Category	Tools
Feature store	Feast, Tecton, Redis (real-time)
Training	XGBoost, LightGBM, PyTorch
Graph analytics	Neo4j, NetworkX, PyTorch Geometric
Real-time scoring	FastAPI, Seldon, custom C++
Rules engine	Custom, Drools, Open Policy Agent
Monitoring	Evidently, custom dashboards
Case management	Custom, SAS, FICO

Example Mini-Case

Scenario: Payment processor handling 5M transactions/day, 0.1% fraud rate, $50M annual fraud loss.

Current state: Rule-based system catches 60% of fraud, 2% false positive rate.

Approach: 1. Feature engineering: 200 features (velocity, behavioral, device, network) 2. Model: LightGBM with focal loss for imbalance 3. Threshold: Set for 0.5% FP rate, ~80% recall 4. Architecture: Rules layer (hard blocks) → ML score → Review queue

Production setup: - Model scoring in < 50ms - Real-time features from Kafka streams - Daily model performance dashboard - Weekly retraining with confirmed labels - Monthly adversarial review

Results: 85% fraud detection, 0.5% FP rate, $15M annual fraud reduction.

Ongoing work: Graph-based detection for coordinated fraud, device fingerprinting improvements.

Index: ML Field Guide
Unsupervised Anomaly Detection
Binary Classification in Production
Feature Engineering Fundamentals

Try it live

Everything above runs in your browser — open Fraud Detection System - AI Simulation and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.

▶ Open Fraud Detection System - AI Simulation simulation

Fraud Detection Systems