A UK payments compliance officer receives their first quarterly APP fraud reimbursement bill under PSR Specific Direction 20. Their platform is the receiving PSP for 3 per cent of the in-scope fraud claims. The 50/50 cost split means they owe half of every reimbursement, even for fraud they did not initiate. The total for Q1: £180,000. Their current fraud detection system carries a 3.8 per cent false positive rate that is also blocking £900,000 in legitimate orders every quarter.

That is the double loss that defines the UK fraud problem in 2026: direct regulatory liability for fraud you receive, and a tool that creates its own revenue problem by treating good customers as risks.

The UK fraud compliance landscape in 2026 is uniquely demanding. Mandatory APP fraud reimbursement under PSR SD20 creates direct PSP liability that does not exist in most other markets. The FCA's Consumer Duty requires proactive fraud prevention as a conduct obligation, not just a risk mitigation measure. UK card-not-present fraud rates remain among the highest in Europe. No other market combines all three pressures simultaneously.

This blog gives UK CFOs and Risk Officers the framework to evaluate ML fraud prevention tools against the specific UK compliance context: APP fraud liability under SD20, CNP chargeback defence, and the false positive cost that makes a poorly calibrated fraud solution a double loss.

Understanding the UK fraud regulatory environment in 2026 requires looking at four distinct pressures operating in parallel.

Authorised Push Payment fraud reimbursement applies to all Faster Payment Service and CHAPS transactions. The reimbursement cap is £85,000 per claim. The cost is split 50/50 between the sending PSP and the receiving PSP. This structural feature of SD20 is what makes the UK framework unlike any other: UK platform operators are now directly financially liable for fraud they receive, not only fraud they send. A receiving PSP with no mule account detection capability is accumulating fraud liability on every transaction that arrives.

Fraud tools that err aggressively on the side of caution create their own compliance exposure. Blocking a legitimate UK customer from completing a £200 transaction means losing that sale to a competitor. At scale, a 3.8 per cent false positive rate is not a risk metric: it is a revenue drain. Under the FCA's Consumer Duty, patterns of unnecessary friction for legitimate customers are a conduct risk. CFOs evaluating fraud vendors need to assess both the cost of fraud that passes through and the cost of legitimate orders that do not.

CoP adoption is expected across UK FPS participants. Sending PSPs without CoP face higher APP fraud exposure because payee verification is absent, as well as increasing regulatory scrutiny. Confirmation of Payee is a baseline safeguard, not a fraud solution in itself: it confirms account name matching but does not detect the social engineering that drives most APP fraud. CoP works alongside ML fraud detection rather than replacing it.

The PSR is conducting a post-implementation review of the APP fraud reimbursement regime in Q4 2026. The outcome may tighten requirements or expand scope. UK PSPs building fraud infrastructure that merely meets current requirements are building to a target that may move. The correct posture is infrastructure that exceeds current requirements and can adapt to tightened obligations without a full rebuild.

APP fraud occurs when a customer is deceived into authorising a legitimate payment to a fraudster's account. The customer acts willingly: the transaction is technically authorised. This is what makes APP fraud resistant to traditional rule-based fraud tools, which are built to detect transactions the customer did not initiate.

The sending PSP's liability under SD20 depends on whether they took reasonable steps to detect and prevent the fraud before it was sent. ML models that evaluate transaction context simultaneously, including new payee combined with high transaction value, unusual timing, device mismatch, and session behaviour inconsistency, can flag high-risk transactions for confirmation friction before the payment leaves the platform.

The delayed payments legislation, live since 2025, gives sending PSPs the ability to delay high-risk transactions by up to 72 hours for further investigation. ML fraud scoring is what makes this power usable in practice: without precise risk classification, the high-risk designation either catches too little to be meaningful or delays enough legitimate payments to breach Consumer Duty obligations.

Under SD20, receiving PSPs bear 50 per cent of the APP fraud reimbursement cost. The fraud mitigation strategy for receiving PSPs is account behaviour analytics: detecting mule account patterns before fraudulent funds arrive and settle.

The signals are distinct from CNP fraud patterns. Mule accounts typically display:

No single signal is definitive: it is the combination and timing that ML models are designed to weigh. Systems that continuously analyse account behaviour across the full payee base flag these patterns at a portfolio level, before individual transactions generate reimbursement liability. This is fundamentally different from transaction-level fraud scoring and requires a different evaluation framework from CFOs assessing vendors.

UK card-not-present fraud rates remain among the highest in Europe, driven by high ecommerce penetration and card usage relative to alternative payment methods. Every UK enterprise processing online card payments faces this baseline exposure.

