What is Authorised Push Payment (APP) fraud?
APP fraud happens when a customer is tricked into instructing their bank to transfer money to a fraudster’s account. Because the customer themselves authorises the payment, it is legally considered authorised, even though the instruction was induced by deception. This is different from pull payment fraud, where the fraudster initiates the transaction without the customer’s consent.
This distinction between push and pull fraud is crucial in law and continues to shape how disputes are argued.
Who is liable for Authorised Push Payment fraud?
Under common law, a payment that is not authorised by the customer is void, and the bank cannot debit the account. This principle was confirmed in Tai Hing Cotton Mill v Liu Chong Hing Bank Limited (1986), which emphasised that the bank must follow the customer’s instructions exactly.
However, if the customer themselves assisted the fraud by providing instructions or information that enabled it for example, the bank can treat the payment as authorised. This principle comes from London Joint Stock Bank v Macmillan (1918), which established that if a customer facilitates a fraud in any way the bank may treat the payment as authorised and is not liable to reverse it
Finally, even if a customer makes a payment under a mistake or is misled, as long as the payment was authorised, the bank can rely on it. This was confirmed in Bank of Scotland v Brunswick Developments (1987) Ltd (No 2) (1999).
In short, whether a payment is considered authorised or unauthorised depends not on the customer’s intentions alone, but on the legal rules around authorisation and facilitation.
Why the legal approach to APP fraud Is under pressure
Even with modern technology, the banking system has stayed largely unchanged, while fraudsters have quickly found ways to take advantage of fast payments, trust, and human error. This gap has led regulators to step in more often and encouraged claimants to challenge traditional legal rules.
As a result, courts are now being asked with greater frequency to assess bank conduct against modern expectations of fraud prevention, rather than the assumptions that underpinned earlier authorities.
Regulatory developments and APP fraud reimbursement schemes
The main regulatory response has been the Contingent Reimbursement Model (CRM), created after a super-complaint by Which? and developed by the Payment Systems Regulator. The original CRM Code, introduced in May 2019, was voluntary and only covered some banks.
Because of this limited coverage, a mandatory reimbursement scheme was later introduced by the PSR and the Bank of England under section 72 of the Financial Services and Markets Act 2003, applying to Faster Payments and CHAPS. However, the scheme does not cover international payments, payments through other systems, payments for unlawful purposes, or payments involved in disputes between parties. Importantly, reimbursement does not automatically prevent legal claims. In disputes, regulatory compensation is part of the facts to consider rather than a full answer to liability.
The Quincecare duty and APP fraud claims
The Quincecare duty is a key issue in APP fraud cases. It requires a bank to stop a payment if there are clear warning signs that the transaction might be fraudulent. In practice, this is a high standard and only applies in cases of gross negligence.
The modern reference point is Singularis Holdings Ltd v Daiwa Capital Markets Europe Ltd [2017], where the court found liability because the bank ignored obvious red flags, though contributory negligence reduced the claim. For claimants, Quincecare is a way to challenge authorised payments. For banks, it is a risky, fact-specific, and hindsight-driven defence. Whether courts will allow Quincecare to apply more broadly in APP fraud cases is still uncertain.
If you would like any further information or advice, contact Downs Solicitors to see how we can help.
Contact Chris Millar
