Fraud detection is not a post-clearing task if you intend to stop the charge. The clearing window generally spans 40 to 80 milliseconds, from authorization-request arrival until the clearing instruction reaches the card scheme. All detection logic must execute within that interval. Otherwise, the system is detecting after clearing and you carry every chargeback tied to fraud that passed through.
This timing limit is the core engineering constraint behind enza's fraud model. The sections below explain inline fraud detection and its operational tradeoffs.
Why Post-Clearing Fraud Detection Differs
Some payment platforms score fraud through a post-clearing webhook. The transaction clears, an asynchronous evaluation runs, and a high score triggers a chargeback dispute filing or merchant hold. That supports fraud analytics and portfolio risk monitoring, but it cannot stop a specific fraudulent charge.
After the clearing instruction reaches the scheme, liability-wise the transaction is effectively committed. The issuer has authorized it, the acquirer has processed it, and the funds are set to move. Chargebacks may recover funds where scheme rules allow, but fraud recovery depends on dispute category, card scheme, and suitable 3DS authentication. Full recovery is not guaranteed.
Stopping fraud before the clearing instruction costs only the declined transaction. Stopping it after clearing begins a dispute that may run 30 to 90 days, with recovery varying by fraud type and scheme rules. That gap justifies investing in inline scoring.
What Must Happen in 40 to 80 Milliseconds
Inline fraud scoring requires all of these steps to finish before the clearing instruction fires:
- Transaction data is received and parsed from the authorization request
- Feature extraction runs: velocity calculations, device and location signals, amount normalization, merchant category context
- The fraud model runs inference against the extracted feature vector
- A risk score is produced and compared against configured thresholds
- A decision (approve, decline, or queue for review) is produced and acts on the clearing decision
Completing the chain in under 50ms is feasible with deliberate architecture. No step can synchronously query cold-storage data. Extract features from in-memory stores, and keep the model loaded in memory rather than fetching it per request.
Fast Feature Extraction
Velocity is the most accessible computational signal: how many transactions did the card generate in the last 60 seconds, 5 minutes, or 1 hour? Keep velocity state in a structure offering sub-millisecond reads. Redis with suitable key expiration works well. At minimum, store sliding-window counters per card and device.
Geographic scoring measures the distance between the prior transaction location and the current one, normalized by elapsed time. Store each card's last location and timestamp in memory, not through a SQL query. Impossible velocity, such as use in Lagos and London within 30 minutes, is a high-confidence signal in African markets, where compromised card data often drives international card-not-present fraud.
Amount anomaly compares the current value with the card's historical distribution. Maintain mean, standard deviation, and recent outlier count as a statistical history summary. A compact rolling summary uses a few hundred bytes per card and updates incrementally after each transaction. A z-score against it takes microseconds.
Merchant category context matters: some merchant category codes (MCCs) have higher base fraud rates. Jewelry, electronics, and selected digital goods merit greater baseline suspicion. Use a lookup table, not computation.
Low-Latency Model Architecture
Latency limits the model choice. Even on well-optimized hardware, deep neural networks with many layers need 5 to 20ms for inference despite strong accuracy. For inline clearing-window scoring, shallow gradient boosted trees, specifically XGBoost or LightGBM with depth limits, infer in 0.5 to 2ms while retaining competitive accuracy on tabular transaction features.
Our scoring uses two stages. First, lightweight heuristics handle obvious, high-confidence cases: impossible velocity, BIN mismatch with claimed geography, and amounts above 10 standard deviations from card history. They return high risk without model inference, saving 1 to 3ms on most transactions where an early signal is clear.
The gradient boosted model handles the remainder, where heuristics are inconclusive. Its full feature vector includes velocity state, geographic signals, amount z-score, MCC context, time-of-day features, and card tenure signals. The output is a probability from 0 to 1.
Thresholds and the False Positive Problem
Production systems should not use one global threshold. The right operating point changes by card type, issuer market, merchant category, and transaction time. A threshold averaging 95% fraud capture may catch 70% in some corridors and 98% in others, while producing excessive false positives where calibration is poor.
enza's fraud configuration sets thresholds per rule, with distinct sensitivity for velocity, amount anomaly, and geographic checks. This is operationally necessary across African markets because usage differs sharply between, for example, a consumer debit card in rural Ghana and a corporate card in Lagos.
Inline scoring does not remove false positives. Claims of near-zero false positives either omit actual threshold settings or apply only to a narrow, unrepresentative context. The target is a portfolio-specific balance: few enough false positives to avoid rejecting legitimate customers, and sufficient sensitivity to keep passing fraud within chargeback tolerance.
The Review Queue Path
A transaction need not receive an immediate approve-or-decline result. Those in a configured middle band can enter a short human-review queue before the clearing instruction fires. This works only with staffed reviewers and a review period that fits the authorization expiry window, typically 60 to 120 seconds for most African scheme authorizations.
For unusual card-not-present activity, brief step-up authentication, such as an OTP sent to the card's registered phone number, can replace a binary decision. It adds 5 to 30 seconds for human verification while the authorization remains open. Given the volume of CNP attempts involving compromised card data, this is standard in Nigeria.
Declining every transaction above a threshold is the simplest design, not necessarily the right one. A configurable path supporting approve, decline, queue-for-review, and step-up authentication provides operating flexibility as the fraud profile changes. The clearing window stays fixed, but its available decision time can be used differently.