Traditional automated transaction monitoring works because of a delay most people never notice. A payment is initiated, it enters a clearing cycle, and somewhere between a few hours and a few days later it settles. That gap was never designed as a compliance control, but it became one. It gave institutions a window in which a suspicious payment could be reviewed, held, escalated to a human, and in many cases stopped before the money left the building.
Real-time payments closed that window. Funds settle in under ten seconds, the transfer is irrevocable, and it can happen at any hour on any day of the year. Every structural assumption behind a batch-era monitoring stack fails at the same moment. This is why so many institutions that migrated to instant rails found their alert volumes rising while their actual interception rate fell. The rules were not wrong. The operating model underneath them had quietly stopped existing.
The rails moved faster than the controls
The shift has been global and unusually quick. The UK has run Faster Payments since 2008. The Clearing House launched RTP in the United States in 2017, followed by the Federal Reserve’s FedNow service in July 2023. Brazil introduced Pix in late 2020 and saw it become a default payment method for a large majority of the adult population within a few years, according to central bank figures. India’s UPI now processes well over fifteen billion transactions a month on NPCI’s own reporting. SEPA Instant Credit Transfer arrived in Europe in 2017 and has since been made effectively compulsory.
That last point matters more than it appears. The EU’s Instant Payments Regulation, adopted in 2024, required euro area payment service providers to be able to receive instant euro payments from January 2025 and to send them from October 2025. Instant payments stopped being a competitive product decision and became a regulatory obligation. Institutions that had planned a phased three-year modernisation of their financial crime stack found themselves needing to support twenty-four-hour, seconds-level settlement on a fixed statutory deadline.
Most of them bridged the gap with the systems they already had. That is the origin of the problem this article is about.
Four assumptions that no longer hold
1. There is time to review before the money moves
Legacy monitoring is fundamentally retrospective. Transactions are aggregated, scored overnight, and surfaced as alerts for an analyst to work the following morning. In a T plus one world, that is defensible, because the analyst can still act. On an instant rail, an alert raised at nine the next morning is not a control at all. It is a record of something that already happened.
2. A payment can be recalled
Card networks have chargebacks. ACH has returns. Instant payment schemes are built on the opposite principle: finality. A recall request on most instant rails is a polite enquiry to the receiving institution, not a mechanism. If the funds have been forwarded onwards, which in organised fraud they will have been within minutes, recovery becomes a legal process rather than an operational one.
3. Financial crime happens during business hours
Batch monitoring evolved alongside staffed compliance teams working a standard day. Instant rails run continuously, and fraud operations know it. Weekend nights and public holidays consistently show elevated risk precisely because the human layer of the control is thinnest. If your monitoring is only as fast as the analyst who reviews the queue, your genuine coverage is a fraction of what your policy documents claim.
4. Yesterday’s data is good enough to score today’s payment
A rule that flags unusual behaviour needs to know what usual looks like. If the customer profile feeding that judgement was last refreshed in an overnight job, the system is blind to everything that has happened since, including the six preceding payments in the same laundering chain. Instant payments compress layering from days into minutes, and a stale profile cannot see it.
Authentication stopped being the control
The most significant consequence of instant settlement is a change in the shape of fraud itself. Authorised push payment fraud, where the victim is manipulated into authorising a genuine payment from their own account, has become the dominant loss category on real-time rails in mature markets. UK Finance reported APP losses of roughly £450 million in 2023, easing to somewhere near £340 million in 2024 following intervention.
The reason this matters for monitoring is simple. Every authentication control performs perfectly during an APP fraud. The right customer, on the right device, in the right location, with the correct credentials and a valid biometric check, deliberately instructs the payment. Strong customer authentication passes. Device fingerprinting passes. The only signal available is that the behaviour is wrong for that person, sent to a counterparty that does not fit their history, at a velocity that does not fit their pattern.
Regulators have responded by moving liability rather than by prescribing technology. The UK’s mandatory reimbursement regime, in force from October 2024, requires losses up to a set cap to be reimbursed and splits the cost evenly between the sending and the receiving firm. That second half is the structural change. Receiving institutions now carry direct financial exposure for accounts that turn out to be mule accounts, which makes inbound monitoring a balance sheet issue rather than a courtesy to the sending bank. Any institution still treating inbound payments as somebody else’s risk is carrying an unpriced liability.
The sanctions screening paradox
There is a genuine technical contradiction at the heart of instant payments compliance. Screening every payment message against sanctions lists in real time introduces latency and generates a high volume of fuzzy name matches, each of which requires review. On a rail with a ten-second service level, that is not survivable at scale.
Europe’s answer in the Instant Payments Regulation was to change where screening happens. Rather than screening each transaction, payment service providers verify their own customer base against EU sanctions lists at least daily, immediately after any list update. Transaction-level screening for sanctions is reduced accordingly. Alongside this sits Verification of Payee, which checks the payee name against the account identifier and warns the payer before confirmation.
This is worth understanding as a design principle rather than as a regional rule. Sanctions screening is a matter of counterparty identity, and identity can be resolved before the payment ever occurs. Fraud and money laundering detection is a matter of behaviour, and behaviour can only be judged in the moment. Institutions that separate these two problems and solve each at the right point in the lifecycle end up with lower latency and fewer false positives than institutions that push everything into the payment path.
What real-time monitoring actually has to do
Rebuilding for instant rails is not a matter of running the same rules more often. Several things have to be true at once.
Decisioning has to sit inside the payment path: The scoring engine must return a verdict within the scheme’s latency budget, typically a few hundred milliseconds, with a defined and tested fallback for when it does not. Ask any vendor for the latency distribution rather than the average, because a system with a 90 millisecond mean and a 900 millisecond ninety-ninth percentile will breach obligations on exactly the payments that matter most. Complex cases are slow cases, and complex cases are where the fraud is.
Baselines have to be behavioural, not static: Fixed thresholds are trivially defeated by structuring, and on instant rails, structuring is cheap because there is no per-transaction friction to discourage it. A profile of how a specific customer normally behaves, updated continuously, catches what a universal threshold cannot.
Counterparty context has to be available at decision time: Mule networks are visible as networks long before any single account looks unusual. Many accounts receiving from many senders and forwarding onwards within minutes is a graph pattern, not a transaction pattern. Effective transaction monitoring on real-time rails increasingly depends on evaluating relationships between accounts rather than scoring payments in isolation, and that in turn depends on the underlying data being queryable inside the latency window. This is where most programmes actually stall. The detection logic is rarely the blocker; customer profiles, device signals, counterparty history and screening results sitting in systems that cannot be reached in 400 milliseconds usually are.
Intervention has to be tiered: Block or allow is too blunt for a rail where a false block becomes a customer complaint within seconds. Warning screens, step-up verification, holding only the second and subsequent payments in a sequence, and capping value while allowing the transfer all preserve service while reducing loss.
Every decision has to be explainable: Supervisors will ask why a payment was scored the way it was, and an answer of “the model decided” is not adequate. This is a hard constraint on model selection, not an afterthought to be handled by documentation.
The false positive problem gets worse before it gets better
Instant rails increase transaction volume, because friction was suppressing demand. They also increase the proportion of payments made to new counterparties, because paying a stranger instantly is now practical. Both of those changes push directly against the assumptions built into legacy rules, which typically treat a first payment to an unknown beneficiary as inherently suspicious.
Industry surveys have long put false positive rates in AML alerting well above ninety per cent. Simply pointing an existing rule set at a higher volume of higher-novelty payments makes that ratio worse, and the operational consequence is not just cost. It is alert fatigue, which is a detection failure dressed up as a staffing problem. When analysts are clearing a queue rather than investigating it, the genuine cases are dismissed at the same rate as everything else.
The realistic path out is not a better rule. It is narrowing what reaches a human at all: resolving low-risk alerts automatically with contextual data, consolidating related alerts into a single case, and feeding confirmed outcomes back into the scoring model so that the same pattern does not generate the same noise next month. Very few institutions have a working feedback loop from confirmed fraud back into detection logic, and it is usually the single highest-return fix available.
A realistic sequence for the next twelve months
- Measure your true decision window: Not the scheme’s stated limit, but the actual elapsed time between payment initiation and irrecoverable settlement on each rail you operate. This number defines everything else.
- Separate identity risk from behavioural risk: Move sanctions and watchlist resolution out of the payment path and into continuous customer screening wherever your regime permits it.
- Audit your inbound monitoring: If reimbursement liability is shared in your market, receiving accounts are now a direct cost centre. Most institutions have materially weaker controls here than on outbound.
- Rebaseline your rules against post-migration data: Thresholds calibrated on batch-era volumes are almost certainly mistuned. Backtest before you assume they still hold.
- Fix the feedback loop: Confirmed fraud outcomes should update detection logic on a defined cycle, with the improvement measured.
- Staff for continuous operation: Twenty-four hour rails need either genuine round-the-clock coverage or automated intervention capable of holding a position until a human is available.
The uncomfortable conclusion
Real-time payments are a genuine public good. They have brought settlement finality to people who previously waited days for their own money, and in several markets they have done more for financial inclusion than a decade of policy initiatives. None of that is in question.
What is in question is whether the control environment moved with them. For most institutions it did not, because the migration was driven by scheme deadlines and competitive pressure rather than by risk appetite. The result is a widespread and largely unacknowledged gap between the speed at which money now moves and the speed at which institutions can decide whether it should.
That gap will close, either deliberately through investment or involuntarily through losses and supervisory attention. The institutions that treat it as an architecture problem now will pay considerably less than those that continue to treat it as a tuning exercise.
