How to Verify Supplier Bank Accounts in the UK: CoP, APP Fraud, and Beyond

The UK rewrote the rules of bank account verification on 7 October 2024. Mandatory APP fraud reimbursement now means sending and receiving PSPs split liability 50/50 when payments go to the wrong account — up to £85,000 per claim. Confirmation of Payee is the front-line defence, but it's not the whole answer. For UK finance teams paying UK suppliers, the operational question is no longer "should we verify bank details" — it's how, when, and with what beyond CoP.

UK bank account verification used to be optional good practice. As of October 2024, it's something closer to a financial necessity. The Payment Systems Regulator's mandatory reimbursement regime means that when a supplier payment goes to a fraudster's account, the sending PSP is generally on the hook to refund the consumer — and can only recover half from the receiving PSP if the receiving institution failed its own controls. The economic incentive across the entire UK payments stack now points in one direction: verify before paying.

For consumer-facing banks, this has accelerated the rollout of Confirmation of Payee (CoP) — UK Finance reports that over 300 organisations have implemented it, with more than 2 million checks completed every day. But CoP was designed primarily for one-off retail payments, not the operational realities of B2B accounts payable. For UK businesses paying suppliers — especially under bank-detail change requests, where the fraud risk concentrates — CoP catches some attacks and misses others.

This article explains what's actually required, what CoP does and doesn't do, and what UK finance teams should put around it to make supplier-payment verification both regulator-defensible and operationally complete. The framing is practical: not a regulatory primer, but the workflow a UK AP manager needs to run in 2026.

The UK regulatory snapshot: what changed in October 2024

Before the operational guidance, a brief refresh on the regulatory framework that's now in force. Three regulatory instruments — Specific Direction 19 (SD19), Specific Direction 20 (SD20), and Specific Requirement 1 (SR1) — together created the new APP fraud reimbursement regime.

Key facts that matter for any UK bank account verification workflow:

• Effective date. The new rules apply to reimbursable APP scam payments made on or after 7 October 2024.
• Reimbursement cap. Sending PSPs must reimburse victims up to £85,000 per claim. (The originally proposed cap was £415,000; the PSR reduced it in September 2024 after industry consultation.)
• 50/50 liability split. The cost of reimbursement is shared equally between the sending and receiving PSP. The receiving PSP must reimburse 50% of the refund amount to the sending PSP within 5 working days of being notified.
• Maximum excess. Sending PSPs can charge consumers an excess of up to £100 per claim — but this excess does not apply to vulnerable consumers.
• Refund timeline. Refunds must be provided within 5 working days; PSPs can "stop the clock" if more information is required, with a final decision within 35 working days.
• Claim reporting window. Consumers have 13 months after the last payment was authorised to make a claim.
• In-scope payments. All Faster Payments and retail CHAPS payments in pounds sterling. (Internal account transfers are out of scope.)
• In-scope customers. Consumers, microenterprises (≤10 employees, ≤€2M turnover), and charities (≤£1M annual income).
• Standard of caution exception. Reimbursement isn't required if the consumer acted with gross negligence, failed to engage with PSP intervention, didn't report the scam within 13 months, or didn't share required information. The exception doesn't apply to vulnerable consumers.

The 50/50 liability split is what changed the economic calculus across the entire UK payments stack. Before October 2024, banks could implement weak verification controls and rely on the sending PSP to absorb fraud losses. Under the new regime, the receiving PSP carries half the exposure — which means every bank in the UK now has a direct financial incentive to verify accounts properly, screen onboarding tightly, and respond to mule-account reports fast. The PSR's framing is that this "incentivises both ends of the payments chain" to prevent fraud.

For UK businesses paying UK suppliers, the practical implication is that the entire ecosystem is now optimising for verification. CoP coverage is expanding rapidly — the PSR mandated almost 400 more PSPs to become CoP-compliant in 2024 — and the operational expectation across the industry is that verification happens before money moves, not after fraud is reported.

What Confirmation of Payee actually does

Confirmation of Payee (CoP) is the UK's account-name-verification service. When you set up a new payment to a UK sort code and account number, CoP queries the receiving bank to confirm whether the name you've entered matches the account holder's name on file. It works on Faster Payments and on single CHAPS payments (when set up via online banking).

