AI Fraud Detection in Real-Time Payments: Architecting ML That Catches Attacks in Milliseconds

If you are building or operating a real-time payments platform in 2026, you already know that rules-based fraud detection is dead. Attackers use generative AI to produce thousands of synthetic identities per hour, payment rails like FedNow and SEPA Instant settle in under 10 seconds, and authorised push payment (APP) fraud alone cost UK consumers £460 million in 2025 according to UK Finance. The only way to keep up is machine learning operating at the wire — feature computation, model inference, and a decision returned before the payment completes.

The modelling is the easy part. The hard part is building the infrastructure to serve those models at sub-100-millisecond latency, with features computed from streaming data, with rules and models running in the same decision pipeline, and with explainability that satisfies regulators.

Who Is This Guide For?

This guide is for payments engineers, data platform architects, and fraud analytics teams building or modernising fraud detection infrastructure for real-time payment systems. If you are moving from batch scoring to streaming ML, evaluating feature store architectures, or dealing with regulatory expectations around model explainability, this is for you.

By the End of This, You’ll Know…

• Why rules-based fraud detection fails against modern attacks and what a streaming ML architecture looks like
• How to design a feature store that serves fraud signals in under 50 milliseconds
• What latency budgets actually look like across FPS, FedNow, and SEPA Instant
• How to combine rules, ML models, and graph-based detection in a single decision pipeline
• What regulators expect from an automated fraud detection system — including the EU’s Instant Payments Regulation

Why Rules-Based Systems Are Failing

Traditional fraud detection relies on static rules: if the transaction exceeds £5,000 from a new device, flag it. These rules worked when fraudsters used deterministic patterns. They do not work in 2026 when a single attacker can spin up 10,000 synthetic accounts, each with unique device fingerprints, realistic transaction histories, and behavioural profiles generated by an LLM.

The numbers tell the story. A 2026 Plaid report found that 67% of fintechs cite increasingly sophisticated fraud as their top challenge. Mastercard reported that AI-powered fraud detection saved banks $20 billion in 2025 by catching synthetic identity rings that rule-based systems missed entirely. The UK’s Payment Systems Regulator now mandates reimbursement for APP fraud victims — making the cost of missed fraud directly visible on the balance sheet.

The fundamental failure mode of rules-based systems is dimensionality. Fraud patterns sit in a high-dimensional space of transaction amount, device characteristics, location, behavioural history, merchant profile, and time-of-day patterns. A rule that catches one attack vector misses fifty others because no human analyst can write rules that span 200+ features simultaneously. Machine learning models can — but only if the infrastructure serves those features in real time.

The Streaming ML Architecture

The architecture that works at scale has three layers: a feature computation layer, a model serving layer, and a decision orchestration layer.

Feature Computation Layer: When a payment request hits your gateway, you have roughly 100-200 milliseconds to decide whether to approve, decline, or flag for review. Within that window, you need to compute features from streaming data — the user’s last 50 transactions, device characteristics, location velocity, merchant risk scores, and network behaviour signals. This requires a feature store that is not a batch data warehouse. You need in-memory, sub-millisecond access to pre-computed aggregates that are updated continuously as new transactions arrive.

The right technology stack for this layer in 2026 looks like Apache Kafka for event ingestion, Apache Flink or RisingWave for real-time feature computation, and Redis or a purpose-built feature store like Tecton or Feast for serving. Kafka streams raw payment events into Flink jobs that maintain sliding window aggregates — transaction count in the last hour, average amount, velocity of new merchants, device changes. These aggregates update in real time and are pushed to Redis with a key formed from the user ID and account ID.

Model Serving Layer: Once features are assembled, the model inference must complete in 10-50 milliseconds. This means no round-trips to a GPU cluster for every transaction. The model must be deployed as a lightweight inference service co-located with the feature store — ideally in the same Kubernetes pod or at least the same availability zone. ONNX Runtime, TensorFlow Serving, or a custom C++ inference engine with pre-loaded model weights are the standard approaches. Gradient-boosted trees (XGBoost, LightGBM) remain the workhorse model type for real-time fraud because they are fast, interpretable, and handle tabular data well. Deep learning models add marginal accuracy for most payment fraud use cases but at significantly higher inference latency.

