Instant Payments Fraud Architecture: Real-Time Risk Scoring at Rail Speed

A card payment gives a fraud team hours or days of grace. Authorisation can be declined in flight, a chargeback can reverse a bad settlement weeks later, and the scheme rules assume the money can move backwards. An instant credit transfer offers none of that. Once the receiving bank accepts the message, the funds are final, and the only window in which instant payments fraud can be stopped is the few hundred milliseconds between the customer pressing send and the sending bank releasing the message to the rail.

That window is getting more valuable and more dangerous at the same time. FedNow’s network limit rose to $10 million in November 2025, the RTP network’s limit is also $10 million, and the EU Instant Payments Regulation has obliged euro-area banks to send and receive instant euro transfers since 2025. More value, more reach, and no clawback mean the control stack in front of the rail is now the primary risk instrument.

This article lays out a reference architecture for that stack: where the latency budget goes, how scoring pipelines are built, how payee verification fits, and what fails in production.

What this covers: the structural difference between instant rails and legacy rails, a layered reference architecture, a worked latency budget, the feature and model design that fits inside it, confirmation of payee, receiving-side mule controls, and the failure modes that catch teams out.

This article is a systems and architecture analysis, not financial, legal, or compliance advice.

Context and Background

Three public rails dominate the discussion in this article. FedNow, operated by the Federal Reserve Banks, settles instant credit transfers in central bank money around the clock. The RTP network, run by The Clearing House, is the US private-sector equivalent. In Europe, SEPA Instant Credit Transfer (SCT Inst) is the scheme, now mandated for euro-area payment service providers by Regulation (EU) 2024/886. India’s UPI and the UK’s Faster Payments are close relatives with their own rules. For a rail-by-rail comparison of how they clear and settle, see our real-time payment infrastructure comparison of FedNow, UPI and SEPA Instant.

The limits have moved fast. According to the Federal Reserve Banks, the FedNow limit rose from $500,000 to $1 million on June 24, 2025, and the Fed announced a further rise to $10 million effective November 2025 (Federal Reserve Financial Services announcements). The Clearing House reports that the RTP limit moved from $1 million to $10 million in early 2025, and that payment value on the network more than tripled between January and March of that year, from roughly $28 billion to over $84 billion, as high-value use cases arrived. The same source reports that fraud on RTP is very low, on the order of a hundred fraudulent transactions per month against about 35 million total. Treat those as the operator’s own figures, not an audited industry benchmark.

In Europe the legal timeline is explicit. The European Central Bank summarises it this way: euro-area PSPs had to be able to receive instant payments from January 9, 2025 and send them from October 9, 2025, with the verification of payee service due on October 9, 2025. Non-euro member states follow with receiving on January 9, 2027 and sending and verification on July 9, 2027. Charges for instant transfers may not exceed those for standard transfers, and the verification service must be free to the payer. The regulation also requires sanctions screening of customers on a daily basis rather than per transaction, a design choice that exists precisely because a ten-second execution deadline makes per-payment screening impractical.

Why does irrevocability change the engineering? Because every legacy fraud control assumed a second chance. ACH fraud teams rely on return windows. Card fraud teams rely on authorisation holds and chargebacks. On an instant rail the second chance is a request for return, which the receiving bank is free to refuse and which is worthless once the beneficiary has moved the money on within minutes. Industry commentary routinely describes “authorised push payment” (APP) fraud, where the victim is socially engineered into sending the payment themselves, as the dominant loss pattern on these rails. The architecture below is built for that reality: stop the payment before release, and make the receiving side hostile to mule accounts.

There is also a regulatory pull. In the UK, the Payment Systems Regulator’s mandatory APP reimbursement regime has applied to Faster Payments and CHAPS payments made from 7 October 2024, with a maximum reimbursement of £85,000 per claim and reimbursement expected within five business days of a claim, subject to a pause of up to 35 business days for assessment. When the losses land on the bank, the control stack becomes a balance-sheet decision, not only a customer-experience one. Our companion piece on verification of payee for instant payments covers the name-check mechanics in more depth, and the broader real-time fraud detection architecture post covers the generic streaming ML pattern this article specialises.

