Confirmation of Payee checks the name on the account. It cannot check the name in your head.

Confirmation of Payee is one of the more effective things UK payments has done in a decade, and it stops a class of loss that used to be routine. It also cannot help with the scam that now dominates the numbers, because that scam works by making the payer say the wrong name confidently. This is what the check proves, what it cannot, and what a bank can actually control once reimbursement is mandatory.

A woman in Leeds is buying her first flat. On completion day she gets an email in the middle of a thread she has been reading for six weeks, from an address she recognises, referencing her solicitor by first name and her purchase by its file number. The bank details have changed, the message says, because of an internal account migration. It apologises for the inconvenience.

She logs into her banking app and sets up the payee. She types the name from the email. The app checks it against the name on the destination account, and returns a match. Green. She reads the scam warning, which asks whether she has verified the details with the recipient by phone. She has: she called the number in the email signature, and a polite person confirmed the change.

She sends 218,000 pounds. It is gone in ninety seconds, moved through three accounts, most of it out of reach within the hour.

Every control worked. The name check matched, because the mule account had been opened in a company name chosen to match the solicitor's firm. The warning displayed, because the bank displays warnings. The customer did verify by phone, using a number the fraudster supplied. And the bank will reimburse her, because under the rules now in force it usually has to, and then it will split the cost with the bank that received the money.

What does Confirmation of Payee actually check?

The service does one thing precisely. Before a payment is made, the sending bank asks the receiving bank whether the name the payer typed matches the name held on the destination account, and gets back one of a small set of answers: a match, a close match with the actual name offered so the payer can correct a typo or a middle initial, no match, or unavailable because the receiving institution cannot answer.

That is genuinely useful and it was not easy to build. It required agreement across the industry on how to ask the question, how to answer it, how to handle account types where the registered name and the trading name differ, and how to do all of that without turning the service into a way to harvest account names. The scheme rules that govern it exist because every one of those problems needed a decision.

What it fixed is worth stating clearly, because it is a real category of harm that has largely stopped being routine. Before the check, typing a digit wrong in a sort code or account number sent money to a stranger, and recovering it depended on that stranger's goodwill and their bank's patience. A generation of payments people have stories about this. The name check catches it before the money moves, which is the only point at which catching it is cheap.

It also catches a meaningful slice of impersonation. A fraudster who wants a payment intended for British Gas has to receive it into an account whose registered name will pass as British Gas, and opening such an account is harder than sending an email. Every additional constraint on the mule account is friction the fraudster has to buy.

Similar obligations have been introduced in the European Union, where payment service providers are required to offer verification of payee services for credit transfers, so the direction of travel is not confined to one market.

The one sentence version

Confirmation of Payee verifies the destination. It is a check on the answer to "where is this going", and it is good at it.

Why does the check pass when the payment is a scam?

Because authorised push payment fraud does not attack the destination. It attacks the payer.

The word doing the work in that phrase is authorised. In an unauthorised fraud, somebody else moves your money and the question is how they got access. In an authorised push payment scam, you move your own money, from your own device, through your own authentication, having formed a genuine intention to send it. The criminal's product is not access. It is a belief.

Once you see it that way, the limits of a name check become obvious rather than surprising. The check compares the name the payer typed with the name on the account. The scam's entire method is to make sure those two things agree. There are three routine ways to arrange that.

Match the story to the account. The mule account is opened, or bought, in a name that fits whatever the payer has been told. A payer who believes they are paying a builder called J. Fletcher Building Services will type that, and if the account is registered that way, the check returns a match. The payer now has a green tick reinforcing the belief the scammer planted, which is worse than no check at all in that specific interaction.

Coach the payer through the warning. Where the names do not match, the scammer has already explained why. The account is in the name of our parent company. It is a client account held by our accountants. My business name is different from my trading name. Payers who have been prepared for a warning treat it as confirmation that the scammer told them the truth. This is the most under-discussed property of any warning: a warning the victim has been told to expect is evidence for the fraudster's story.

Take over an account that is already trusted. Where the fraudster compromises a real business's email, as in the opening scene, the payment often goes to an account that legitimately relates to the transaction chain, or to one prepared specifically to match. The payer is not paying a stranger who has appeared from nowhere. They are paying the party they were always going to pay, at details they believe came from that party.

Say the consequence plainly, because most writing on this topic will not: for the scam types that dominate the losses, a name check can return a match, display a warning, and increase the payer's confidence, all while doing exactly what it was designed to do. That is not a failure of the control. It is a control being asked a question that belongs to a different problem.

What changed when reimbursement became mandatory?

Everything about how a bank should think about this, which is why the standards question suddenly has money attached to it.

Since 7 October 2024, the UK's Payment Systems Regulator has required payment firms to reimburse victims of authorised push payment scams on Faster Payments and CHAPS, subject to a maximum claim value, with the cost split evenly between the sending and receiving firms and a narrow exception where the customer acted with gross negligence. The regulator has published data on the first year and commissioned an independent review, which reported that in-scope losses fell and that substantial sums were reimbursed to victims. Those are published regulatory findings about a regime the regulator designed, which is worth keeping in mind when reading them, and they are the best numbers available.