Decision Orchestration Layer: This is where models, rules, and external signals combine into a single decision. The orchestration engine must support a decision graph: rule A fires first and routes to model B for scoring, which feeds into rule C for threshold evaluation, which may trigger an external API call to a third-party device reputation service, with the final decision logged for regulatory audit. Platforms like FeatureByte, Nected, or custom-built decision engines using Temporal or AWS Step Functions handle this orchestration.

Latency Budgets Across Payment Rails

Different payment systems impose different latency constraints, and your architecture decisions flow directly from which rails you support:

The tightest constraint is UPI in India, where payment apps must return a response within roughly 300 milliseconds of receiving the payment instruction. FedNow in the US is similarly demanding, with a 200-500 ms window. If your architecture handles UPI latency, it handles everything else.

Graph-Based Detection for Synthetic Identity Rings

The most challenging fraud pattern in 2026 is the synthetic identity ring. A fraudster generates thousands of identities using an LLM, opens accounts across multiple financial institutions over months, builds transaction histories that look legitimate, and then executes a coordinated attack. Individual transactions look normal, so point-in-time models miss them entirely.

Graph-based detection catches these rings by connecting entities through shared characteristics. If 47 accounts opened in the last three months share the same device fingerprint variant, use the same type of password pattern, and transfer to a small set of common beneficiary accounts, that is a fraud ring regardless of how realistic each individual account looks.

The technology for this is a graph database — Neo4j or Amazon Neptune — holding an entity graph of users, accounts, devices, IP addresses, and merchants. When a transaction arrives, the orchestration layer queries the graph for connected entities within k-hops and feeds graph features (neighbourhood density, shared device count, cluster coefficient) into the ML model alongside transaction features. Graph queries add 10-20 ms to the decision pipeline, which is acceptable for FedNow’s 200-500 ms window but tight for UPI’s 100-300 ms constraint.

Regulatory Expectations

The EU’s Instant Payments Regulation, effective from April 2026, mandates that payment service providers must implement real-time fraud detection for instant credit transfers. This is not optional. The regulation explicitly requires that fraud detection systems assess each transaction against the payer’s historical behaviour patterns and flag anomalies before settlement.

The UK’s APP fraud reimbursement scheme, also effective 2025, requires banks to reimburse victims of authorised push payment fraud within 5 business days — up to £415,000 per claim — unless the bank can demonstrate that its fraud detection system met reasonable standards. In practice, this means you need auditable evidence that your ML model scored the transaction and that the score was within acceptable parameters. Model explainability is no longer a nice-to-have — it is a legal requirement.

This is where SHAP (SHapley Additive exPlanations) values and LIME (Local Interpretable Model-Agnostic Explanations) become operational tools, not just Jupyter notebook experiments. For every declined or flagged transaction, you must be able to explain which features contributed most to the score — transaction amount, device age, velocity of new payees, geographic anomaly — and by how much. Platforms like Arize AI, Fiddler, and WhyLabs integrate this explainability into production model monitoring pipelines.

Where to Start

If you are building fraud detection infrastructure from scratch, start with the feature store. The model will iterate, the rules will change, but the feature computation pipeline is the foundation everything else depends on. Deploy Kafka for event streaming, Flink for windowed aggregates, and Redis for serving. Build the first version with 20-30 features and a single XGBoost model. Measure latency end-to-end from payment gateway ingress to decision response. Then iterate.

If you are migrating from batch to real-time, the highest-value first step is moving your feature computation from nightly batch jobs to streaming windows. The model itself can stay the same during the transition — the feature freshness improvement alone typically reduces fraud losses by 15-25% because the model sees behaviour patterns that are minutes old rather than 24 hours stale.

Further Reading

• Mastercard: AI Is Helping Banks Save Millions by Transforming Payment Fraud Prevention (2026)
• Plaid: 10 Fintech Trends Defining the Industry in 2026
• Redis: AI in Payment Processing — Real-Time Fraud Detection Architecture

For more on financial data platforms and real-time analytics, see our comparison of ClickHouse vs kdb+ vs TimescaleDB. For event-driven architectures in payment systems, see our guide to event-driven architectures for payments. For the broader capital markets technology picture, see our services page on Trading & Market Systems Engineering.