Fraud & Controls / Learning brief
Confirmation of Payee and APP fraud
Your notes
In simple terms / 01
What this means in plain language
In authorised push payment fraud the victim sends the money themselves, deceived into paying a criminal's account. Confirmation of Payee checks the name on an account before the payment is authorised, so a mismatch shows before the money moves. Here is what the check does, and what it does not.
Authorised push payment fraud (APP fraud) is fraud in which the victim is deceived into authorising a payment from their own account to an account controlled by a criminal. Because the victim initiates and approves the payment, it passes the usual authentication checks: the bank sees a genuine, authorised instruction. The deception sits before the payment, an impersonated supplier, employer, or authority persuading the payer that the destination is legitimate, which is why controls aimed at unauthorised access do not stop it. Confirmation of Payee (CoP) attacks the deception instead. It is a name-verification service that compares the payee name the payer enters against the name actually held on the destination account, and shows the payer the result before they authorise. The outcome is a match, a close match, no match, or that the check could not be done. CoP informs the payer, but it warns rather than blocks: a payer can override a no-match and send anyway. It catches mismatches and honest typos, but it does not judge whether a payee is honest, so it is one control among several rather than a complete answer.
Key takeaways / 03
Three things to remember
- 01
In APP fraud the victim authorises the payment themselves, so it passes authentication; the deception comes before the payment.
- 02
Confirmation of Payee checks the payee name against the destination account before authorisation and shows the payer the result.
- 03
CoP warns rather than blocks, catching mismatches and typos but not judging whether a payee is honest.
Practical use cases / 04
Where you would use this
A bank runs a name check before authorising a push payment and shows the payer a match, close match, no match, or unavailable result.
A fraud team analyses no-match overrides to spot payers who may have been deceived into paying a criminal's account.
A payer pauses on a no-match and verifies new bank details through a trusted channel before sending a large invoice payment.
Worked example / 05
Put the idea into a real situation
Illustrative example: (SYNTHETIC / TRAINING ONLY) Maya Chen is buying from Example Supplies Ltd and receives an email, appearing to be from them, saying their bank details have changed. The email is from a criminal. Maya goes to pay GBP 4,500.00 to the new account, entering the payee name Example Supplies Ltd. Her bank asks the receiving bank whether the name matches the account and returns no match, because the account is not held in that name. Maya sees the warning before authorising and can stop and verify through a trusted channel, or override and send anyway.
Evidence & review / 07
Evidence & review
Account-name verification before a push payment, illustrated by the UK Confirmation of Payee model. Match logic and coverage differ by scheme and country.
What this brief simplifies: Match categories are simplified to match, close match, no match, and unavailable. CLS, cheque, and Confirmation of Payee scheme-specific operational detail was not re-verified against primary operator docs this pass (environment egress limits).
Sources for this brief4
- Scheme-specific rule
Faster Payment System (FPS) ↗ — Pay.UK · Confirmation of Payee name-checking context
Interbank settlement in FPS is deferred net at the Bank of England — the customer experience is instant, but the banks settle net at defined cycles, not payment-by-payment. Not an RTGS system.
- Market practice
Launching the FATF's Roadmap 26-28 on Combatting Fraud ↗ — Financial Action Task Force · Authorised push payment fraud context
Launched 1 July 2026, the first day of the UK's two-year FATF Presidency. The roadmap itself is a plan of work (data-gathering through October 2026, recommendations by February 2027), not yet a new binding requirement.
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · Strong customer authentication and payer protection context
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Fictional impersonation scenario
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.