Real-Time Fraud Decisions Under 100 Milliseconds

FinTech Engineering

I start a real-time fraud design by defining the stopwatch and the cost of a wrong decision. A sub-100-millisecond target is useful only when its boundary, percentile, degraded mode, and loss trade-off are explicit.

Define what the stopwatch measures

“The model responds in 12 ms” says little about an authorization decision. A useful service-level objective might be: p99 under 100 ms from the risk API receiving a complete request to returning approve, decline, or step-up, measured in one region at a stated throughput. Network travel to the merchant, 3-D Secure interaction, issuer processing, and processor latency are outside that boundary and must be reported separately.

There is no universal 100 ms fraud standard. It is an architectural budget. Publish p50, p95, and p99, workload, geography, and measurement point. Otherwise a precise title creates false confidence.

EMVCo’s official 3-D Secure material shows the broader risk-based context: lower-risk transactions may follow a frictionless flow, while higher-risk transactions can require additional authentication. The current protocol details are versioned in the 3-D Secure specification hub. A platform must state which 3DS version and market rules it implements.

Build the budget backwards

Here is how I would sketch a synthetic 100 ms internal p99 budget:

These numbers are synthetic, not a benchmark. The reserve matters because tail latency compounds across dependencies. The service should avoid synchronous calls to a data warehouse, case-management tool, or third-party enrichment that cannot meet the same budget.

Split features by freshness and consequence

Compute stable attributes—merchant history aggregates, known device relationships, account tenure—offline or through streaming pipelines into a low-latency online store. Compute request-local signals such as amount deviation and device velocity at decision time. Every feature needs an owner, definition, freshness timestamp, default behavior, and training/serving consistency test.

Missing data is not zero. If device history is unavailable, expose missing and the cause. Models trained on complete data can fail silently when the online store degrades. Monitor feature age and missingness by segment, not only overall.

Rules and model scores often run in parallel. A deterministic sanctions or blocked-credential rule may override the model. A model score may select approve, decline, or step-up thresholds by product and risk appetite. Record rule version, model version, feature-set version, threshold policy, and reason codes with each decision.

Design degradation before the outage

When the feature store times out, “fail open” and “fail closed” are both too crude. Define a tiered policy:

• low-value, established-customer traffic may use a conservative reduced feature set;
• high-risk operations may step up authentication;
• materially exposed operations may decline or queue when the product permits;
• the platform may reduce traffic or disable an unstable model version.

The policy should be approved, tested, and observable. NIST AI RMF 1.0 frames AI risk work across Govern, Map, Measure, and Manage; it is voluntary guidance, but its lifecycle approach is useful for documenting owners, testing, monitoring, and response.

Optimize expected loss, not a single metric

Accuracy is usually misleading for rare fraud. Evaluate precision, recall, false-positive rate, approval impact, calibration, and monetary outcomes by relevant slices. A simple decision cost can include fraud loss, authentication cost, interchange or processing cost, customer abandonment, and support burden.

Thresholds should reflect asymmetric consequences. A false decline can lose a good customer; a false approval can create fraud loss and operational work. Report both, and check whether performance differs across regions, devices, customer tenure, or other legally and ethically reviewed segments.

Close the delayed-label loop

Fraud labels arrive late and imperfectly through disputes, confirmed account takeover, investigation, and recovery. Store the label source and observation window. Do not treat every chargeback as fraud or every unreported transaction as legitimate.

Case management is asynchronous. Investigators need the decision evidence available at the time—not a reconstruction using today’s features and model. Their outcomes feed a governed training dataset with leakage checks, lineage, and approval. Compare production decisions with later outcomes to detect drift and threshold decay.

Operate the whole decision system

Monitor latency, errors, feature freshness, reduced-mode use, score distribution, rule hit rate, step-up rate, approval, confirmed loss, false positives, and label maturity. Shadow a candidate model before promotion and retain a rapid rollback path. Repeated trials and segment-level evaluation matter because aggregate averages hide tail failures.

My design rule is to keep the synchronous path small and deterministic, then move enrichment, investigation, training, and analytics off it. Under 100 ms can then be an honest SLO for a defined boundary—not a promise detached from financial outcomes.

Before promotion, run the candidate against a time-separated, versioned dataset and a production shadow stream. Review performance by material segments, repeat trials when inference is nondeterministic, and define rollback thresholds before seeing the result. Validate the degraded feature set as a separate decision system. Finally, confirm that investigators can reconstruct a historical decision without retrieving mutable features from today’s store.

Related reading

• Idempotency at Scale: More Than a Request Header
• Double-Entry Ledger Architecture for Product Engineers

References

• EMVCo: EMV 3-D Secure
• EMVCo: 3-D Secure Specification v2.3.1 hub
• NIST: AI Risk Management Framework 1.0