The Reference Architecture: A Pre-Release Control Plane

The core design principle is simple to state: the sending bank owns a synchronous pre-release decision point that no instant payment can bypass, backed by an asynchronous learning loop that never sits in the critical path. Everything else follows from keeping those two paths separate.

Direct answer. A fraud architecture for instant rails places a low-latency decision engine between the channel and the rail adapter. It assembles precomputed features, runs rules, a machine-learning scorer and payee checks in parallel, and returns allow, step-up, hold or block within a budget of tens to low hundreds of milliseconds, while a separate case-management and retraining loop learns from outcomes.

Figure 1: Reference architecture for instant payments fraud control, showing the synchronous pre-release path and the asynchronous feedback loop.

Figure 1 reads top to bottom. The channel (mobile app, online banking, corporate API, or a batch file exploded into individual instructions) submits a payment to a gateway that normalises it into a canonical internal model. That model is deliberately rail-neutral: a payer, a payee account, an amount, a purpose, device and session context, and a requested execution time. Rail-specific syntax, such as the ISO 20022 pacs.008 customer credit transfer message used by FedNow, RTP and SEPA Instant, is produced late by the rail adapter, not early by the channel. The practical benefit is that risk logic is written once and reused across every rail the bank connects to, which matters when a bank joins FedNow and RTP and SEPA Instant within the same year. For the message-level background, see our ISO 20022 migration architecture analysis.

Feature assembly: precompute everything you can

The gateway calls a feature assembly layer that builds a vector for the scorer. The central design decision is what is computed at request time and what is precomputed. In an instant-payment context, almost nothing should be computed from raw history at request time. A query that scans ninety days of transactions for a customer is a tail-latency incident waiting to happen.

Instead, streaming jobs maintain rolling aggregates keyed by customer, by payee account, by device, and by the customer-payee pair: counts and sums over one minute, one hour, one day and thirty days, the number of distinct new payees in the last day, the age of the payee relationship, and the time since the last password or device change. The decision engine performs key-value lookups against a low-latency store, typically in-memory or SSD-backed, and merges them with request-time features such as amount, hour of day, and the session’s behavioural signals. This split between a streaming write path and a point-lookup read path is the standard shape of an online feature store, and it is what keeps the read path flat as volume grows.

Three parallel evaluators, one decision engine

Figure 1 shows three evaluators feeding the decision engine, and they exist for different reasons.

The rules and limits evaluator enforces deterministic constraints: per-customer and per-segment velocity and value limits, sanctions and internal deny-list hits, regulatory blocks, and operator limits such as the rail’s maximum transaction amount. Rules are not legacy baggage. They are the only component whose behaviour a compliance officer can explain line by line, and they are the fastest way to respond to a newly observed scam typology on the day it appears. FedNow itself exposes participant-side tools of this kind: the Federal Reserve describes account activity thresholds, letting a bank limit dollar amount and transaction speed by customer segment, as part of the service’s risk management tooling.

The ML scorer estimates the probability that this payment is fraudulent or coerced given the full feature vector. It generalises where rules cannot, picking up combinations such as a new payee, a large amount, an unusual hour, and a remote-access tool running on the device.

The payee and network checks evaluator asks whether the destination is trustworthy: does the name match the account (the verification of payee result), is the receiving account newly opened, has it appeared in a consortium or internal mule list, and does the receiving institution have a poor outbound-fraud record. This evaluator is the one that most distinguishes instant-payment fraud architecture from card fraud architecture, because the beneficiary is a bank account, not a merchant.

The decision engine combines the three outputs under a policy. It is a distinct component, not a line in the scorer, for a practical reason: policy changes weekly while models change quarterly. Keeping thresholds, tier boundaries, segment overrides and reason-code mappings in a versioned policy layer lets risk operations tune behaviour without a model deployment.

The asynchronous half

