Q: How do you detect card testing fraud?

Card testing: fraudsters steal card numbers and verify them by making small ($0.01-$1) transactions. Signals: multiple small-amount transactions on different merchants in a short window, new account with high-value purchase immediately after small transaction, multiple declined transactions followed by a successful one (testing cards until one works). Detection: INCR small_tx:{device_id}:{hour} for transactions < $1. If count > 3 in 60 minutes, block the device and flag all associated cards. Also: if a new card has more than 2 declined transactions in 10 minutes, block the card. Store device fingerprints and IP addresses associated with card testing patterns in a blocklist (Redis SET, TTL=30 days).

Question 1

How does a rule-based fraud detection system work?

Accepted Answer

A rule engine applies deterministic, fast checks in sequence and short-circuits on the first match. Rules are evaluated in milliseconds and cover obvious fraud patterns: velocity rules (INCR tx_count:{user_id}:{minute} in Redis, block if > 5/min), geographic rules (billing country != IP country → review), amount rules (amount > 3x user's 30-day average → review), device blocklist (device fingerprint associated with prior fraud → block), card BIN blocklist (first 6 digits of known stolen cards → block). Rules are transparent, auditable, and easy to update when new fraud patterns emerge. Limitation: rule engines miss novel fraud patterns that don't match existing rules. Complement with ML scoring for ambiguous cases.

Question 2

How does machine learning improve fraud detection over rule-only systems?

Accepted Answer

ML models find complex non-linear patterns across many features simultaneously — patterns that would require hundreds of hand-crafted rules. Feature examples: amount z-score relative to user's history, time since last transaction, count of new devices in last 7 days, IP reputation score, is_VPN, merchant risk category, velocity across multiple time windows. Model: gradient boosting (XGBoost/LightGBM) trained on labeled transactions (fraud=1 based on chargebacks, non-fraud=0). Output: risk score 0-1. Decision: score > 0.7 = block, 0.2-0.7 = review (3DS challenge or manual review), < 0.2 = allow. ML catches fraud that evolved past existing rules. Key challenge: class imbalance (fraud is 0.1-1% of transactions) — oversample positives or use class weights.

Question 3

How do you detect card testing fraud?

Accepted Answer

Card testing: fraudsters steal card numbers and verify them by making small ($0.01-$1) transactions. Signals: multiple small-amount transactions on different merchants in a short window, new account with high-value purchase immediately after small transaction, multiple declined transactions followed by a successful one (testing cards until one works). Detection: INCR small_tx:{device_id}:{hour} for transactions < $1. If count > 3 in 60 minutes, block the device and flag all associated cards. Also: if a new card has more than 2 declined transactions in 10 minutes, block the card. Store device fingerprints and IP addresses associated with card testing patterns in a blocklist (Redis SET, TTL=30 days).

Question 4

How do you build a feature store for real-time fraud detection?

Accepted Answer

A feature store separates feature computation from model serving. Real-time features (computed at transaction time): velocity counts from Redis (transactions in last 1h/24h), amount of last transaction, time since last transaction. These are computed from the raw event stream and stored in Redis with TTL. Historical features (precomputed from batch jobs): user's 30-day average transaction amount, stddev, typical transaction hour distribution, country distribution. These are stored in Cassandra or a fast key-value store (DynamoDB), keyed by user_id. At inference time: fetch both real-time and historical features, combine into a feature vector, run through the model. Separate real-time features (Redis, sub-ms) from historical features (batch-computed, Cassandra lookup, ~5ms).

Question 5

How do you minimize false positives in a fraud detection system?

Accepted Answer

False positives (legitimate transactions blocked) are costly — lost revenue, frustrated customers, support tickets. Five strategies: (1) Use REVIEW instead of BLOCK for medium-risk scores — add friction (3DS challenge) rather than outright rejection. (2) Allow customers to whitelist trusted devices and merchants. (3) Contextual signals: if the user just changed their billing address AND made a large purchase, it's more suspicious than either signal alone. ML captures these combinations. (4) Tune thresholds: optimize the block threshold to minimize false positives while staying below the acceptable chargeback rate. (5) Feedback loop: when a customer disputes a block (calls support), label that as a false positive and use it to retrain the model. Track FPR (false positive rate) as a key SLA metric alongside fraud detection rate.

Fraud Detection System Low-Level Design

Requirements

Architecture: Rule Engine + ML Scoring

Rule Engine (First Layer)

ML Risk Scorer (Second Layer)

Risk Score → Decision

Feature Engineering

Feedback Loop

Data Model

Key Design Decisions