ML-based CNP fraud prevention evaluates device fingerprints, session behaviour, BIN risk scores, and velocity patterns simultaneously. High-risk transactions are flagged for 3DS step-up before authorisation, not after a chargeback. The distinction matters: post-authorisation fraud recovery is expensive, reputationally damaging, and operationally demanding. Pre-authorisation intervention is the only efficient point of control.

The 3DS 2.0 frictionless flow depends entirely on the quality of ML scoring. Frictionless authentication is only safe when ML correctly identifies low-risk transactions. Systems with high false negative rates on CNP fraud will impose 3DS friction across a far wider share of their customer base than necessary, creating revenue drag on the legitimate orders that make up the overwhelming majority of transaction volume.

These five questions test whether a fraud vendor's product is designed for the UK regulatory environment or retrofitted to it.

A vendor that leads with chargeback rates and transaction-level scores is answering the wrong question. APP fraud prevention requires a separate capability set. If a vendor cannot describe their mule account detection model specifically, they do not have one.

A false positive rate without context is a meaningless metric. Ask for it segmented by transaction value band, card type, and merchant category. A 1 per cent false positive rate on low-value transactions and a 1 per cent false positive rate on high-value enterprise orders represent completely different revenue exposure.

FPS is an instant payment rail. A fraud scoring system that requires 200ms to return a decision is architecturally incompatible with FPS. This single question disqualifies a significant portion of the vendor market without requiring a technical deep-dive.

When a PSP challenges a reimbursement claim, the burden is evidential. Can the vendor's system produce a timestamped fraud score, the risk signals that drove it, and the customer interaction record at the point the high-risk transaction was flagged? If not, the PSP has no defence documentation.

CoP is a mandatory baseline. A vendor who treats it as optional or separate from their fraud stack is not building for the UK market.

The UK fraud compliance environment in 2026 imposes liability that has no direct equivalent in other major markets. APP fraud reimbursement under SD20 makes receiving PSPs financially accountable for fraud they did not initiate. Consumer Duty makes false positive rates a conduct issue, not just a revenue issue. CNP fraud exposure remains structurally high. Managing all three with a single fraud tool requires ML-based infrastructure that is designed for the UK regulatory context from the ground up, not adapted from a generic international product.

ONERWAY's built-in fraud intelligence is built for this environment: APP fraud behavioural scoring, mule account detection, and CNP fraud prevention aligned to the PSR's reimbursement regime, all delivered through the same unified API that handles payments, payouts, and embedded finance. One integration, one compliance posture, one infrastructure partner with FCA-licensed credentials and a UK-based risk team.

If you want to assess your current APP fraud exposure or false positive rate, our UK risk team can run a compliance gap assessment. Get in touch.

ML fraud detection reduces APP fraud reimbursement liability in two distinct ways depending on the PSP's role. For sending PSPs, behavioural ML models flag high-risk transactions before authorisation, generating the documented "reasonable steps" defence that SD20 requires for partial liability exemption. For receiving PSPs, ML-based account behaviour analytics detect mule account patterns before fraudulent funds settle, reducing the volume of claims to which the 50/50 cost split applies.

APP fraud involves a customer who is deceived into authorising a payment: the transaction is technically legitimate but the destination is fraudulent. CNP fraud involves an unauthorised transaction using stolen card credentials: the cardholder did not initiate the payment at all. Both require ML detection, but they use different signal sets. APP fraud detection focuses on payee risk, transaction context, and behavioural anomalies in the customer's payment patterns. CNP fraud detection focuses on device signals, session behaviour, and card-level velocity.

Mule account detection at the receiving PSP requires account-level behavioural analytics rather than transaction-level scoring. The key signals include multiple high-value inbound transfers from diverse senders, rapid fund movement out of the account after receipt, account opening followed immediately by high-value inbound transactions, and a significant mismatch between account profile and observed transaction behaviour. ML models that monitor the full payee portfolio continuously are better positioned to detect these patterns than rule-based systems, which require known signal combinations to trigger.

Confirmation of Payee is a bank account name-checking service that verifies whether the account name entered by a payer matches the name held by the receiving institution. It provides a partial safeguard against misdirected payments and some categories of APP fraud where the fraudster has provided false account details. It does not prevent social engineering fraud where the account name check passes because the fraudster has taken over a legitimate account. CoP is a regulatory baseline requirement, not a replacement for ML fraud detection.

The 50/50 split between sending and receiving PSPs under SD20 requires fraud prevention strategies at both ends of the transaction. Sending PSPs reduces their liability by implementing pre-payment behavioural scoring, delayed payment capabilities, and documented intervention frameworks that demonstrate reasonable steps were taken. Receiving PSPs reduce their liability through mule account detection and account behaviour analytics that prevent fraudulent funds from settling. ML-based systems that serve both roles from a single integrated platform give UK PSPs the most efficient path to managing their combined SD20 exposure.