The bottom of the diagram is the part most teams under-invest in. Every decision, whether released, held, stepped up or blocked, writes to case management with its full feature snapshot and the policy version that produced it. Analysts, customer contacts, recall outcomes and confirmed-fraud reports turn those cases into labels. Labels flow into retraining and into rule authoring. The snapshot matters: when a model is retrained months later, it must learn from the features as they looked at decision time, not as they look now, otherwise point-in-time leakage produces models that look excellent offline and degrade in production.

Deeper Analysis: Latency Budgets, Scoring Design and Tiered Decisions

The latency budget is a contract, not a target

Every instant rail imposes an end-to-end deadline. SEPA Instant, and the Instant Payments Regulation that mandates it, expects funds to be made available to the beneficiary within ten seconds of the payment order being received. FedNow and RTP are similarly built around seconds-scale completion with timeouts the participants must respect. The customer-facing experience is usually faster, and the fraud decision is allowed only a small slice of the overall time because the channel, the rail round trip, and the receiving bank all consume their own share.

The budget below is illustrative, intended to show how a team should decompose the allowance, not a measured benchmark or a rail requirement. The numbers are an engineering planning example for a decision that must complete in well under half a second at the 99th percentile.

Stage	Illustrative p99 allowance	What it covers
Gateway and normalisation	10 to 20 ms	Authentication, schema validation, canonical model
Feature lookups	15 to 40 ms	Parallel key-value reads, session features
Rules and limits	5 to 15 ms	In-memory evaluation of compiled rules
ML inference	10 to 40 ms	Gradient-boosted trees or a small neural model
Payee and network checks	30 to 120 ms	Name verification call, internal and consortium lookups
Decision and logging	5 to 15 ms	Policy evaluation, asynchronous write to the audit stream

Two rules govern how this budget is managed. First, the stages that must call outside the bank, principally the verification of payee request to the beneficiary’s institution, are the long pole, so they are started the moment the payee details are known and are frequently completed before the customer even presses confirm. Second, every stage has a timeout and a fallback behaviour defined in advance, because the p99.9 matters more than the median when the downside is an unscreened irrevocable payment.

Figure 2: Where the fraud decision sits in the instant credit transfer flow, between customer submission and the pacs.008 release to the rail.

Figure 2 shows the control point in the message flow. The payer’s submission reaches the sending bank’s gateway, the risk engine returns a decision with reason codes, and only then does the gateway create and send the pacs.008 to the rail. The rail forwards it to the receiving bank, which runs its own inbound checks and replies with a pacs.002 status report that is either an acceptance or a rejection. The sending bank learns the final status from the rail and informs the customer. The detail that matters is that the sender’s decision happens strictly before release, while the receiver’s decision happens before acceptance, so the system has two independent chances to stop a payment, in two different institutions with different information.

Fail-open, fail-closed, and fail-degraded

When the risk engine is slow or unavailable, the gateway must choose. Fail-open releases the payment unscored and is a gift to fraudsters, who can induce load. Fail-closed rejects everything and turns a risk-system hiccup into a payments outage, which on a 24/7/365 rail is its own incident with its own regulatory attention.

The defensible pattern is fail-degraded: a lightweight, local, always-available fallback path. It runs a small set of hard rules, such as per-customer value limits and deny-lists held in the gateway’s own memory, plus a conservative cached score or a simpler model. Under degradation, thresholds tighten, so that new payees and high amounts go to step-up or hold rather than release. The key engineering requirement is that the degraded path shares no network dependency with the primary path, otherwise the same outage takes out both.

Model design for a 20-millisecond decision

Gradient-boosted decision trees remain the workhorse for tabular payment features because they deliver strong accuracy with predictable, small inference latency and straightforward explanation through feature attribution. Neural sequence models over a customer’s recent history can add value for behavioural patterns, but they carry heavier serving cost and are typically used as an extra input feature (an embedding or a sequence score) rather than as the sole decider.

Class imbalance is severe. Confirmed fraud is a tiny fraction of payments, and the labels that exist are biased toward what the previous system caught. Three practical consequences follow. Train on time-based splits, never random splits, because fraud tactics drift. Evaluate on precision at a fixed review capacity or on value-weighted recall, not on accuracy or an unqualified area under the curve. And treat the decision threshold as an operational variable set by the cost of a false positive (a held legitimate payment, customer friction, analyst time) against the cost of a miss (an irrevocable loss, plus reimbursement under regimes like the UK’s).

