How to Design a Fraud Detection System
Learn how to design a real-time fraud detection system combining rules engines, ML scoring, feature stores, and feedback loops.
Expected Interview Answer
A fraud detection system scores every transaction in real time by combining a low-latency rules engine for known bad patterns with a machine-learning model for subtler anomalies, feeding both from a shared feature store so decisions happen in tens of milliseconds without blocking checkout.
The request path starts at an ingestion gateway that timestamps and enriches each transaction with account age, device fingerprint, velocity counters and geo-location, pulling precomputed features from a low-latency store like Redis so the model never does a slow database join in the hot path. A rules engine catches deterministic red flags (blocklisted cards, impossible travel speed) instantly, while a gradient-boosted or neural model scores the remaining ambiguous cases, producing a risk score that routes the transaction to auto-approve, auto-decline, or manual review. Every decision and outcome is logged to a feature pipeline that retrains the model on a schedule, closing the loop as fraud patterns shift. Because false positives cost real revenue and false negatives cost real losses, the system exposes tunable thresholds per merchant risk appetite and supports shadow-mode deployment so new model versions can be validated against live traffic before they make real decisions.
- Combines deterministic rules and ML scoring for both known and novel fraud patterns
- Precomputed feature store keeps scoring latency in the tens of milliseconds
- Feedback loop from confirmed fraud/chargebacks continuously retrains the model
- Shadow-mode deployment lets new models be validated safely before going live
AI Mentor Explanation
A fraud detection system is like a team’s match referee watching every delivery for both obvious no-balls (a fixed rule: foot over the line) and subtler suspicious patterns like a bowler’s action changing mid-spell that only years of umpiring experience can flag. The referee has instant checks for the clear-cut violations, but for borderline cases sends the footage to the third umpire, who reviews more data before a final ruling. Every overturned or confirmed decision gets logged and used to retrain how future close calls are judged. That mix of instant rule checks and a learned, evolving judgment for ambiguous cases is exactly how a fraud detection system balances speed and accuracy.
Step-by-Step Explanation
Step 1
Ingest and enrich in real time
The gateway timestamps each transaction and enriches it with precomputed features (device fingerprint, velocity counters, account age) pulled from a low-latency feature store.
Step 2
Apply deterministic rules first
A fast rules engine instantly blocks or flags known bad patterns (blocklisted cards, impossible travel velocity) before any model call.
Step 3
Score with the ML model
Remaining ambiguous transactions are scored by a trained model (e.g. gradient boosting) that outputs a risk probability in milliseconds.
Step 4
Route and close the feedback loop
The score routes to auto-approve, auto-decline, or manual review; confirmed outcomes (chargebacks, cleared cases) feed back into scheduled retraining.
What Interviewer Expects
- Distinguishes deterministic rules from ML scoring and explains why both layers are needed
- Discusses latency constraints (scoring must not block checkout) and the role of a feature store
- Mentions the feedback loop from confirmed fraud/chargebacks back into retraining
- Addresses the false positive/false negative trade-off and tunable thresholds
Common Mistakes
- Proposing only a rules engine with no learning component for novel fraud patterns
- Ignoring latency budget and assuming a full model inference plus database join is fine in the hot path
- Forgetting the feedback loop that keeps the model current as fraud patterns evolve
- Not discussing how to safely roll out a new model version (shadow mode / canary) without live risk
Best Answer (HR Friendly)
“A fraud detection system checks every transaction against known bad patterns instantly, and for anything less obvious, a trained model scores how risky it looks based on things like spending history and location. Transactions that look clearly fine go through immediately, clearly bad ones get blocked, and the grey-area ones go to a human for a closer look, with every outcome helping the system get smarter over time.”
Code Example
def score_transaction(txn):
features = feature_store.get(txn.account_id, txn.device_id)
# Layer 1: deterministic rules, fast and definitive
if txn.card_id in blocklist:
return "DECLINE", 1.0
if features.travel_velocity_kmh > 900:
return "DECLINE", 0.99
# Layer 2: ML model for ambiguous cases
risk_score = fraud_model.predict_proba(
build_feature_vector(txn, features)
)
if risk_score < 0.2:
decision = "APPROVE"
elif risk_score < 0.7:
decision = "MANUAL_REVIEW"
else:
decision = "DECLINE"
audit_log.write(txn.id, decision, risk_score)
return decision, risk_scoreFollow-up Questions
- How would you keep p99 scoring latency under 100ms as transaction volume grows?
- How do you handle severe class imbalance when training the fraud model (fraud is rare)?
- How would you validate a new model version before it makes live decisions?
- How do you prevent fraudsters from reverse-engineering your rules through repeated probing?
MCQ Practice
1. Why do fraud detection systems typically combine a rules engine with a machine-learning model rather than using only one?
Rules give instant, deterministic coverage of known fraud patterns; the model catches subtler and evolving patterns that rules alone would miss.
2. What is the primary purpose of a low-latency feature store in a fraud detection pipeline?
Feature stores precompute and cache signals like velocity counters so scoring avoids slow live joins during the transaction hot path.
3. What is “shadow mode” deployment used for in a fraud detection system?
Shadow mode lets a new model score real traffic in parallel so its behavior can be validated before it is trusted to make live decisions.
Flash Cards
Why combine rules and ML for fraud detection? — Rules catch known patterns instantly; ML models catch novel, ambiguous patterns that rules cannot enumerate.
Role of a feature store here? — Serves precomputed signals (velocity, device history) fast enough to keep scoring within the checkout latency budget.
What closes the fraud detection feedback loop? — Confirmed fraud/chargeback outcomes are logged and used to retrain the model on a schedule.
Why use shadow-mode deployment? — To validate a new model against live traffic without letting it affect real decisions until proven safe.