Confirmation of Payee is the UK check that tells a payer whether the name they have typed matches the account they are about to pay. It sits between "enter the payment details" and "send the payment", and it exists because sort code and account number alone say nothing about who actually holds the account. A single digit typed wrongly can move money to a stranger. Confirmation of Payee, usually shortened to CoP, is the industry's answer to that problem.

For anyone building payment flows, CoP is not a nice-to-have feature bolted onto a payment button. It is a scheme-level check with defined message formats, defined response codes, and defined obligations on who has to run it and when. Understanding the mechanism properly avoids a lot of the integration mistakes teams make when they treat it as a simple yes/no lookup.

What the check actually does

When a payer enters a name, sort code and account number, the paying institution sends a CoP request to the payee's bank, via the Confirmation of Payee API infrastructure that connects participating institutions. The receiving bank checks the submitted name against the name it holds on the account, and returns one of a small number of standard responses:

  • Match — the name given matches the account holder's name closely enough to proceed.
  • Close match — the name is similar but not identical (a shortened first name, a missing middle initial, a company trading name instead of the registered name). The receiving bank returns the actual account name so the payer can check it manually.
  • No match — the name does not correspond to the account holder at all.
  • Unable to check — the receiving institution does not support CoP, the account type is out of scope, or the service is temporarily unavailable.

The important detail here is that CoP never confirms an account "is fraudulent" or "is safe". It only confirms whether a name matches. A no-match result should stop or delay a payment. A close match should be shown to the payer as a warning, not silently accepted or silently blocked. Systems that collapse these four outcomes into a binary pass/fail lose most of the value of the check.

Why it was mandated, and what "in scope" means

CoP was introduced following direction from the Payment Systems Regulator, initially targeting the largest UK payment service providers, with participation extended over time to a wider set of institutions handling Faster Payments and CHAPS transactions. The driver was Authorised Push Payment fraud: cases where a payer is tricked into sending money to an account that isn't who they think it is, and the payment is completed correctly from a technical standpoint but wrong from an intent standpoint. Traditional fraud controls, built around unauthorised transactions, didn't touch this category at all.

Scope matters in practice. CoP applies to accounts identified by a UK sort code and account number, reachable via Faster Payments or CHAPS. It does not extend to cross-border payments SWIFT rails, and it isn't part of SEPA's rulebook either. A platform that processes both UK domestic transfers and cross-border payments needs to be clear with users about which payments get a name check and which don't, rather than implying a blanket guarantee.

Where CoP sits in a payment flow

The check normally happens at the point a new payee is added or edited, not on every single payment to an already-verified payee. That keeps the user experience sensible: nobody wants a name check delaying a payment to a beneficiary they've paid a hundred times before. The typical sequence looks like this:

  1. User enters payee name, sort code and account number.
  2. The payment platform sends a CoP request through its banking or payments provider.
  3. The receiving bank returns match, close match, no match, or unable to check.
  4. The interface shows the result and, for anything other than a clean match, asks the user to confirm or amend before the payee is saved.
  5. The payment proceeds using the payee record, which is now flagged with its match status for audit purposes.

That match status matters later. If a dispute arises, being able to show that a payment was made to a name-verified payee, with a timestamped match response, is a meaningful part of a firm's evidence trail. It also matters for consumer duty and complaint-handling obligations, where firms need to demonstrate they took reasonable steps to prevent misdirected payments.

Where it matters most: marketplaces, payouts, and client money

CoP has an obvious use case for retail bill payments, but it's just as relevant for platforms moving money on behalf of others. Marketplace payouts to sellers, freelancers or drivers involve payee details entered by a third party, sometimes copied from an invoice, sometimes typed from memory. A no-match or close-match result at onboarding catches a wrong digit before the first payout goes astray, rather than after.

The same logic applies to client money accounts and to any GBP collection accounts used to receive funds on behalf of end customers. Getting the beneficiary details right before money moves matters more when the money isn't the platform's own. Fintechs that operate under a BaaS provider's API banking platform typically get CoP checking as part of the payment initiation service, rather than having to build a direct scheme connection themselves, since direct connectivity requires the underlying payment scheme membership that only regulated institutions and their infrastructure partners hold.

Common integration mistakes

A few patterns come up repeatedly when platforms bolt CoP onto an existing payment flow:

  • Treating "unable to check" as a failure. It isn't a match result at all — it means the check couldn't be performed, often because the receiving bank doesn't participate. Blocking payments outright on this response frustrates users unnecessarily; the sensible approach is to let the payment proceed with a clear notice that the name wasn't verified.
  • Auto-accepting close matches. A close match exists precisely because the systems can't be certain. Surfacing the actual held name and asking the user to confirm is the point of the feature — skipping that step defeats it.
  • Running the check too late. Checking the name after the payment has already been submitted, rather than at payee creation, removes the chance to stop the transaction before it's committed.
  • Not storing the result. Match status is evidence. Discarding it after the check removes the audit trail that matters most when something does go wrong.
  • Assuming coverage beyond UK domestic rails. CoP doesn't extend to EUR IBAN issuance or SEPA transfers, so a multi-currency platform needs separate thinking for its non-GBP flows.

Confirmation of Payee is a narrow, specific check: it confirms a name against an account, nothing more. Built into a payment flow properly, with all four response types handled distinctly and logged, it closes a genuine gap that sort code and account number alone left wide open. Built in carelessly, it becomes a box-ticking exercise that neither protects users nor produces useful records when disputes arise.