Coerced payments make the problem harder than classic account takeover. In an APP scam, the genuine customer, on their genuine device, authenticates correctly. The device, location and credentials all look right. What is anomalous is the behaviour: an unusually large first payment to a brand-new payee, a hesitant session with long idle gaps, a phone call in progress on the same device, the customer editing the amount upward, or pasting an account number rather than choosing a saved payee. Behavioural biometrics and session telemetry therefore matter more here than in card fraud, and the policy should lean on payee-side signals, since the beneficiary is the part the scammer cannot disguise as familiar.

Tiered decisions: friction proportional to risk

A binary allow or deny wastes the information in the score. The decision engine should return a tier, and the tiers should map to different customer experiences, as Figure 3 shows.

Figure 3: Risk tiers and their outcomes. Medium risk triggers friction the customer can resolve; high risk routes to a human; critical risk blocks and reports.

At the low tier the payment is released immediately, and this tier should carry the overwhelming majority of traffic, because the value of instant payments is speed. The medium tier introduces targeted friction, and the research on scam interventions suggests the content of the friction matters more than its quantity. A generic “are you sure” prompt is habituated away within days. A specific, contextual warning, such as “you are paying a new account whose name does not match the name you entered, and this payment cannot be recalled”, changes behaviour because it addresses the exact scam script the victim is following. Step-up authentication helps for account takeover but does little against a genuine customer being coached, so the warning, not the extra password, is the control that matters.

The high tier holds the payment for review. On a rail with a ten-second deadline, “hold” needs careful definition: either the sender’s institution rejects the instruction back to the customer with a request to contact the bank, or, where scheme rules allow, uses a short processing delay. It does not mean parking a pending message indefinitely. Many institutions therefore pair the hold tier with a callback or in-app chat flow that lets the customer resubmit once an agent has spoken to them. The critical tier blocks and reports, feeding the deny-list and any consortium channels the bank participates in.

Confirmation of payee as a first-class signal

Confirmation of payee, called verification of payee (VoP) under the EU regulation, is the control that directly attacks misdirection fraud, where a payer is tricked into paying the wrong account, and invoice-redirection scams in particular. The ECB describes the EU service as returning one of four results, match, close match, no match or other, before the payment is initiated, and the regulation requires that the service be offered to payers free of charge across both instant and standard SEPA credit transfers.

Architecturally, VoP is a request-response exchange between the payer’s bank (the requesting PSP) and the payee’s bank (the responding PSP), typically routed through a scheme or a routing and verification mechanism rather than bilateral connections. Three design points matter for fraud engineers.

First, VoP is evidence, not a decision. A “no match” is a strong risk signal, but it is also what an honest typo produces. The right treatment is to feed the result, and the customer’s reaction to it, into the scorer. A payer who sees “no match”, reads the warning, and proceeds anyway to a new account for a large amount is exhibiting a risk pattern the bank should weigh. The decision engine should record whether the customer overrode a warning, because that field is valuable in both scoring and later liability disputes.

Second, latency belongs to the other bank. The responding PSP’s speed is outside the requester’s control, so the call needs a strict timeout and a defined result for “no answer”, conventionally mapped to the “other” outcome. The verification request should be fired as early as possible, when the payee name and account are entered, and cached against the beneficiary for a short period so repeat payments do not repeat the call.

Third, name matching is a fuzzy problem with an adversarial edge. Close-match logic has to handle transliteration, abbreviations, legal-entity suffixes, and joint accounts, and it should resist gaming, for example a mule account opened in a name designed to be a plausible near-match for common supplier names. Our dedicated VoP architecture analysis covers matching algorithms and the scheme message flows. In the United States there is no equivalent universal scheme-level payee verification mandate that is comparable to the EU’s, so US institutions generally assemble the equivalent from account validation services, third-party data and their own signals. Treat that as a general observation rather than a statement about any single institution.

The receiving bank is half the control