Note what that does to the incentive structure. Before, a bank that displayed a warning and was ignored had a defensible position and often a cheaper outcome. Now the bank pays by default, the receiving bank pays half, and the only route to a different outcome runs through evidence about the customer's conduct and the firm's own compliance with the standard of caution.

So the question a fraud team faces stopped being only "can this be caught in time" and became "what can we prove about what happened". Those are different engineering problems, and the industry has spent almost all of its money on the first one.

What can a bank actually prove today?

Less than most people assume. In a dispute, the bank typically holds server-side records: the payee was set up at this time, the Confirmation of Payee response was a match, a warning of type 14b was rendered, the customer proceeded, the payment executed. Every one of those is a log the bank wrote about itself.

That is usually accepted, and it should be, because banks are not in the habit of forging their own audit trails. But it is not evidence in the strong sense. It cannot establish what pixels reached the customer's screen, whether the warning was displayed for long enough to be read, whether it was rendered at all on that app version, or whether the customer was on a call with somebody telling them what to tap. When a case turns on those questions, both sides are arguing about the plausibility of a record rather than examining an artifact.

We have a name for that condition: Evidence Without Provenance. It is the same failure that makes chargeback defence hard for merchants and makes e-signature audit trails weaker than they look, which we cover in the piece on e-signatures.

What is an intent receipt, and what does it change?

An intent receipt is a signature produced on the customer's own enrolled device, covering the payment and the warning as actually rendered, at the moment of confirmation.

The payload is unremarkable, which is the point:

{
  "action":     "payment.confirm",
  "payer":      "acct_7741",
  "payee_name": "J Fletcher Building Services",
  "payee_ref":  "sha256:c41a...",        // sort code + account, hashed
  "amount":     { "value": 21800000, "currency": "GBP" },
  "cop_result": "match",
  "warning_id": "app-scam-purchase-v4",
  "warning":    "sha256:7be9...",        // the exact text rendered
  "shown_ms":   6180,
  "iat":        "2026-09-29T10:14:22Z"
}

Three fields carry the weight. warning is a hash of the exact wording the customer saw, so a year later the bank recomputes it against the version in its content repository and the question of what was displayed becomes arithmetic. shown_ms records how long it was on screen before confirmation, which distinguishes a customer who read a warning from one who dismissed it in 300 milliseconds. cop_result binds the name-check outcome into the same signed object, so nobody can later argue about whether the match result the customer saw was the one the system recorded.

Verification needs nothing from the bank or from us:

assert verify_ed25519(receipt.signature,
                      receipt.payload_hash,
                      published_key)              # no callback

assert receipt.payload_hash == sha256(canonical(payload))
assert receipt.warning == sha256(content_repo["app-scam-purchase-v4"])
assert receipt.iat  < payment.executed_at

That last property is the one worth pausing on. The receipt verifies offline against a published key. An ombudsman, a court, the receiving bank, or the customer's own solicitor can check it without asking the bank for anything and without trusting us. It stops being the bank's word.

This cuts both ways, and it should

A control that only helps the firm holding it is not evidence, it is marketing. The reason to like this design is that it is symmetric.

It protects the customer against a firm that claims a warning was shown when the app build in question did not render one, or rendered it below the fold, or showed a generic warning where the scam type called for a specific one. Those disputes exist and today the customer has no way to contest the record. With a receipt, the absence of a signature covering a specific warning is itself informative.

And it protects the firm in the genuinely contested minority of cases, where a customer proceeded through an explicit, specific, well-timed warning and later cannot recall it. Human memory of a stressful financial event is not reliable, which is not an accusation, it is a well-established property of memory.

Where does the second signer come in?

The scam's operational requirement is isolation. Almost every high-value authorised push payment scam includes an instruction not to discuss the payment with anyone: not with the bank, not with family, sometimes explicitly not with the person the payer thinks they are paying. That instruction exists because the fraud does not survive a second opinion.

So the intervention that matches the mechanism is not more information delivered to an isolated person under pressure. It is a second person.

An opt-in rule where payments above a threshold, or to a first-time payee, require a co-signature from a designated trusted contact does exactly that, and it does it without a conservatorship, a joint account, or a power of attorney. The account holder chooses the contact, chooses the threshold, and can remove the rule unilaterally. The contact sees only the payment they are asked to co-sign, never the balance or the history.

There is precedent for the shape of this in financial services. Rules requiring firms to ask customers to name a trusted contact person, and permitting holds on disbursements where exploitation is suspected, already establish that a named third party has a legitimate role in protecting an account holder without controlling the account. The co-signature is the same idea with a cryptographic mechanism instead of a phone call. We develop that design in full in the second signer piece.

Which controls work against which scams?

The honest version of this table has a lot of no in it.

Read down the intent receipt column. It says evidence only in most rows, and that is the correct answer. The only row where a signature deterministically prevents the loss is the last one, where the payer never formed an intent at all and therefore cannot have signed. That row matters, and it is the subject of the payee-add piece, but it is not where the reimbursement bill comes from.

