Fraud scoring in payment processing is subject to a hard real-time constraint that doesn't exist in most other machine learning applications: the score must be produced within the authorization window. An online card payment authorization cycle — from the moment a cardholder submits payment to the moment the merchant receives an approve or decline response — operates within a total budget of roughly 150 to 200 milliseconds when measured end-to-end including issuer response time. The fraud scoring system has to complete its work within that window, and it shares the window with network latency, authorization routing, and the issuer's own processing time.
In practice, the scoring system's budget is 30 to 50 milliseconds. That's the engineering constraint the entire fraud scoring architecture must be designed around.
The Authorization Latency Budget
Breaking down the authorization timeline: a typical card-not-present authorization flows from the merchant's checkout system to the payment processor, through the card network (Visa or Mastercard), to the issuing bank, and back through the same path. Each hop adds latency. Network transit for a typical US-based transaction runs 10-20ms each way. The issuer's authorization system adds another 40-80ms. Card network processing adds 5-15ms.
After accounting for these components, the processor typically has a budget of 30-50ms to complete all processing on its side of the authorization — including fraud scoring. When issuers are slow (a regular occurrence, particularly for smaller issuers), the budget shrinks further. The scoring system must be architected to return a result in under 40ms at the 99th percentile — meaning it can't rely on operations that occasionally spike beyond that threshold.
This constraint rules out a significant range of computational approaches that are viable in asynchronous contexts. A deep neural network that runs 200ms inference time is not a candidate for real-time authorization scoring regardless of its accuracy. Model architecture choices have to start with the latency constraint, not end with it.
How Sub-40ms Scoring Is Achieved
Meeting a sub-40ms scoring latency at the 99th percentile requires architectural decisions across three dimensions: model architecture, feature caching, and async signal enrichment.
Model architecture: Gradient-boosted tree models (XGBoost, LightGBM) are the practical standard for real-time fraud scoring because they deliver strong predictive accuracy with inference times in the 1-5ms range on typical hardware. A well-tuned gradient boosted model with 200-500 trees runs inference in under 3ms. This leaves the remaining latency budget for feature computation and I/O. Deep learning architectures — transformer models, deep MLPs — can achieve comparable accuracy but at 10-50x the inference latency, making them unsuitable as primary scoring models for real-time authorization paths. They can be used in asynchronous enrichment pipelines but not in the synchronous scoring path.
Feature caching: The most latency-sensitive component of fraud scoring is often not model inference but feature retrieval. A fraud model that requires 30+ features about a cardholder, merchant, and device must retrieve those features within the latency budget. Pre-computed feature caches — maintained in low-latency key-value stores (Redis, Memcached, or equivalent) — reduce feature retrieval to sub-millisecond operations for features that can be computed ahead of time. Features that can be pre-computed include: 30-day velocity metrics per card and merchant, device fingerprint history, BIN risk scores, and merchant baseline statistics. These are updated asynchronously and retrieved at scoring time from cache.
Async signal enrichment: Some signals are valuable for fraud detection but cannot be computed within the authorization window. Geolocation enrichment of IP addresses, device reputation lookups against third-party databases, and social graph analysis of linked accounts all have retrieval latencies measured in tens to hundreds of milliseconds. These signals are computed asynchronously and stored in the feature cache for use in subsequent transaction scoring. The latency-accuracy tradeoff is explicit: these signals are always slightly stale, but they represent a structured trade-off — a device reputation score that's 30 seconds old is substantially more valuable than no device reputation score at all.
The Tradeoff Between Model Complexity and Latency
Adding model complexity generally improves predictive accuracy but increases inference latency. For fraud scoring, the relationship is not linear and the practical improvements from very high complexity models are modest relative to the latency cost. An XGBoost model with 300 trees and 30 features will typically outperform a model with 100 trees on a held-out test set. Moving from 300 to 1,000 trees may improve AUC by 0.5-1.0%, but increases inference latency by 3x. That trade-off is rarely justified in the authorization path.
The more productive approach is feature engineering rather than model complexity escalation. A simpler model with richer, more predictive features consistently outperforms a complex model on basic features for fraud detection. Time-windowed velocity features, merchant-relative anomaly scores, and BIN cohort risk metrics all add predictive value without requiring more complex models to extract it. Engineering the feature set is higher-ROI than escalating model complexity.
Why Batch Scoring Is Not Viable for Online Payments
Batch scoring — scoring transactions in periodic batches rather than individually in real time — is used in some fraud analytics contexts (retrospective analysis, model training, post-authorization review). It is not a viable architecture for online payment authorization for a fundamental structural reason: authorization decisions are binary and immediate. A transaction is either approved or declined at the moment of authorization. A score produced 5 minutes later, in a batch process, cannot inform that decision.
Post-authorization scoring has a role in dispute management and retrospective fraud analytics, but it cannot substitute for real-time authorization scoring. Processors that rely on rule-based pre-screening without a real-time scoring component are making authorization decisions without the benefit of model-based risk assessment. The fraud rate difference between real-time model-scored authorization and rule-only authorization is consistently measurable and substantial.
Feature Freshness and Model Accuracy
Feature freshness — how recently a cached feature was computed — directly affects model accuracy. A 30-day velocity feature computed this morning and retrieved from cache this afternoon is fresh. The same feature computed three days ago and not updated is stale by the standards of a merchant experiencing a card-testing campaign that started yesterday.
The practical standard for velocity features is cache TTL of 5-15 minutes for high-velocity merchants and up to 60 minutes for low-frequency merchant categories. Features tied to device and IP reputation can tolerate longer TTLs — 24-48 hours — because device risk profiles change more slowly than velocity patterns. The freshness policy should be set per feature type, not as a single global TTL.
Latency SLA Commitments
A real-time fraud scoring system for payment authorization should commit to the following latency targets as a baseline: median scoring latency under 15ms; 95th percentile under 25ms; 99th percentile under 40ms; 99.9th percentile under 60ms. Latency exceeding 60ms at any meaningful percentile begins to create authorization timeout risk — situations where the processor's authorization response is delayed long enough that the card network or merchant system times out and fails the transaction. A fraud scoring component that introduces timeout-driven transaction failures has a direct, measurable negative impact on authorization rate that typically exceeds the fraud reduction benefit. The latency SLA is not a soft engineering target; it's a hard operational boundary.