Most public discussion focuses on the sender, but the receiving institution holds the information that actually identifies mules: account age, how quickly funds arrive and leave, whether the account has ever received a payment from this sender, whether the holder’s profile resembles the inbound value, and whether the account is linked by device or identity attributes to previously flagged mules. Under the UK reimbursement regime, the cost split between sending and receiving firms was designed to give receivers exactly this incentive, with the PSR describing a requirement that reimbursement costs be shared between the two.

An inbound control stack looks like a mirror of the outbound one, with different features. It scores each incoming instant credit before accepting the pacs.008 and may reject, accept and hold funds as unavailable pending review, or accept and flag. Whether a receiving bank may hold or delay credit depends on scheme rules and local law, so the “accept and restrict onward movement” option is a legal design question as much as a technical one.

The feature set emphasises pass-through behaviour. A legitimate account typically receives funds and keeps or spends them in recognisable patterns. A mule account receives a series of unrelated inbound credits and rapidly sends the value onward, often split across several rails, which is why the structure in Figure 4 cycles through before, during and after settlement, and why the outbound scorer on the mule account’s own payments is a control against the second hop of the scam.

Figure 4: Control layers across the payment lifecycle, from onboarding and device trust to post-settlement recall requests, with a feedback loop into shared intelligence.

Graph signals and consortium data

Mule detection is naturally a graph problem. Accounts connect through shared devices, shared addresses, shared phone numbers, shared beneficiaries, and money flow. Graph-derived features, such as the size of the connected component, the distance to a known mule, or the number of distinct senders in the last day, are computed offline or in a streaming graph job and written into the same feature store, so the online path remains a lookup. Computing graph traversals inside the request path is a recurring and avoidable mistake.

No single bank sees the whole network. Consortium and shared-intelligence arrangements let institutions exchange confirmed-mule indicators, with the privacy, data-protection and legal constraints that implies. These arrangements are typically jurisdiction-specific and sector-governed, so the architectural requirement is a clean, auditable interface for ingesting external indicators and a way to record which source produced which signal.

After the money moves: recall and request for information

Post-settlement tooling is a damage-limitation layer, not a prevention layer. ISO 20022-based rails include messages for requesting a return of funds (the camt.056 payment cancellation request is the standard family member) and for the receiving bank’s response, and many schemes also support request-for-information style exchanges. The Clearing House’s published material does not detail specific recall features in the article cited here, so check the current rulebook of each rail for the exact procedure and timelines. The architectural point is general: recall success decays with every minute, because mules move money fast, so recall initiation should be automatic and triggered by the case management system the moment fraud is confirmed, not by an analyst opening a form hours later.

Deeper Analysis: Rules, Models, and the Operational Machinery

Rule design that survives contact with attackers

A mature rule set is short, layered and measured. Hard limits and deny-lists sit at the front. Typology rules, each tied to a named scam pattern and carrying an owner, sit in the middle. Experimental shadow rules, which log what they would have done without acting, sit at the back, and graduate when their precision is proven on live traffic.

Every rule should have an expiry or a review date. Rule sets rot: a rule introduced in a spike of investment scams two years ago continues to generate holds on genuine payments long after the scam shifted. Tracking per-rule precision, value saved, and customer-friction cost, then retiring rules that no longer earn their place, is routine hygiene that most teams skip until the false-positive rate becomes a board topic.

Velocity limits as the cheapest robust control

Instant-payment risk tooling from the operators themselves leans on limits. FedNow provides participants with account activity thresholds, and the Federal Reserve describes them as allowing a bank to limit dollar amounts and transaction speed by customer segment. The underlying idea is old and effective: cap the damage per customer per time window, and scale the cap with the established trust of the relationship.

A sound limit design is dynamic and tiered. A new customer in their first thirty days gets conservative cumulative limits. A long-standing customer with a clean history gets higher ones. Increases require authentication or a cooling-off period, and a recent change of device, phone number or credentials temporarily lowers the limit. Cooling-off on limit increases defeats the attacker who takes over an account and immediately raises the limit to drain it. Corporate customers need limits that reflect business patterns, including approver workflows, and the account activity thresholds can be set per segment so a treasury customer is not treated like a retail one.

