Any platform paying beneficiaries in both the UK and the eurozone will eventually run into two separate payee-verification regimes that look similar on the surface but work on different mechanics. Verification of Payee (VoP) under SEPA and Confirmation of Payee (CoP) in the UK both aim to catch misdirected payments before money moves. Neither is built the same way, and treating them as interchangeable in a payout system is a common source of integration bugs.

What both checks are trying to do

Both schemes exist to reduce a specific failure mode: a payment sent to a correct account number but the wrong person, whether through fraud, a typo, or stale beneficiary data. Before the transfer executes, the sending side asks the receiving side to confirm whether the account name matches the name the sender has on file. The response typically falls into a small set of categories: a full match, a close match with a suggested correction, no match, or an inability to verify (the account does not exist, or the receiving institution does not participate).

Where the two schemes diverge is in what identifier they check against, who is required to support them, and how that check is threaded into the underlying payment rail.

SEPA's Verification of Payee

VoP under SEPA is anchored in EU-level regulation covering both SEPA Credit Transfer and SEPA Instant Credit Transfer. The obligation to offer and perform the check sits with payment service providers operating in the euro area, with a later compliance deadline for PSPs in EU member states outside the euro area. This is not an opt-in industry scheme in the way some payment features are; it is a regulatory requirement tied to the instant payments framework, which means coverage across SEPA is expected to be broad rather than patchy.

Mechanically, the check runs against the IBAN. Because SEPA is a single instrument covering more than thirty countries, a VoP check on a EUR IBAN works the same way whether the receiving bank sits in Ireland, the Netherlands, or Slovakia. One identifier, one verification path, applied consistently across the scheme's geography. For a platform managing EUR IBAN issuance for marketplace sellers or suppliers, this means the verification logic doesn't need to branch by country.

The UK's Confirmation of Payee

CoP was built earlier and differently. It runs on Pay.UK's infrastructure and covers Faster Payments and CHAPS. Rather than a single pan-scheme legal mandate, participation was driven by direction from the Payment Systems Regulator requiring the largest UK banks and building societies to support CoP, with adoption spreading more widely across the industry from there. The direction and its scope have been the main lever, rather than an EU-style regulation applying uniformly to every PSP.

The identifier is also structurally different. UK domestic payments route on a sort code and account number pair rather than a single account number, so a CoP check has two fields to match against the account name instead of one. This is a small technical detail with a real consequence: any system that treats "the number to check" as a single string across both schemes will need to hold two data shapes, not one, and validate them differently.

Why the mechanical difference matters for platform builds

A platform holding both EUR IBAN issuance and GBP collection accounts under a BaaS provider is effectively running two verification integrations behind what looks like one feature to the end user. The response taxonomies aren't identical between VoP and CoP, the identifier formats differ, and the timing expectations differ too, since VoP is explicitly tied to instant SEPA transfers where speed matters as much as accuracy.

A few integration points are worth planning for explicitly:

  • Separate identifier validation logic. IBAN structure and sort code/account number structure need distinct parsing and formatting rules before either check is even called.
  • A normalised internal response state. Rather than passing raw scheme responses through to downstream logic, map both VoP and CoP outcomes into a small internal set (verified, partial match, no match, unverifiable) so the rest of the payout flow doesn't need to know which scheme produced the result.
  • Different points of verification. Marketplace payouts often verify a payee once at onboarding and re-verify periodically, rather than on every transaction. Whether that's appropriate depends on how often beneficiary details change and how the platform's risk policy treats stale verification.
  • Clear handling for "no match" and "unverifiable." Neither outcome should silently pass through to payment execution. Decide in advance whether the flow holds the payout, prompts the payer to confirm, or routes to manual review, and log the outcome for audit regardless of what the platform decides to do next.

Where cross-border SWIFT payments sit

It's worth noting that neither VoP nor CoP covers cross-border payments SWIFT transfers outside SEPA and outside UK domestic rails. There is no equivalent scheme-level name-check for a payment leaving the SEPA zone or the UK Faster Payments network via SWIFT. Any name-matching for those payments happens through the sending institution's own screening and beneficiary data checks, not through a shared scheme response. Platforms that route some payouts through SWIFT alongside SEPA or Faster Payments need to be clear that this is a different risk profile, not an extension of the same verification guarantee.

Scheme membership and who actually performs the check

Payment scheme membership shapes who is technically responsible for running these checks. A PSP with direct access to SEPA or Faster Payments performs verification against the scheme directly. A platform working through an aggregator or a BaaS provider's API banking platform typically relies on that provider to have built the connection to both VoP and CoP, exposing a single API call that returns a normalised result. Either way, the underlying obligation sits with whichever entity holds the scheme membership, and it's worth understanding where that sits in a given payment stack before assuming a "verified" response means the same thing in every context.

For product teams designing payout flows that span both currencies, the practical takeaway is to treat VoP and CoP as related but non-interchangeable checks, each with its own data shape, mandate, and failure modes, and to build the internal logic that sits above them rather than assuming one pattern fits both.