The technical mechanics: CoP is operated as an "overlay service" by Pay.UK, sitting on top of the existing payment infrastructure. The PSR mandated CoP for the largest banks in 2020, then expanded coverage in 2024 to nearly 400 more PSPs. UK Finance reports that over 300 organisations have implemented CoP and more than 2 million checks are completed every day.

A CoP check returns one of four possible outcomes:

• Match — the name you entered matches the name registered to the account. Safe to proceed.
• Close match — the name is similar but not exact (e.g., "Acme Limited" vs "Acme Ltd"). The actual registered name is returned to you so you can decide whether to proceed.
• No match — the name you entered does not match the account holder. The receiving bank will NOT share the actual name (to protect privacy). You should contact the supplier directly to verify.
• Unable to check — the receiving bank or account type doesn't support CoP, or the account is configured in a way that prevents the check. Proceed with caution.

Crucially, CoP doesn't block the payment. It returns information; the decision to proceed is yours. A "No Match" or "Close Match" response is a warning, not a hard stop. That design choice was deliberate — CoP is a fraud-prevention overlay, not a payment authorisation system — but it has operational implications for AP teams writing internal policy around CoP responses.

The personal vs business account flag

One detail UK businesses often miss: when you enter payment details, you also need to select whether the account is personal or business. The receiving bank uses this to decide which CoP check response to return. Entering the wrong account type can produce a "No Match" even when the name is correct. For B2B payments, always confirm with the supplier whether their account is personal (sole trader using personal banking) or business (registered business account) before running the check.

The trading-name problem

Many UK businesses operate under a trading name different from their legal name. "Smith & Sons Plumbing" might trade as "Smith Plumbing" but bank under "Smith & Sons Plumbing Limited." CoP checks against the registered account name — meaning a supplier asked to send you payment using "Smith Plumbing" will get a Close Match response, with the registered name returned. If your AP team isn't trained to expect this, they may treat legitimate Close Matches as fraud signals and slow legitimate payments.

Where CoP falls short for UK B2B payments

CoP is the right first line of defence — but it's not the whole defence. Three specific gaps matter for UK businesses paying suppliers.

1. The "Match" doesn't tell you who actually owns the company

CoP confirms that the bank account belongs to whoever the supplier registered the account under. It doesn't tell you whether that supplier is a legitimate business or a shell company set up to receive fraudulent payments. A fraudster who registers "Acme Cloud Services Ltd" at Companies House, opens a business bank account in that name, and submits an invoice will pass CoP cleanly — the account is registered correctly to the entity that exists. The fraud is in the entity itself, not the account.

Shell-company fraud is a real and growing attack vector. Companies House registration is cheap, fast, and minimally verified; combining a clean CoP response with shell-company KYB checks is what closes that gap. See KYB verification for marketplaces for how entity verification complements account verification.

2. CoP only works for UK sterling payments

If your supplier has a Euro account in Ireland, a USD account in the US, or operates in a country without an equivalent service, CoP can't help. For cross-border B2B payments — which most UK mid-market businesses make at some volume — you need a parallel verification layer. The EU's Verification of Payee (VoP), live since October 2025 under the Instant Payments Regulation, is the closest equivalent and works for EU SEPA payments. Outside of UK/EU, the verification methods vary by country: ACH validation for the US, NPCI for India, PIX-equivalent for Brazil, and so on. See cross-border bank account verification for the country-by-country picture.

3. CoP doesn't tell you about supplier-side compromise (VEC)

The single highest-frequency attack vector for UK businesses isn't a fraudster setting up a fake company — it's a fraudster compromising a legitimate supplier's email and redirecting payments. The supplier is real. Their bank account is real. Their CoP records are correct. But the email asking you to change the payment details from their normal account to a "new account" came from a fraudster who has access to the supplier's inbox.

If your AP team takes the new account details, runs CoP, and gets a Match, the payment proceeds. The Match is technically correct: the new account belongs to whoever the fraudster set it up under (often a money mule whose name was supplied to the receiving bank legitimately). CoP can't tell you that the bank-detail change request itself was fraudulent.