Monitoring the models themselves

Models degrade in ways that are invisible without instrumentation. Four monitors are worth the investment. Feature drift monitors compare live feature distributions with training distributions. Score distribution monitors track the share of traffic in each tier by hour and segment. Outcome monitors track confirmed fraud and false-positive proxies on a lag, since labels arrive days or weeks late. And latency monitors track per-stage p50, p99 and p99.9, because a slowly increasing feature-store latency will eventually push the whole decision beyond its budget.

Because confirmed labels lag, teams use proxy labels (customer-reported fraud, recall requests, mule-flagged beneficiaries) and accept that the freshest weeks are always under-labelled. Training pipelines should mask that incomplete recent window, otherwise the model learns that last week was fraud-free.

Explainability and the audit trail

Regulators and customers increasingly want reasons. Every decision should store the policy version, model version, top contributing features, rule hits, and the customer’s response to any warning. Reason codes shown to the customer should be written for the customer: “this account has been reported in connection with scams” is understandable, while a raw score is not. Reasons surfaced to the customer should also avoid revealing control thresholds, since attackers probe them. Storage design matters here: decisions are written to an append-only log, and the log is the system of record for disputes under reimbursement regimes and complaint handling.

Capacity and cost, in orders of magnitude

Rather than quote vendor figures, which vary and are rarely published, reason in orders of magnitude. If a mid-sized institution handles a few million instant payments per day, the average rate is tens of payments per second, but the peak, driven by paydays and promotions, can be one to two orders of magnitude above the average. The decision path has to be sized for the peak with headroom, horizontally scaled and stateless, with the feature store sized for the read rate, which is several lookups per decision. These numbers are planning heuristics, not measurements. Cost then divides into steady-state infrastructure for the online path, which scales with peak rate, and the much larger variable cost of analyst time, which scales with the hold tier’s volume. That second cost is the real optimisation target: a small improvement in precision at the hold tier saves more than any amount of inference optimisation.

Trade-offs, Gotchas, and What Goes Wrong

Friction habituation. Warnings that fire too often train customers to dismiss them. Reserve strong warnings for medium-high risk and make them specific. Measure the override rate per warning type, and treat a rising override rate as a control failure, not a customer failure.

The false-positive tax. Every held legitimate payment costs customer trust on a rail whose entire pitch is speed. Corporate customers paying suppliers at month-end are the most sensitive, and a bank that holds a large B2B payment at 5 p.m. on the last business day may lose the relationship. Segment-aware thresholds and rapid analyst service levels are not optional extras.

Label bias and feedback loops. If the system blocks the payments it is most suspicious of, those payments never produce a label of “fraud that would have succeeded”. The model then learns from a censored sample. Random holdout, where a small share of borderline cases is released under extra monitoring with appropriate governance, is the principled remedy, and it is a policy and legal decision as well as a technical one.

Attacker adaptation. Fraudsters test limits, split payments below thresholds, and rotate mule accounts. Static thresholds are probed within days. Cumulative and rolling-window rules, randomisation within safe bounds, and fast rule deployment narrow the gap, but there is no permanent fix.

Synthetic identity and mule onboarding. Much instant-payments fraud is decided at account opening. Strong onboarding checks, ongoing monitoring of newly opened accounts, and tight initial limits move the control left of the payment, where it is cheaper and does not sit in the latency budget.

Fail-open by accident. A timeout configured at the gateway but not honoured in a downstream library, or a retry that re-sends a payment without re-scoring it, quietly creates an unscored path. Idempotency keys on payment instructions, with the decision bound to the key, close this hole. Pen-test the degraded path as carefully as the primary one.

Over-reliance on payee verification. A “match” result is not an all-clear. A scammer who persuades the victim to pay a mule account in the scammer’s own name returns a perfect match. VoP defeats misdirection and some impersonation; it does not defeat coercion where the payee is the fraudster.

Regulatory fragmentation. Reimbursement liability, hold rights, data-sharing permissions, and screening obligations differ by jurisdiction. A bank operating on FedNow, RTP and SEPA Instant needs a policy layer parameterised by jurisdiction, not three forked codebases.

