A user taps “Pay” at a checkout terminal in Mumbai. Within the next 80 milliseconds, your system must decide whether this transaction is genuine or fraudulent - before the payment processor times out and before the customer gets annoyed waiting for the spinner. The decision draws on hundreds of signals: is this the usual device the user shops from? Have they made 12 transactions in the last 5 minutes from three different countries? Does the merchant category match previous spending patterns? Has this card number appeared on a known-compromised list in the last hour?

Fraud is an adversarial cat-and-mouse problem. Fraudsters actively probe your defenses, testing small transactions before large ones, cycling through stolen cards, and mimicking legitimate behavior patterns to avoid velocity triggers. Your detection system must evolve continuously - a static rule set becomes obsolete within days as attackers learn its boundaries. At the same time, every false positive blocks a legitimate customer, damages trust, and costs revenue. A 0.5% false positive rate on a system processing 10,000 transactions per second blocks 50 legitimate payments every second.

The core engineering tension is latency versus accuracy. More sophisticated models - deep neural nets, graph-based fraud network detection, complex ensemble methods - take longer to run. Simple threshold rules are fast but blind to subtle pattern combinations. Waiting for more signals improves accuracy but increases latency. Running every model in parallel wastes compute on transactions that a fast rule would have blocked immediately. The system must be a pipeline that can exit early on high-confidence decisions while escalating uncertain cases through progressively more expensive analysis.

We need to solve for three things simultaneously: (1) sub-100ms scoring that consumes pre-computed features and makes a decision before the payment processor times out, (2) continuous model evolution that updates risk models with new fraud patterns without requiring a full redeployment, and (3) false positive minimization that avoids blocking legitimate users even as fraud patterns shift.

Requirements and Constraints

Functional Requirements

• Score every incoming payment transaction synchronously before approval, returning APPROVE, DECLINE, or REVIEW within 100ms
• Compute velocity features: transaction count and volume per user in the last 1 minute, 5 minutes, 1 hour, and 24 hours
• Evaluate rule-based checks: velocity thresholds, device fingerprint consistency, IP geolocation anomalies, card BIN risk scoring
• Run ML ensemble scoring combining gradient boosting and a neural network for behavioral pattern detection
• Support a shadow mode where new models run alongside production without affecting decisions, for validation before promotion
• Feed approved and declined transaction outcomes back into the feature store for continuous model updates
• Allow manual case review workflow for REVIEW decisions, with analyst feedback flowing back into training data

Non-Functional Requirements

• Latency: P99 scoring decision under 100ms end-to-end, P50 under 30ms
• Throughput: 10,000 transactions per second sustained, 50,000 TPS burst (flash sale periods)
• Availability: 99.99% uptime for the scoring path (failsafe to APPROVE on system failure to avoid blocking payments)
• False positive rate: under 0.3% of legitimate transactions incorrectly declined
• False negative rate: under 0.8% of fraudulent transactions incorrectly approved (tunable via threshold)
• Feature freshness: velocity counters updated within 500ms of transaction completion
• Model update latency: new model versions promoted to production within 15 minutes of approval
• Audit log retention: all scoring decisions with full feature vectors stored for 7 years (regulatory requirement)

Constraints and Assumptions

• Payment processor has a 120ms timeout - we must respond in under 100ms to leave 20ms buffer
• We do not store raw card numbers - only tokenized card IDs and card BIN (first 6 digits)
• PCI-DSS compliance requires all cardholder data to flow through isolated network segments
• We assume a user identity graph is available as a pre-built service (not built here)
• Geographic distribution: scoring nodes deployed in 4 regions; features replicated with eventual consistency

High-Level Architecture

The fraud engine has six major components working together to deliver a sub-100ms scoring decision for every payment.

The API Gateway receives the raw transaction payload from the payment processor and immediately strips sensitive fields before forwarding downstream. It enforces the 100ms SLA by setting a deadline on the entire scoring pipeline context.

The Feature Extractor is the synchronous hot path. It executes feature lookups in parallel: querying the online feature store for pre-computed behavioral features, hitting Redis for velocity counters, and calling the device fingerprint service. All lookups run concurrently with a combined timeout of 20ms. Missing features default to safe baseline values rather than failing the transaction.

The Feature Store has two layers: an offline store (columnar database updated by batch jobs) and an online store (Redis cluster) that serves low-latency feature lookups. The online store holds pre-computed user risk scores, historical velocity statistics, and device trust signals updated within seconds of new transactions.

The Rule Engine applies deterministic, interpretable checks that can exit early. Rules catch obvious fraud patterns - impossible travel, velocity spikes, known-bad indicators - in under 5ms. A rule firing with sufficient confidence returns an immediate DECLINE without invoking the ML models.

The ML Ensemble runs gradient boosting and a neural network in parallel, combining their scores with learned weights. This layer handles subtle pattern combinations that rules cannot express. It accounts for 60-80ms of the total budget when invoked, which is why the Rule Engine’s early exit path is critical.

The Decision Engine receives the rule verdict and ML scores, applies the final threshold logic, writes the decision to the audit log, and returns the response to the payment processor. It also enqueues the transaction and decision to the feedback loop pipeline.