API access alone doesn’t make an organisation eligible for UK Confirmation of Payee. Organisations navigating Confirmation of Payee (CoP) API requirements in the UK must be FCA or NCA regulated, authorised to perform payment service activities, and account-holding payment service providers whose customers have accounts reachable by sort code and account number. An organisation without its own sort code may still be eligible if its accounts are addressable through Secondary Reference Data (SRD).
Eligibility is only the starting point. You also need to understand what a match, partial match or no match tells a payer, and how each response shapes the payment journey. This article explains who can apply to join CoP, how name matching works for personal and business accounts, and what to consider when integrating the API, including the difference between UK CoP and Verification of Payee. The aim is to clarify whether your organisation may participate and what the results mean in practice.
Key Takeaways
Assess eligibility by focusing on your organisation’s regulatory status, payment services authorisation and account reachability, including whether accounts use sort codes and account numbers or Secondary Reference Data.- Understand what a match, partial match or no match communicates before deciding how to present the result in your payment journey.
- Separate UK Confirmation of Payee requirements from Verification of Payee rules when designing services that operate across different payment regions.
- Plan API integration around how account-name checks fit into payment initiation, customer experience and the handling of different response outcomes.
- Written by Alexander Legoshin, this guide helps you connect eligibility and matching requirements to the wider decisions involved in building embedded financial services.
Table of Contents
- Who is eligible to apply to join Confirmation of Payee?
- What happens when a Confirmation of Payee check returns a partial match?
- Differences between CoP and Verification of Payee
- CoP API integration and implementation features
- How Confirmation of Payee name matching works
- Gemba: Fast time to market embedded banking
Who is eligible to apply to join Confirmation of Payee?
Eligibility depends on your role in the payment chain, not simply on whether you can connect to an API. To join UK Confirmation of Payee, an organisation must be FCA or NCA regulated, authorised to perform payment service activities, and an account-holding payment service provider. Its personal or business customers must have accounts reachable by sort code and account number. These criteria distinguish an account provider participating in CoP from a business that only sends payment instructions.
Some account providers without their own sort code may qualify through an alternative route: their accounts must be addressable using Secondary Reference Data (SRD). In either case, an eligible provider can participate directly by building its own CoP solution or using a technical service provider. Start by mapping your account model, customer types and role in payments against the eligibility criteria.
CoP compares the intended payee’s name with the name associated with the account before payment. This can help prevent misdirected payments and reduce authorised push payment (APP) fraud, in which a payer is deceived into authorising a transfer. A partial or failed match gives the payer information to consider, but does not guarantee that a payment is safe. CoP is one input into a wider payment decision, not a substitute for customer judgement.
CoP checks are mandatory for Faster Payments, CHAPS and new standing orders in the UK. For organisations handling Faster Payments or CHAPS, coverage matters on both sides of a transaction: CoP can support checks before an outbound payment and help validate details associated with an incoming payment. A business offering payment initiation services should distinguish initiating a payment from holding the recipient’s account. Eligibility centres on account-holding payment service providers, so an initiator should assess its role in the arrangement rather than assume API access alone qualifies it.
Before an outbound payment, display the CoP result clearly and let the payer acknowledge it in the payment journey. For example, if the name submitted for a business beneficiary differs from the account name, show the result before the customer confirms the transfer. This gives the payer a meaningful chance to pause, correct details or proceed with awareness of the outcome.
For consent and data protection, explain that the name and account details are used for a CoP check, and handle personal data under applicable UK GDPR and data-protection controls. Use only information relevant to the check and make its purpose clear in the payment flow. Access and per-check fees depend on the commercial arrangement and participation route, including whether the organisation builds in-house or uses a technical service provider; fees are not uniform across all integrations.
What happens when a Confirmation of Payee check returns a partial match?
A partial match means the name entered is similar to, but not identical to, the account holder’s name. To interpret the result, distinguish what CoP compares from what it does not establish.
Account Name Checks
A CoP check compares the payee name with the account name held by the recipient’s payment service provider, using the account details supplied for the payment. UK checks can apply before Faster Payments, CHAPS and new standing orders, as described above. The response helps a payer spot a potential discrepancy before sending funds, rather than discovering an error after the transaction.
For example, a payer enters a supplier’s name and account number, but the name is abbreviated. A partial match indicates similarity, not exact identity. The payer can compare the displayed information with the intended recipient’s details and correct a typo or outdated entry where appropriate. The result creates a meaningful decision point before the payer authorises payment.
Payee Name and Business Details
CoP checks support personal and business accounts, comparing the submitted name with the name associated with the account. For a business payee, the relevant comparison is with the business account name; for a personal payee, it is with the personal account holder’s name. This matters when a trading name, shortened name or individual contact differs from the account’s registered name.
CoP is not a general review of a company’s activities or proof that a business is genuine. It returns a result about the relationship between the entered name and the account details. A payer should not treat a partial match as confirmation of a company’s wider identity, and should resolve inconsistencies using information they already have about the recipient.
The response generally falls into three categories: match, partial match or no match. A match means the supplied name aligns with the account holder’s name. A partial match means the names are similar but differ. A no-match result means the supplied name does not match the account details. Each result describes the name comparison, not the commercial purpose of the payment.
Payment systems can use these outcomes to make the payment journey clearer. Show the result before the payer confirms the transaction, using plain language to explain whether the entered name matched. If the result is partial or no match, let the payer review the payee name and account number. Do not obscure the discrepancy or present it as a successful match.
Consistency also matters when users select saved beneficiaries or make repeat payments. A supplier’s account may be saved under a familiar trading name, while the bank records a different account-holder name. If the check returns a partial match, explain that the names differ and let the payer decide whether to amend the details or continue. Clearly distinguishing match types supports informed action without overstating what CoP verifies.
Differences between CoP and Verification of Payee
UK Confirmation of Payee (CoP) and European Verification of Payee (VoP) both compare payment details with an account name. They belong to distinct frameworks, so a solution designed for one market should not assume the other’s rules or reach.
In the UK, the Payment Systems Regulator mandates CoP as a payee account-name checking service provided by payment service providers. CoP checks whether the name entered by a payer matches the name held for the recipient’s account. Its result supports a decision before payment; it is not a broad verification of the payee’s identity or business.
CoP can also be used in some direct debit set-ups. Existing CoP customers can use it as a supplementary service to check account names before setting up or amending Bacs Direct Debit payments. Payer Name Verification supports these checks during set-up, helping the payer compare the name associated with an account against the intended payer details. This differs from checking a payee before a credit transfer.
For European institutions, the scope is tied to SEPA Credit Transfer and SEPA Instant schemes. Payment service providers operating in eurozone member states are due to implement Verification of Payee by October 2025 under the EU Instant Payments Regulation, according to the European Union. The European Payments Council’s VoP Scheme Rulebook is identified by reference EPC218-23, providing a scheme framework separate from UK CoP.
UK CoP is a UK account-name checking service, while European VoP follows its own SEPA scheme framework. US payment systems and verification services operate in a different market context, so UK CoP participation does not provide access to a US verification network. For cross-border products, identify which country’s payment system handles each transaction.
The distinction matters when a business serves customers across regions. A UK payment may use CoP, while a euro-area transfer may require a separate VoP capability. The name-checking purpose is similar, but the applicable scheme, participating institutions and payment route determine the relevant solution. Map these separately instead of presenting one verification result as universal across borders.
For product design, label each check by the payment route and scheme that produced it. Keep UK CoP outcomes distinct from VoP outcomes, and explain which account name was compared. For example, do not display a UK payee check as a European VoP result simply because both return information about name matches. Clear scheme identification preserves the meaning of each response.
These differences also shape operational planning: eligibility, scheme participation and transaction coverage are not interchangeable. A business building payment flows across the UK, eurozone and United States should establish where each payment is initiated and which verification framework applies. This makes the user experience more precise and prevents a local name-checking result from being overstated as global verification.
CoP API integration and implementation features
Implementing CoP means more than connecting an API to a banking screen. For teams navigating Confirmation of Payee (CoP) API requirements in the UK, the design must place checks within inbound and outbound payment journeys and make results clear before a push payment proceeds.
API Implementation Considerations
API implementation is the work of connecting payment flows to CoP requests and responses. It matters because a check must relate to the correct bank account and transaction. Map where payee details enter your system, when the check runs, and how each outcome reaches the payer. CoP can return more than 14 technical reason-code responses, so operational handling should distinguish outcomes rather than flatten them into one status.
For an outbound payment, connect the check to the point before confirmation, then display its result in the payer journey. For an inbound payment, determine where your system receives and processes the check. Test both paths with representative personal and business account scenarios. Keep each response associated with the payment request that generated it, especially when users amend saved beneficiary details.
UK Implementation Timeline
The UK implementation timeline developed through separate directions and phases, rather than one deadline for every organisation. The six largest banking groups were required to join for inbound and outbound transactions before June 30th 2020. Later deadlines applied to additional payment service providers, making it important to distinguish an organisation’s group and payment role.
UK Group 1 PSPs named in Direction 17 had to implement CoP by 31 October 2023. UK Group 2 PSPs covered by the direction had to implement it by 31 October 2024. From October 2024, all UK payment service providers handling Faster Payments and CHAPS were required to comply with CoP standards. Those dates describe staged implementation, not a suggested API delivery schedule for a new integration.
Regulatory Requirements and Audit Records
The Payment Systems Regulator directs CoP implementation for covered payment service providers and payment flows. Requirements include checking payee account names under the applicable direction, with coverage involving Faster Payments and CHAPS. Identify which direction and group apply to your role, then align inbound and outbound journeys with the relevant scope. A practical approach to navigating Confirmation of Payee (CoP) API requirements in the UK also considers how each result is recorded.
For a usable audit trail, retain the payment reference, check timestamp, submitted name and account details, returned outcome, and the payer’s subsequent action. Link each record to the relevant transaction so teams can reconstruct whether a result appeared before payment confirmation. These are practical evidence fields, not a universal statutory retention period; apply your organisation’s recordkeeping and data-protection controls.
Alexander Legoshin’s guide highlights a practical implementation principle: make every CoP result traceable to a payment, a decision and the correct flow. That structure helps teams investigate a disputed payment or diagnose an integration issue without confusing an inbound check with an outbound one.
How Confirmation of Payee name matching works
CoP compares the name submitted for a payment with the account holder’s name in the provider’s records. The result describes that comparison, helping a payer consider possible misdirected payments before authorising a transfer.
Name-Matching Outcomes
A CoP response distinguishes among match, partial match and no match. A match means the submitted name aligns with the account holder’s name; a partial match means it is similar but not identical; and no match means the name does not match the account details.
An unavailable response is different: it does not establish that the name matches or fails to match. Keep this state distinct from the three name-comparison outcomes in the payment journey. For example, if a check cannot return a comparison, don’t display it as a no match or imply that the account holder’s name was verified.
Matching Names to Bank Details
For a CoP check, the payer supplies payee details, including the account name and bank details, so the recipient’s payment service provider can compare the name with its account records. The CoP API supports checks for personal and business accounts. The response concerns the supplied name and account, not the wider identity or trustworthiness of a person or business.
This distinction matters when a legitimate recipient uses a trading name, abbreviation or spelling that differs from the account name. A partial match can signal a difference without identifying its cause. Before deciding whether to proceed, the payer can review the entered details and compare them with information already held for the intended recipient.
In practice, present the result before the payment is authorised. A match indicates alignment, not that the payment’s purpose is legitimate. A no match is a clear discrepancy to consider; a partial match deserves attention because similar names can still refer to different account holders. None of these outcomes independently proves that a recipient is honest or that a transaction is safe.
The payment journey should preserve these distinctions. Show the specific CoP outcome alongside the payee details and give the payer a clear opportunity to review them. If the payer corrects an account name or changes bank details, the displayed result should correspond to the details currently being used, not an earlier version of the payment.
Participation structure also affects how results travel between providers. In the UK aggregator model, the aggregator is a Direct Participant, while the payment service providers it serves are Indirect Participants. This clarifies which participants exchange CoP requests and responses; it does not change what a match or partial match means to the payer.
For payment services connecting UK flows with Europe, identify CoP results as UK checks rather than presenting them as universal verification. The practical takeaway is precise: treat each response as evidence about a name-to-account comparison, explain its limits and preserve the payer’s ability to make an informed decision. This section was written by Alexander Legoshin.
Gemba: Fast time to market embedded banking
Gemba helps businesses building branded financial services bring embedded banking to market through Banking API Integration and a White-label Banking Interface. If your CoP planning is part of a broader payment product, these capabilities can support the infrastructure around your service. Eligibility and CoP participation remain separate considerations.
For organisations managing business payment flows, Ultra fast bulk payments and Global payroll are relevant offerings to consider alongside a wider build. The right next step depends on the services you plan to deliver and how they fit your operating model. This article was written by Alexander Legoshin.
To explore whether Gemba fits your plans, visit ge.mba.
Turn your CoP plans into a considered next step
Use your CoP design to clarify what your payment experience must enable for customers and operations. As you continue navigating UK requirements for the Confirmation of Payee (CoP) API, consider how checks fit your wider service proposition, customer journey and technology decisions. A clear view of these priorities can help you assess the role of embedded financial services in your business.
If you’re shaping a broader payment proposition, Gemba can be part of the conversation. Discuss how your plans and operating model align with the infrastructure you need. This article was written by Alexander Legoshin.
Discuss your CoP API plans with Gemba and take a considered next step toward building a payment experience that serves your business and its customers.
Frequently Asked Questions
Can CoP be used for cross-border payments?
CoP isn’t a universal check for every leg of a cross-border transfer. In your payment design, treat currency conversion, payment routing and recipient-name checking as separate operations: an FX conversion doesn’t extend a CoP check to an overseas beneficiary. For a transfer involving a UK account, place any applicable check within that UK payment flow, and don’t present its result as validation of every international detail.
Can Confirmation of Payee be used across multiple banking providers?
Yes, checks can involve different participating providers, but reachability depends on whether the account provider can be identified within the CoP ecosystem. Design for payment journeys where a result cannot be obtained, rather than treating every request as a completed name check. Keep that state distinct from a name mismatch and explain clearly what the payer can do next.
Can I use CoP for business accounts?
Yes. A business can use CoP for its account, and the check can support supplier-payment controls. For example, an accounts-payable team can compare the outcome with its vendor onboarding record before approving a new beneficiary. Establish a consistent internal process for recording supplier payment details and reviewing changes, so staff can distinguish a genuine update from an unexpected alteration.
Do I need to connect directly to the CoP scheme to use Confirmation of Payee?
No. An eligible provider can use a technical service provider instead of building its own solution. This is an architectural decision: compare how each route fits your existing payment systems, operational responsibilities and customer journey. In either model, keep CoP results associated with the relevant payment request, rather than separating them from the action they inform.
How does CoP work?
CoP provides a name-check result within a payment flow, so the payer can consider it before proceeding. For a saved beneficiary, show the result when the user makes a payment, not only when the beneficiary is first created. This keeps the check relevant to the current transaction and the details being used.
What does the future look like for CoP?
Payment businesses should build systems that accommodate scheme-specific checks without treating one scheme as universal. For example, a business operating across the UK and Europe can keep payment routes and verification responses distinct in its product architecture. This makes it easier to adapt customer journeys as relevant schemes and participation arrangements develop, without suggesting there is one shared framework.
What general impact does Confirmation of Payee have?
CoP can shape internal payment controls as well as the payer’s screen. A finance team can define who reviews a warning, how an amended beneficiary record is approved, and what happens when a payer chooses not to proceed. Clear ownership helps organisations use the check consistently across departments, rather than leaving each employee to interpret a result differently.
What is Confirmation of Payee (CoP) in the UK and how does it work?
Confirmation of Payee is a UK service for checking payment account names through participating payment service providers. Its role is narrower than general identity verification: it gives the payment journey information about the name associated with an account. For organisations, the key product decision is where that information appears and how users can act on it before completing a payment.
Frequently Asked Questions
Can CoP be used for cross-border payments?
CoP isn’t a universal check for every leg of a cross-border transfer. In your payment design, treat currency conversion, payment routing and recipient-name checking as separate operations: an FX conversion doesn’t extend a CoP check to an overseas beneficiary. For a transfer involving a UK account, place any applicable check within that UK payment flow, and don’t present its result as validation of every international detail.
Can Confirmation of Payee be used across multiple banking providers?
Yes, checks can involve different participating providers, but reachability depends on whether the account provider can be identified within the CoP ecosystem. Design for payment journeys where a result cannot be obtained, rather than treating every request as a completed name check. Keep that state distinct from a name mismatch and explain clearly what the payer can do next.
Can I use CoP for business accounts?
Yes. A business can use CoP for its account, and the check can support supplier-payment controls. For example, an accounts-payable team can compare the outcome with its vendor onboarding record before approving a new beneficiary. Establish a consistent internal process for recording supplier payment details and reviewing changes, so staff can distinguish a genuine update from an unexpected alteration.
Do I need to connect directly to the CoP scheme to use Confirmation of Payee?
No. An eligible provider can use a technical service provider instead of building its own solution. This is an architectural decision: compare how each route fits your existing payment systems, operational responsibilities and customer journey. In either model, keep CoP results associated with the relevant payment request, rather than separating them from the action they inform.
How does CoP work?
CoP provides a name-check result within a payment flow, so the payer can consider it before proceeding. For a saved beneficiary, show the result when the user makes a payment, not only when the beneficiary is first created. This keeps the check relevant to the current transaction and the details being used.
What does the future look like for CoP?
Payment businesses should build systems that accommodate scheme-specific checks without treating one scheme as universal. For example, a business operating across the UK and Europe can keep payment routes and verification responses distinct in its product architecture. This makes it easier to adapt customer journeys as relevant schemes and participation arrangements develop, without suggesting there is one shared framework.
What general impact does Confirmation of Payee have?
CoP can shape internal payment controls as well as the payer’s screen. A finance team can define who reviews a warning, how an amended beneficiary record is approved, and what happens when a payer chooses not to proceed. Clear ownership helps organisations use the check consistently across departments, rather than leaving each employee to interpret a result differently.
What is Confirmation of Payee (CoP) in the UK and how does it work?
Confirmation of Payee is a UK service for checking payment account names through participating payment service providers. Its role is narrower than general identity verification: it gives the payment journey information about the name associated with an account. For organisations, the key product decision is where that information appears and how users can act on it before completing a payment.