This is the gap that costs UK businesses the most. UK Finance reported £25 million lost to invoice and mandate scams in the first half of 2024 alone, and 78% of those losses (£20 million) occurred on business accounts — not personal ones. For the operational picture on how this attack works, see vendor email compromise vs business email compromise.

A concrete scenario: what VEC-against-CoP looks like

A composite, anonymised UK scenario showing how this failure mode plays out in practice.

The setup. "Sterling Tech Ltd" is a UK SaaS company that's been paying "Hartley Engineering Limited" — a small UK supplier — for two years. Monthly invoices of around £12,000 for ongoing engineering support. Payment details have never changed. Hartley uses a Barclays business account; the legal entity name on file at Sterling matches the CoP-registered name. Everything has been clean.

The attack. On a Tuesday morning, Sterling's AP team receives an email from "James Hartley" — the supplier's regular contact, whose email address they recognise immediately. The email explains that Hartley has switched banking providers and asks Sterling to update the payment details for this month's invoice to a new account at a different UK bank. The email is well-written, references the recent invoice number, and includes a polite closing. Everything looks normal.

What Sterling's process catches — and misses. Sterling has a CoP-first policy on bank-detail changes. The AP analyst enters the new sort code and account number into the banking platform, sets the account holder name to "Hartley Engineering Limited," and submits a CoP check. The response comes back: Match. The receiving bank confirms the account is registered to "Hartley Engineering Limited." The analyst saves the new details and processes the £12,000 payment.

What actually happened. James Hartley's email account was compromised six weeks earlier by an attacker who patiently studied Hartley's email patterns and waited for the right moment. The "new bank account" was opened in Hartley's legal name — using fake documentation that fooled the receiving bank's onboarding. The CoP "Match" was technically correct: the account holder name on file at the receiving bank really did read "Hartley Engineering Limited." The fraud lived in the bank-detail change request itself, not the account details.

How it surfaces. Three weeks later, the real James Hartley calls Sterling asking when this month's payment will arrive. By that point the £12,000 has moved through the fraudulent account and out via three further hops. Sterling's only realistic recovery path is the PSR APP fraud reimbursement scheme — and even there, Sterling needs to demonstrate that they followed appropriate caution. The Match response on CoP isn't a defence; it's the system working as designed, which is precisely the gap.

What would have caught it. A callback to Hartley on a phone number from Sterling's CRM (not the email signature) would have surfaced the fraud in 30 seconds. So would running the new account against a continuous-monitoring webhook that flagged the account as recently-opened. Both are mature, available controls — but neither is part of "CoP-first" policy. They're the controls that need to surround CoP, not replace it.

The full UK supplier verification workflow

What a working bank account verification workflow looks like for a UK finance team in 2026 — across vendor onboarding, before each material payment, and continuously thereafter.

At vendor onboarding

Onboarding is when verification is cheapest and most informative. The supplier wants to be paid; their incentive to provide accurate data is highest; and the audit trail starts at the point of first contact.

• Verify the entity at Companies House. Confirm the supplier exists, is in good standing, registered address matches what they supplied, and check the directors and PSC (Persons with Significant Control) data. Entity status of "Dissolved", "Liquidation", or "Strike off action in progress" should pause the onboarding.
• Run a CoP check on the supplied bank account. A "Match" or "Close Match" with explainable trading-name reason is acceptable; "No Match" requires direct contact with the supplier to resolve.
• Cross-check the account holder against the entity name. The CoP check confirms the account is registered correctly — but you also want to confirm that the account holder name on CoP matches the legal entity name from Companies House. A small mismatch (trading name vs legal name) is normal; a large mismatch is a fraud signal.
• Sanctions and PEP screening on the entity and its directors. Required under UK MLR 2017 for all regulated firms; advisable for unregulated firms paying suppliers in higher-risk sectors.
• Document the verification with timestamps, source attribution, and result codes. Under MLR 2017 record-keeping requirements, this is mandatory for regulated firms; under PSR APP fraud rules, it's defensive evidence if a fraud claim is later raised against the supplier.

