Confirmation of Payee API for Payouts: Common Integration Mistakes

Confirmation of Payee was built with a simple case in mind: one person paying another person, checking a name against a sort code and account number before the money moves. Marketplace and platform payouts look nothing like that case. A platform might pay out to thousands of sellers, drivers or freelancers a day, many of them limited companies, sole traders, or joint account holders whose registered name does not read the way a person types it. Bolting a Confirmation of Payee API onto a payout engine built for that scale exposes assumptions that do not hold, and the failures usually show up as either blocked payouts that were actually fine, or missed checks on payouts that should have been stopped.

This article sets out where those failures tend to come from and how to design around them.

What the check is actually matching against

When a Confirmation of Payee API call goes out, it is matched against the account name held by the receiving bank, using the sort code and account number as the lookup key. The response is not a simple yes or no. It comes back as one of a small set of outcomes: a full match, a close match with a suggested correction, no match, or an indication that the account cannot be checked at all, which happens with some non-personal accounts, some client money accounts, and accounts at institutions that have not yet built full support for the scheme.

Platforms that treat every non-"match" response as a hard stop end up blocking legitimate payouts. A sole trader might hold an account under their personal name while trading under a business name. A company might have an account name that includes "LTD" where the platform's records show "Limited". None of these are fraud signals. They are formatting mismatches, and the close-match response exists precisely to flag them for a human decision or a corrected resubmission, not an automatic rejection.

Mistake one: checking only at onboarding

Many platforms run a Confirmation of Payee check once, when a payee first adds their bank details, and then treat that detail as verified indefinitely. Bank details change. Accounts close. Someone updates their payout details through a support ticket that never triggers a re-check. Running the check only at the point of first entry misses all of these, and it is the update path, not the initial one, where mismatched payouts most often originate.

A more resilient pattern re-checks payee details whenever they change, and periodically for payees who receive regular payouts, rather than relying on a single check performed once and never revisited.

Mistake two: no path for legitimate non-matches

Close matches and non-matches are common with business accounts, not exceptions. A payout platform needs a defined process for what happens next: does the payment get held for manual review, does the payee get prompted to re-enter details, is there a threshold below which a mismatch is tolerated and above which it is not. Without that process built in advance, mismatches get resolved ad hoc by whoever is on shift, which produces inconsistent outcomes and, over time, a backlog of stuck payouts that erodes trust in the payout system generally.

Mistake three: applying personal-account logic to business payouts

Sort code and account number checks behave differently depending on account type. Personal accounts generally support full name matching. Business and organisation accounts sometimes only support partial matching against the registered account name, and some scheme participants restrict what data they return for non-personal accounts entirely. A platform paying out primarily to businesses needs to design its matching logic and its fallback rules around that reality rather than around the cleaner personal-account case, which is the one most integration guides use as their default example.

Mistake four: treating the check as a fraud control on its own

Confirmation of Payee reduces misdirected payments and a specific category of authorised push payment fraud, where someone is tricked into paying the wrong account. It is not a general fraud screen, and it does not verify that the person submitting payout details is authorised to receive the money on the recipient's behalf. Platforms that rely on a name match as their sole control against payout fraud are missing the layer that actually matters for their risk: identity verification of the payee and, for marketplace payouts specifically, confirmation that the receiving account belongs to the seller or partner the platform has a contractual relationship with, not merely that the name looks right.

Mistake five: not planning for accounts the check cannot reach

Not every account in the UK payments system currently supports Confirmation of Payee matching. Some client money accounts, some accounts at smaller institutions, and some overseas accounts reached through correspondent banking or cross-border payments via SWIFT sit outside the scheme's reach entirely. A payout system built with an assumption that every payee can be checked will fail unpredictably when it meets one of these accounts. The correct handling is a defined fallback: flag the payout for manual verification, apply an alternative check, or route it through a different rail, rather than letting the integration error out or silently skip the check.

Why this matters more for platforms than for single transactions

A consumer sending one payment can tolerate a moment's friction if a name doesn't match. A platform processing thousands of payouts needs the check embedded in a workflow that handles mismatches, retries, exceptions and non-checkable accounts without manual intervention on every case. That is a design problem as much as an integration problem, and it sits alongside the other pieces of fintech banking infrastructure a platform needs for payouts: GBP collection accounts to receive incoming funds, a clear account structure separating operating funds from money held on behalf of others, and payment scheme membership or a sponsoring arrangement that gives the platform the routing rights the payout actually needs.

Firms building this from scratch typically look to an API banking platform or a BaaS provider that has already solved the exception-handling layer around Confirmation of Payee, rather than treating the check as a single endpoint to call and forget.

The practical takeaway

A Confirmation of Payee API returns more than a match or a fail. It returns information that needs a decision behind it, and a payout platform that has not built that decision layer will either block payments it shouldn't or wave through ones it should have queried. Getting the mechanism right matters less than getting the exception handling right, because the exceptions are where most of the real payout volume actually lives.