Confirmation of Payee: Name-Checking vs APP Fraud

For most of banking's history, a UK payment was routed purely on numbers — a sort code and account number — while the payee name you typed was never actually checked. If you fat-fingered a digit or a fraudster tricked you into paying the wrong account, the name meant nothing. Confirmation of Payee (CoP) was introduced to close that gap. It checks whether the name you enter matches the name on the destination account before the payment leaves, turning a previously ignored field into a genuine line of defense against misdirected and fraudulent payments.

The problem CoP addresses

The specific threat is authorized push payment (APP) fraud: scams where the victim is manipulated into willingly sending money to an account the fraudster controls. Because the customer authorizes the payment themselves, traditional fraud controls built around unauthorized transactions offer little protection. Common variants include:

• Invoice and mandate scams, where a genuine invoice is intercepted and the payment details swapped.
• Impersonation scams, where a fraudster poses as a bank, a supplier, or a government body.
• Purchase scams, where goods paid for never arrive.

In each case the payer believes they are paying the right person. A name check at the point of payment gives them a concrete signal — "this account does not belong to who you think" — at exactly the moment it can change their decision.

How the name check works

When a payer enters a payee's name, sort code, and account number, their bank sends a real-time request to the receiving bank asking whether that name matches the account holder. The receiving bank compares the submitted name against its records and returns a result. Rather than a blunt yes/no, the responses are graded:

• Match — the name matches the account. The payer can proceed with confidence.
• Close match — the name is nearly right (for example, a shortened first name or minor spelling difference). The payer is shown the actual account name and asked to check.
• No match — the name does not correspond to the account. This is a strong warning sign, and the payer is prompted to reconsider before sending.
• Unavailable — a check could not be completed, for instance if the account type is not supported or the service is temporarily down.

Account type matters too: a check on a personal account differs from one on a business account, and the payer typically indicates which they intend to pay. The graded responses reflect a deliberate balance — catch genuine mismatches without generating so many false alarms that people learn to click through the warnings.

Where CoP fits in the payment flow

CoP runs in the setup and pre-send phase, most importantly when a payer adds a new payee or makes a first payment to one. It sits ahead of the actual clearing, which is why it applies naturally to Faster Payments and CHAPS journeys where the payer is entering fresh beneficiary details. The check is about verifying who you are paying; the rail then handles moving the money. Because CoP happens before submission, it can prevent a mistaken or fraudulent payment from ever being sent — which is far more effective than trying to recover funds afterward on an irrevocable rail.

Confirmation of Payee turns a field everyone used to ignore into the last human checkpoint before the money moves.

Strengths and limits

CoP has meaningfully reduced certain kinds of misdirected payments and has taken away a fraudster's ability to rely on a payee name simply not being checked. But it is not a silver bullet, and builders should be clear-eyed about its limits:

• It does not judge intent. A "match" only confirms the name fits the account — not that the account is honest. A victim coerced into paying a fraudster's correctly named account still gets a match.
• Social engineering adapts. Fraudsters coach victims to expect and dismiss warnings, or steer them toward accounts where the name will match.
• Coverage and edge cases. Not every account type or scenario is straightforwardly checkable, producing "unavailable" results that carry no signal.

The right way to think about CoP is as one important layer in a defense-in-depth approach, alongside real-time transaction monitoring, fraud scoring, customer warnings, and reimbursement rules that share the cost of fraud between sending and receiving institutions.

What builders should do

If you are building UK payment journeys, a few principles apply:

• Wire CoP into new-payee flows and treat close/no-match results as friction worth adding, not obstacles to smooth away.
• Design the warnings to be heard. Clear, specific messaging beats a generic dialog people reflexively dismiss.
• Combine it with monitoring. Pair name-checking with behavioral fraud detection so you catch cases where the name matches but the pattern is suspicious.
• Handle every response type. Account for match, close match, no match, and unavailable explicitly in your UX and logic.

Platforms that combine rail access with real-time fraud and AML screening — KibiPay among them — can run name-checking alongside transaction monitoring so the two reinforce each other rather than operating in isolation.

Takeaway

Confirmation of Payee checks the payee's name against the destination account before a payment is sent, giving payers a graded signal — match, close match, no match, or unavailable — at the decisive moment. It is a strong, practical defense against misdirected payments and many APP fraud tactics, but it verifies identity, not honesty. Treat it as one essential layer in a broader, defense-in-depth fraud strategy rather than a complete solution.