Honest limits

• A signature does not stop a deceived payer. If somebody genuinely intends to send the money, they will sign, and the signature will be valid. Social engineering is a persuasion problem. No authentication mechanism, however good, addresses persuasion, and any vendor telling you otherwise is selling you something. We say the same thing in the reimbursement piece and it is worth repeating.
• Better evidence can cut against the customer. A regime that makes it easier to demonstrate that a warning was clearly displayed and briskly dismissed could be used to widen the gross negligence exception. Whether that is fair depends on how it is applied, and firms adopting this should expect scrutiny of exactly that.
• Second signers are not universal. Many people have nobody suitable to name. Some who do would be endangered by naming them, because a significant share of financial abuse is committed by family members. The rule must be revocable by the account holder alone and must never become a default.
• It adds friction where friction is unpopular. First-time payee flows are already the highest-abandonment moment in retail payments. Any firm deploying this should measure abandonment as carefully as it measures fraud.
• Adoption is the real constraint. The evidentiary value depends on ombudsmen, courts and receiving banks accepting the artifact. That is a scheme and regulator conversation, not an engineering one. Manav has filed drafts on receipt formats and has no card scheme or payment scheme integration.

What to do this week

1. Pull your last hundred reimbursed cases and ask what you actually hold. For each, list the evidence in your possession and whether a third party could verify it without your systems. Most teams have not done this and find the answer uncomfortable.
2. Version your warning content properly. Every warning variant should have a stable identifier and a hash. Without that, no receipt scheme is possible and your current logs are weaker than you think.
3. Instrument display time. Record how long each warning was on screen before confirmation. This costs almost nothing and immediately tells you whether your warnings are being read.
4. Separate your metrics. Stop reporting misdirected payments and scam losses in one number. The name check moves the first and cannot move the second, and combining them hides which interventions work.
5. Model the second signer on real data. Take your first-time-payee population above your threshold and estimate coverage. If fewer than a third of the affected customers would plausibly name a contact, redesign before building.
6. Talk to the receiving side. Under a 50/50 split, receiving firms have a direct financial interest in mule account controls and in verifying evidence. This is a rare case where both banks want the same artifact.
7. Write down what you will not claim. Decide now, in advance of any pilot, that you will not describe an intent receipt as scam prevention. It is evidence and friction. Overclaiming here will cost you credibility with your own regulator.

Frequently asked questions

Does Confirmation of Payee stop authorised push payment fraud? It stops some of it. The check reliably catches payments misdirected by mistake and impersonation where the fraudster cannot obtain a matching account name. It cannot see intent or coercion, so where a scammer has prepared a mule account whose name fits the story, the check returns a match and reinforces the payer's mistaken belief.

What happens if Confirmation of Payee returns no match? The payer is warned and can proceed anyway, which is deliberate, because legitimate mismatches are common: trading names differ from registered names, client accounts are held by third parties, and joint accounts vary. Scammers exploit that flexibility by explaining the mismatch in advance, so a coached payer treats the warning as confirmation of the story.

What evidence can a bank use in an APP reimbursement dispute? Today, mostly server-side records: the name-check result, which warning was triggered, and that the customer proceeded. These are logs the firm wrote about itself. They cannot establish what was rendered on the customer's screen or for how long. A signature produced on the customer's device over the payment and the warning hash converts that into an artifact a third party can verify.

Can a family member co-approve my bank transfers? Not widely today, though the design is straightforward and has precedent in trusted contact person rules. An opt-in rule can require a designated person's co-signature for first-time payees or payments above a threshold, with the account holder able to remove it unilaterally and the contact seeing only the payment they co-sign, never the balance.

Would a signature have prevented the scam in the opening example? No, and it is important to say so. The buyer intended to send the money and would have signed. What changes is the record of what she was shown and confirmed, and, if a second-signer rule had been active for a first-time payee at that value, the scam would have had to survive a conversation with a second person, which is the thing it is designed to avoid.

Is verification of payee required outside the UK? Similar obligations have been introduced in the European Union, requiring payment service providers to offer verification of payee for credit transfers. The mechanics differ by market, and the structural limitation is the same everywhere: matching a name to an account tells you about the destination and nothing about why the payer chose it.

Sources

1. Payment Systems Regulator, authorised push payment scams and the reimbursement requirement. https://www.psr.org.uk/
2. Pay.UK, Confirmation of Payee. https://www.wearepay.uk/
3. Financial Conduct Authority, Consumer Duty. https://www.fca.org.uk/firms/consumer-duty
4. Financial Ombudsman Service, decisions on authorised push payment complaints. https://www.financial-ombudsman.org.uk/
5. European Commission, instant payments and verification of payee obligations. https://finance.ec.europa.eu/
6. FBI Internet Crime Complaint Center, annual Internet Crime Reports. https://www.ic3.gov/AnnualReport/Reports
7. FINRA, trusted contact person and financial exploitation rules. https://www.finra.org/

The name check tells you where the money is going. The scam was never about where the money was going.