Before each bank-detail change

This is the single highest-yield workflow control. Industry data is consistent on this: bank-detail change requests are where fraud concentrates. UK Finance, Action Fraud, and the National Business Crime Centre all single out mandate fraud as the attack pattern AP teams most commonly miss.

• Treat any bank-detail change request as suspicious by default. The threshold isn't "is this likely fraud" — it's "have we verified this through an independent channel."
• Verify by callback to a known number. Not the number in the email requesting the change. A phone number from your existing supplier records, your contract, or the supplier's website.
• Run CoP on the new account before saving it to the master file. Don't update the master file first and verify second — that creates a window where a payment can be sent to an unverified account.
• Check the legal entity name on the new account matches the existing supplier's legal name. A supplier whose entity is "Acme Limited" should not have their account suddenly registered under "Acme Holdings Limited" without explanation.
• Escalate any "No Match" or unexplained "Close Match" to senior approval. The PSR's standard of caution exception specifically calls out failing to engage with PSP intervention as a reason reimbursement can be denied — strong internal controls strengthen your position if a fraud claim arises.

For high-value payments

For payments above an internal threshold (typically £10K–£50K depending on the firm's risk appetite), additional verification reduces the operational impact of a single fraudulent payment slipping through.

• Re-run CoP at payment initiation. Confirm the account is still active and the registered name still matches what's on file.
• Check the entity status at Companies House. Dissolved or inactive entities should trigger an immediate pause.
• For payments over £85,000. Note that this is the PSR reimbursement cap — meaning if the payment goes wrong and is determined to be APP fraud, the consumer can only recover up to £85,000 from the PSP. For payments above the cap, internal controls take on disproportionate importance because the regulatory backstop is partial.

Continuous monitoring between payments

Vendor changes happen continuously: ownership restructurings, director resignations, dissolutions, account closures, and UBO transfers. The point of continuous monitoring is to catch these before the next payment cycle so the next payment flows through a check that reflects current state, not stale onboarding data.

• Subscribe to webhook alerts on Companies House data. Director appointments and resignations, change of registered office, status changes (e.g., "Strike off action proposed"), and filing-deadline misses are all early warning signs. Companies House is free and authoritative for UK entity data — but it only covers the UK, and the data depth is limited to what UK statute requires firms to file.
• For deeper UBO and cross-jurisdictional monitoring, layer a company-data vendor on top. Companies House records the Persons with Significant Control (PSC) but doesn't track ownership changes that happen below filing thresholds, through nominee arrangements, or via overseas holding entities. Specialist vendors like Global Database aggregate data from 200+ government registries across 600M+ companies — providing the corporate group structure, beneficial ownership chains, and cross-border linkages that pure Companies House subscriptions miss. For UK firms with EU exposure, overseas suppliers, or sophisticated supplier structures, this layer is increasingly operationally essential.
• Monitor UBO changes specifically — not just director changes. A supplier can keep the same registered directors while the controlling beneficial owner shifts through share transfers, holding-company restructuring, or nominee arrangements — none of which trigger a director-resignation filing. UBO drift is the silent attack vector: a clean supplier at onboarding can quietly come under sanctioned or high-risk ownership without any Companies House event firing. Webhook-driven UBO monitoring catches this; annual or quarterly re-screening doesn't. For the full case on why UBO verification matters in 2026 — and how it complements bank account verification — see beneficial ownership verification in B2B payments.
• Subscribe to webhook alerts on the supplier's bank account status. Account closures, account-holder-name changes, and status flag changes (e.g., from "Active" to "Account holder deceased").
• Re-screen against sanctions and PEP lists on a defined cadence. Sanctions designations change frequently; a supplier who cleared screening at onboarding may have been designated since. Sanctioned UBOs are particularly time-sensitive — a UBO designation made the day after annual re-screening leaves 11 months of unmonitored payment exposure.

For a deeper case on why one-time verification isn't enough — and why continuous monitoring is now the operational standard — see why one-time verification fails.

How UK verification methods compare

UK businesses have several technical options for bank account verification. They differ in what they confirm, what they cost, and where they fit in the workflow.

The pattern that emerges: no single method is sufficient for UK B2B verification. CoP is the right first-line check, but it works alongside Companies House KYB at onboarding, manual callback verification for bank-detail changes, and continuous monitoring between payments. For a comparison of how these methods interact with their non-UK equivalents (VoP, ACH validation, NPCI), see our 7 verification methods compared article.

Where this workflow fits by industry

The verification workflow isn't one-size-fits-all. The right depth depends on payment volume, supplier risk profile, and regulatory exposure.

Mid-market and corporate AP teams

Typical pattern: 50–500 active suppliers, monthly payment cycles, payments ranging from £500 to £200K+. The bank-detail change attack vector is the highest concentration of risk. Full workflow: Companies House KYB at onboarding, CoP at onboarding and before every bank-detail change, manual callback for changes, continuous monitoring as a webhook subscription.

Fintech and PSP operators

Different exposure: you're the PSP, so you're directly subject to the SD19/SD20 reimbursement obligations. Verification of incoming counterparties (your customers, your customers' counterparties) is part of your regulatory obligations under MLR 2017 and now under the PSR APP fraud reimbursement regime. CoP is mandatory for in-scope PSPs; Companies House KYB at customer onboarding is the standard; continuous monitoring is increasingly expected by examiners.

Marketplaces with UK seller payouts

Marketplaces face a hybrid problem: they have thousands of sellers (high-volume, low-touch verification) but each seller represents an entity with a bank account that needs to be onboarded. The pattern that works: Companies House KYB at seller signup, CoP at first-payout setup, automated re-verification when sellers change their bank details, sanctions and PEP screening at intervals. See KYB verification for marketplaces for the full workflow.

Charities and microenterprises

These groups are explicitly named in the SD19/SD20 scope as in-scope customers for reimbursement protection. For charities receiving and paying funds, the workflow is simpler but the stakes are high — invoice fraud in the charity sector has been a documented attack pattern for years. Minimum viable workflow: CoP on new payee accounts, manual callback for changes, Companies House check on supplier entities (free service for basic entity data).

What's coming next: 2026-2027 regulatory horizon

The Oct 2024 PSR rules were the first major step. The UK regulatory roadmap continues evolving, and any UK verification workflow should be designed to absorb three near-term changes.

CHAPS rules under review

The current PSR reimbursement regime covers Faster Payments and retail CHAPS, but the Bank of England signalled in its Dec 2023 announcement that it intends to develop a comparable reimbursement model for wholesale CHAPS payments. The PSR has been considering specific directions to CHAPS participants. For UK businesses making large CHAPS payments — common in property settlements, corporate M&A, and high-value treasury transfers — the asymmetric protection between Faster Payments and CHAPS is closing.

Open banking AIS evolves under PSD3

The EU's proposed PSD3 + PSR1 package, expected to apply from late 2026 onwards, doesn't directly govern UK regulation post-Brexit — but it sets the direction that UK regulators will mirror. The implications for AIS-based verification: stricter bank-side API quality requirements, expanded scope for B2B AIS use cases, and tighter fraud-prevention obligations on PSPs. UK platforms architecting around AIS now should expect more reliable AIS infrastructure in late 2026 onwards. See open banking AIS vs registry-based verification for the architectural framing.

Continued PSP expansion of CoP

The PSR's 2024 directive added almost 400 new PSPs to the CoP scheme — but this still doesn't cover every UK account type. Building societies, smaller banks, and certain account types (notably some commercial accounts requiring payment references) are still partly outside the CoP perimeter. UK businesses should expect CoP coverage to continue expanding, but should not rely on it covering 100% of accounts they pay to.

The verification floor is rising

The broader pattern is consistent: across UK regulation, EU regulation, and US regulation, verification is moving from "good practice" to "documented compliance obligation." A UK supplier verification workflow designed today should anticipate a near-term future where: every bank-detail change must be re-verified, continuous monitoring of supplier registry data is the standard, and verification audit trails are routinely requested in regulatory examinations and APP fraud disputes. The economic incentive — and increasingly the regulatory incentive — points in one direction: verify deeply, document everything, monitor continuously.

Frequently Asked Questions