Practical Recommendations

Start with the decision point, not the model. Establish a single synchronous pre-release gateway that every channel and every rail must traverse, and make bypass structurally impossible. Only then invest in model sophistication, because a brilliant model behind a bypassable path protects nothing.

Next, define your budget and your fallbacks before you define your features. Agree the p99 allowance for each stage with the rail’s deadline in mind, choose a fail-degraded behaviour that is locally evaluated, and test it under load and under dependency failure.

Treat payee-side signals as first-class. Integrate payee verification where it is available, record customer overrides, and invest in the receiving-side controls, because on an irrevocable rail the mule account is the choke point. Feed everything through a single feature store with point-in-time snapshots so that training and serving agree.

Close the loop. Automate recall and request-for-information the moment fraud is confirmed, route confirmed mule indicators into deny-lists and consortium channels, and review rule and model performance on a fixed cadence.

A short checklist to carry away:

• One pre-release decision gateway, no bypass, idempotent by payment key.
• Stage-by-stage latency budget with timeouts and a documented fallback per stage.
• Precomputed rolling features, graph features computed offline, request-path lookups only.
• Policy layer separate from models, versioned, with jurisdiction parameters.
• Tiered outcomes: release, targeted warning, hold, block.
• VoP result and customer override logged and scored.
• Inbound scoring and pass-through detection on the receiving side.
• Automatic recall on confirmed fraud, with case management owning the trigger.
• Per-rule and per-model monitoring, with a rule-expiry process.
• Immutable audit log of every decision with reasons.

Frequently Asked Questions

Why is fraud harder to stop on instant payments than on cards or ACH?

Because settlement is final and fast. Cards have authorisation holds and chargebacks, and ACH has return windows, so a bad payment can be unwound days later. An instant credit transfer is irrevocable once accepted, and a mule can forward the money within minutes. The decision therefore has to be right before release, and recall can only be a best-effort supplement.

How fast must a real-time fraud decision be?

It must fit inside a small share of the rail’s end-to-end deadline. SEPA Instant requires funds to reach the beneficiary within ten seconds, and the customer expects a response in about a second or two, so engineers typically budget tens to low hundreds of milliseconds at p99 for the whole decision. Any such figure is a design choice, not a published rail rule.

What is confirmation of payee and does it stop fraud?

It is a pre-payment check that compares the payee name the customer typed with the name on the destination account and returns a match, close match, no match or other result. It strongly reduces misdirected payments and some invoice-redirection scams, but it cannot stop coercion where the customer knowingly pays an account held by the fraudster.

What are FedNow’s fraud controls?

The Federal Reserve describes account activity thresholds that let participants limit dollar amount and transaction speed by customer segment, within a network limit that was raised to $10 million in November 2025. Beyond these built-in tools, each bank is expected to run its own scoring, payee, and monitoring controls, because the rail itself does not replace a bank’s fraud programme.

Who bears the loss when a customer is scammed on an instant rail?

It depends on the jurisdiction. In the UK, the PSR regime in force since 7 October 2024 requires reimbursement of most APP fraud up to £85,000, with costs shared between sending and receiving firms. In other markets, liability rules differ and are evolving, so institutions should confirm obligations with their legal and compliance teams before designing around them.

Should a bank build or buy its instant payments fraud engine?

Most institutions buy the model-serving and case-management platform and build the policy layer, feature definitions and integration. The differentiator is data: your features, your labels, and your payee signals. Whatever the choice, require the vendor to expose decision latency per stage, support point-in-time feature snapshots, and allow fast rule deployment.

Further Reading

• Real-time payment infrastructure: FedNow, UPI and SEPA Instant compared
• Verification of payee for instant payments: architecture in 2026
• ISO 20022 migration: payments architecture in 2026
• Agentic payments architecture and AI commerce
• Real-time fraud detection architecture
• External: ECB: Instant Payments Regulation, Federal Reserve Financial Services: FedNow $10 million limit, PSR: APP fraud reimbursement protections, The Clearing House: RTP $10M limit

By Riju — about