Most explanations of Confirmation of Payee stop at the point where the API returns an answer. In practice, that answer is where the real product decisions begin. The check itself is straightforward: a payer submits a sort code, account number and account name, and the receiving bank's system tells you whether the name matches its records. What happens next, inside your platform, is where design, liability and user experience actually collide.
The three responses, and why they are not equally simple
Confirmation of Payee returns one of three outcomes, and only one of them is unambiguous.
- Match – the name supplied corresponds to the name held on the account. The payer can proceed with confidence.
- Close match – the name is similar but not identical. The responding bank typically returns the correct name it holds, without disclosing further account detail, and the payer decides whether to proceed, correct the input, or abandon the payment.
- No match – the name does not correspond to the account, or the account does not exist. This is often the result that generates the most support queries, because payers assume it means the account is closed or fraudulent, when it may simply mean a typo or a legal name mismatch.
A fourth outcome sits alongside these three: the receiving institution may not participate in Confirmation of Payee at all, or the account type may sit outside the scheme's scope. In that case the API returns an "unable to check" response, and the payer is left to make a judgement call with no name verification at all.
Business accounts complicate the picture
Personal accounts generally hold a single registered name, so a close match is usually a spelling variation or an old name. Business accounts are messier. A company might trade under a name that differs from its registered legal name, hold an account under a director's name for historic reasons, or use a name that includes punctuation your input form strips out before sending the request. Product teams that treat close match as a minor formatting issue, and code accordingly, tend to generate a high volume of unnecessary payment abandonment from legitimate business payers. The fix is not to loosen the matching logic, since that sits with the responding bank, but to give users enough context in the interface to recognise a legitimate variation.
What the regulatory backdrop actually requires
Confirmation of Payee was introduced as a fraud-prevention measure for Faster Payments and CHAPS, targeting authorised push payment fraud, where a payer is tricked into sending money to the wrong account entirely. Since the Payment Systems Regulator's reimbursement rules took effect, the consequences of ignoring a no-match or close-match warning have sharpened. If a payer is warned that a name does not match and proceeds anyway, and the payment turns out to be fraudulent, that warning becomes relevant to how liability for reimbursement is assessed between sending and receiving institutions. This does not mean every mismatch is fraud, and it is not a substitute for proper fraud controls. It does mean that how your platform records, displays and logs the payer's response to a warning is no longer a cosmetic detail. It is part of the audit trail.
Designing the payment journey around each response
A workable pattern looks like this:
- Match – proceed without friction. Do not add extra confirmation steps the scheme has already handled for you.
- Close match – show the payer the name the bank actually holds, and require an explicit action to either update their entry or confirm they wish to proceed regardless. Log that decision with a timestamp.
- No match – require a clear, unambiguous warning and a deliberate confirmation step before allowing the payment to continue. Avoid pre-ticked boxes or soft language that understates the risk.
- Unable to check – tell the payer plainly that verification was not possible, rather than implying a check has passed silently. Silence is often read as reassurance, which is the opposite of what an unchecked payment deserves.
Marketplace and platform businesses that run frequent payouts to suppliers or sellers face a variant of this problem at scale. A one-off consumer payment can tolerate a manual confirmation step. A payout run processing thousands of transactions to onboarded sellers needs the mismatch logic built into onboarding itself, so that a name discrepancy is caught and resolved when a seller registers their bank details, not at the moment funds are due to move.
Where Confirmation of Payee stops working
The scheme only covers UK sort code and account number pairs sent through Faster Payments and CHAPS. It has no equivalent for EUR IBAN issuance or SEPA transfers, where a separate Verification of Payee mechanism applies under EU rules, and no reach at all into cross-border payments settled through SWIFT correspondent banking, where identity checks rely on manual screening and correspondent relationships rather than an automated name-match API. A platform operating across UK and EU rails, or handling GBP collection accounts alongside EUR balances, needs to treat these as genuinely separate risk controls rather than assume one covers the other. Building a single "payee verification" component that silently degrades outside UK domestic rails is a common source of false confidence.
Where this sits in the wider stack
Confirmation of Payee is one check within a broader set of controls that any platform moving client money needs to get right: proper segregation of client money accounts, accurate reconciliation, and clear ownership of liability when things go wrong. For platforms building payment flows on top of a BaaS provider's API banking platform, the practical question is less about whether Confirmation of Payee is available, and more about how much of the response-handling logic — the warnings, the logging, the escalation paths — is left for the product team to build themselves. Providers that hold direct payment scheme membership, such as London Rails, are typically better placed to surface these response codes accurately, but the interface decisions around them remain the platform's responsibility.
Getting the mechanism right is necessary but not sufficient. The output of a Confirmation of Payee check is only as useful as the decision your product makes with it, and that decision now carries real regulatory weight.