Design a Real-Time Fraud Detection System

Problem Statement & Requirements

Think of fraud detection like airport security with multiple screening layers. The first layer is a quick metal detector (rules engine). The second is an X-ray machine (ML model). Suspicious items get additional manual inspection (human review). Each layer catches different threats, and together they provide defense in depth.

Functional Requirements

• Real-time scoring — Score every transaction before authorization
• Rule engine — Configurable rules (velocity checks, blocklists, thresholds)
• ML model inference — Run trained fraud models on transaction features
• Alerting — Flag high-risk transactions for human review
• Feedback loop — Incorporate confirmed fraud/legitimate labels for retraining
• Case management — Investigation workflow for flagged transactions

Non-Functional Requirements

• Decision latency — <100ms for block/allow decision
• False positive rate — <0.1% (1 in 1,000 legitimate transactions incorrectly blocked)
• Fraud detection rate — >95% of fraudulent transactions caught
• Availability — 99.99% (downtime = all transactions auto-approved)

Back-of-Envelope Estimation

System API Design

# Score a transaction (called by payment gateway)
POST /api/v1/transactions/score
{
  "transaction_id": "txn_abc123",
  "amount": 499.99,
  "currency": "USD",
  "merchant_id": "merch_456",
  "user_id": "user_789",
  "card_hash": "sha256_xxx",
  "ip_address": "203.0.113.42",
  "device_fingerprint": "fp_xyz",
  "timestamp": "2024-01-15T10:30:00Z"
}
# Response (must return in <100ms)
{
  "decision": "allow",  // allow, block, review
  "risk_score": 0.12,
  "triggered_rules": [],
  "model_version": "v4.2"
}

# Submit fraud/legitimate label (feedback loop)
POST /api/v1/transactions/label
{
  "transaction_id": "txn_abc123",
  "label": "fraud",
  "source": "chargeback"
}

# Manage rules
POST /api/v1/rules
{
  "name": "high_velocity_check",
  "condition": "txn_count_1h > 10 AND amount > 500",
  "action": "block"
}

Data Model

CREATE TABLE transactions (
    txn_id        VARCHAR PRIMARY KEY,
    user_id       VARCHAR,
    merchant_id   VARCHAR,
    amount        DECIMAL(12,2),
    currency      VARCHAR(3),
    risk_score    FLOAT,
    decision      VARCHAR,
    label         VARCHAR,  -- fraud, legitimate, null (unknown)
    features      JSONB,
    timestamp     TIMESTAMP
) PARTITION BY RANGE (timestamp);

CREATE TABLE rules (
    rule_id       VARCHAR PRIMARY KEY,
    name          TEXT,
    condition     TEXT,   -- expression DSL
    action        VARCHAR, -- block, review, score_boost
    enabled       BOOLEAN,
    priority      INT
);

CREATE TABLE alerts (
    alert_id      VARCHAR PRIMARY KEY,
    txn_id        VARCHAR,
    status        VARCHAR,  -- open, investigating, resolved
    assigned_to   VARCHAR,
    resolution    VARCHAR,  -- confirmed_fraud, false_positive
    created_at    TIMESTAMP
);

High-Level Architecture

The system has two paths: a real-time scoring path (<100ms) and an offline learning path (hours-days).

Deep Dive: Core Components

Real-Time Feature Engineering

class FraudFeatureEngine:
    def compute_features(self, txn, feature_store):
        user_id = txn["user_id"]
        # Pre-computed features from feature store (<5ms)
        stored = feature_store.get_online(
            entity="user", id=user_id,
            features=["avg_txn_30d", "account_age",
                      "device_count", "country_count_7d"]
        )
        # Real-time windowed aggregations (<10ms)
        velocity = self.redis.get_sliding_window(
            f"velocity:{user_id}", window="1h"
        )
        # Derived features
        features = {
            "amount_deviation": (
                txn["amount"] - stored["avg_txn_30d"]
            ) / max(stored["avg_txn_30d"], 1),
            "txn_count_1h": velocity["count"],
            "txn_sum_1h": velocity["sum"],
            "is_new_device": txn["device_fingerprint"]
                not in stored.get("known_devices", []),
            "is_new_country": txn["country"]
                != stored.get("home_country"),
            **stored  # Include all pre-computed features
        }
        return features

Rule Engine + ML Hybrid

Handling Class Imbalance

Only 0.1% of transactions are fraudulent. Training on raw data gives a model that predicts "legitimate" 99.9% of the time. Solutions:

• Oversampling: SMOTE generates synthetic fraud examples
• Undersampling: Randomly reduce legitimate examples to 10:1 ratio
• Cost-sensitive learning: Weight fraud examples 100x higher in loss function
• Anomaly detection: Train on legitimate transactions only, flag outliers

Graph-Based Fraud Detection

Fraud rings involve coordinated accounts. Build a transaction graph: nodes are users, merchants, devices, IPs. Edges connect related entities. Use graph algorithms (community detection, PageRank) to identify suspicious clusters sharing devices or addresses.

Concept Drift

Scaling & Optimization

Stream Processing Architecture

Use Kafka for event ingestion and Flink for real-time feature computation. Flink maintains sliding window state for velocity features. Back-pressure handling prevents queue buildup during traffic spikes.

Low-Latency Model Serving

• Pre-compile models: Convert to ONNX/TensorRT for 2-5x faster inference
• CPU-optimized models: Use XGBoost/LightGBM for <5ms inference (no GPU needed)
• Model caching: Keep hot models in memory, cold models on disk
• Parallel scoring: Run rule engine and ML model concurrently, combine results

Feedback Loop Latency

Practice Problems

Quick Reference