KibiPay
HomeBlog › Payment Rails

Confirmation of Payee and Account Name Checking

6 min read Payment Rails
Confirmation of PayeeFraud preventionBank transfers
Confirmation of Payee and Account Name Checking

For decades, sending a bank transfer meant trusting that the sort code and account number you typed belonged to who you thought. The name field was cosmetic — banks routed on the numbers and ignored the name entirely. That gap was a gift to fraudsters, who could trick victims into paying a legitimate-looking name while the money flowed to an account they controlled. Confirmation of Payee (CoP) closes the gap by checking the account name before the payment is sent.

The problem CoP solves

The dominant threat is authorised push payment fraud, where a victim is manipulated into authorising a transfer themselves. A common variant is invoice or mandate fraud: a fraudster intercepts an invoice, changes the bank details, and the victim pays the criminal believing they are paying a supplier. Because the payment is authorised by the genuine account holder, traditional fraud controls do not catch it. CoP attacks the moment of trust — by confirming, before sending, whether the account really belongs to the intended payee.

How the name-check works

When a payer sets up a new payee, their bank sends a real-time query to the receiving bank asking, in effect, "does this account number, at this sort code, belong to a person or business with this name?" The receiving bank compares the supplied name against the name on the account and returns a result in seconds. Importantly, the receiving bank does not reveal the actual account name when it does not match — that would leak data — it only reports the degree of match. In the UK, the service is built on an Open Banking API framework and coordinated by Pay.UK, and it applies to Faster Payments and CHAPS transfers.

The four responses

CoP does not simply say yes or no. It returns a graded result so the payer can make an informed decision:

A crucial design point is that CoP is advisory, not blocking. The payer can still choose to send after a no-match, but they do so having been warned, which changes the liability picture if fraud later occurs.

Account type matters

The check must know what kind of account it is looking at, because names are structured differently. A personal account is matched against an individual's name; a business account is matched against a registered or trading name. If the payer picks the wrong type — entering a company as an individual — the check can fail even when the details are correct. Good payment interfaces ask the payer to choose personal or business up front to reduce false no-matches.

Benefits and limits

CoP has measurably reduced misdirected payments and certain APP scams, and it deters fraudsters who rely on mismatched mule accounts. But it is not a silver bullet. It does not help when a victim is coerced into paying an account whose name genuinely matches the fraudster's story, such as a purchase scam where the criminal's own account name is used. It also depends on broad coverage: the protection only works if both the sending and receiving institutions participate, which is why regulators have progressively mandated adoption across more firms rather than leaving it voluntary.

Beyond the UK

The idea is spreading. The European Union has mandated a comparable verification of payee service for euro credit transfers, requiring payment service providers to offer a name-and-account check before instant and standard transfers. The names differ by jurisdiction, but the principle is converging: on push rails with no chargeback, verifying the payee before sending is one of the few points where fraud can be stopped in time.

Key takeaways

See these rails in motion

KibiPay connects UK Faster Payments, Bacs, CHAPS, Mojaloop mobile money and Solana behind one API, with ISO 20022 messaging and real-time fraud & AML screening.

Open the live console How it works