Authorized Push Payment Fraud and the Real-Time Rail Liability Problem

One common card-fraud pattern is an unauthorized transaction made with stolen credentials. Card-network disputes can also cover other scheme-defined reasons, such as processing errors or goods not received, as Visa's chargeback explanation illustrates. An APP scam poses a different challenge because the payer authorizes the transfer after deception.

Authorized push payment fraud is different in a way that makes it structurally harder to address. The victim sends the money themselves — they open their banking app, enter the account details, and approve the transfer. The payment is authorized. The rail processes the instruction, although separate reimbursement rules may apply. By the time the victim realizes they were deceived, funds may have been forwarded from the destination account, making recovery harder.

This is why real-time payment rails have created a new liability problem. Irrevocability — the property that makes instant payments valuable — is the same property that makes APP fraud recoveries so difficult.

How APP Fraud Works

The attack is social engineering that ends in a payment instruction. The mechanics vary by scam type, but the structure is consistent: establish false context, create urgency, direct the victim to send funds to a controlled account.

Impersonation fraud: the fraudster poses as the victim's bank, HMRC, a government agency, or law enforcement. They claim the victim's account is compromised and must be "secured" by moving funds to a "safe account." The safe account belongs to the fraudster.

Invoice fraud: a fraudster intercepts or spoofs a legitimate vendor's communications and redirects a pending payment. The victim thinks they are paying their supplier; they are paying the fraudster. Most common in B2B contexts — construction, legal, property.

Investment scams: a fraudulent investment platform shows convincing gains on a small initial deposit. The victim increases investment over weeks or months. Withdrawal requests are met with fees, taxes, or technical delays until the platform disappears.

Purchase scams: goods or services advertised (often on social platforms or classifieds) that never arrive. The payment is push rather than card.

Romance scams: long-term relationship built online, financial emergency manufactured, funds transferred.

What these have in common: the victim authorizes a payment after deception. A control designed only to spot stolen credentials or unauthorized account use can miss that pattern. Payment behavior and payee signals may still reveal risk before funds leave.

Why Real-Time Rails Amplify the Problem

Faster Payments is one of the UK rails covered by the mandatory APP reimbursement framework. A fast transfer can reach the destination account quickly, leaving a short window to intervene. Fraudsters may forward funds through mule accounts before the victim contacts their bank.

Card transactions can have scheme chargeback rights under their rules. Credit transfers follow different recall and reimbursement processes; a rapid transfer may leave little time to recover funds after they reach a mule account.

SEPA Instant Credit Transfer, PIX, UPI, PayNow, and Australia's New Payments Platform all share this characteristic. As real-time rail adoption grows globally, the APP fraud surface area grows with it.

The UK's Reimbursement Framework

The UK Payment Systems Regulator's mandatory APP reimbursement scheme came into force on 7 October 2024. It remains in force under the PSR today. Regulator in transition. HM Treasury confirmed on 21 April 2026 that the PSR will be abolished and its functions consolidated into the FCA, and the enabling Bill was introduced to Parliament on 19 May 2026. This has not happened yet — it requires primary legislation that is not enacted, the PSR continues to exercise its functions in the meantime, and Treasury has said transitional provisions will carry existing PSR requirements, directions and guidance across to the FCA. Treat PSR obligations as live; expect the named regulator to change, not the obligation. Specifically, Treasury has confirmed the mandatory APP reimbursement requirements are among those to be transferred.

Key parameters:

• Coverage: eligible individuals, microenterprises and charities making in-scope UK Faster Payments or CHAPS transfers
• Maximum reimbursement: £85,000 per claim
• Liability split: 50% sending PSP, 50% receiving PSP
• Exceptions and conditions: fraudulent consumer conduct and gross negligence can exclude a claim under defined rules; the gross-negligence exception and any permitted claim excess do not apply to vulnerable consumers. The claim maximum and time limits also matter.
• Cooling-off provision: PSPs may delay payments by up to 4 business days where there are reasonable grounds to suspect APP fraud, without incurring liability for the delay

A note on trends: UK Finance data shows APP fraud cases and total losses actually declined in 2024 compared to 2023, before H1 2025 losses rose year-on-year. The framing that APP fraud is universally accelerating requires market and time-period specificity — the UK trajectory is not linear.

The Receiving PSP Problem

The 50/50 cost-sharing rule gives both sending and receiving PSPs a direct stake in eligible claims. Earlier arrangements varied by firm and case; the current rule specifies the receiving PSP's contribution.

The 50/50 split changes the incentive structure. Receiving PSPs, including challenger banks and neobanks that have grown partly through frictionless onboarding, now have a direct financial stake in detecting mule accounts on their platform.

Mule account signals: accounts that receive a large inbound transfer and immediately forward most of it elsewhere; accounts opened very recently; accounts with onboarding patterns inconsistent with stated purpose; accounts linked to device or IP patterns associated with known fraud rings.

This is where account takeover detection tooling and merchant risk monitoring intersect — the same behavioral ML stack that detects compromised consumer accounts can identify newly created mule accounts before they are used.

Pre-Payment Controls

Confirmation of Payee (CoP): one pre-payment control. Before a payment is sent, the sending bank checks whether the account name entered by the payer matches the name on the account at the receiving bank. A name mismatch generates a warning, not necessarily a block. A matching name alone does not establish that a payment is safe.

CoP has been mandatory for the UK's largest banks since 2020. The EU Instant Payments Regulation requires a Verification of Payee service for euro credit transfers on staged dates; that checks the supplied account identifier against the intended payee's name. A match is a useful signal, not proof that the intended recipient is trustworthy. The European Central Bank explains the staged VoP requirements.

Behavioral analytics: anomaly signals in the payment session — first time paying this payee, payment amount significantly above typical for this customer, session patterns suggesting external instruction (copying account numbers from a chat window, browser switching), late-night timing. These signals can trigger additional friction (confirmation screen, delay, call-back) without blocking the payment outright.

Friction calibration: the challenge for payment operators is calibrating friction to risk without degrading experience for the majority of legitimate payments. The PSR cooling-off provision provides legal cover for delays on high-risk transactions — but applying it to every large payment would destroy the user experience that makes instant payment rails valuable.

Implications for Global Operators

The PSD3 framework in the EU has provisions on fraud liability but does not mandate reimbursement in the same way as the UK PSR. Operators expanding into EU markets should track whether mandatory reimbursement provisions emerge in national implementations.

For operators building real-time payment products in any market — whether on SEPA Instant, PIX, UPI, or PayNow — the APP fraud risk profile should be assessed at product design stage, not retrofitted post-launch. The questions are:

• What pre-payment name-matching capability is available on this rail?
• What is the irrevocability window — is there any grace period for recall?
• What mule account detection capability does the receiving bank ecosystem support?
• What is the regulatory liability framework if a customer is defrauded?

The irrevocability that makes real-time payment rails valuable to legitimate users is the same property that makes them the preferred channel for social engineering fraud. Building payment products on these rails without a coherent APP fraud control framework is building on a known structural risk.