By: Money Navigator Research Team
Last Reviewed: 12/02/2026
FACT CHECKED
Quick Summary
Confirmation of Payee (CoP) in Tide is a name-check that compares the payee name and account details entered against the details held by the payee’s bank, then returns a result such as match, partial/close match, no match, or unavailable.
Most “mismatch” situations are caused by the payee’s bank account name being different from the trading name used on invoices, or by data-entry differences (including account type).
CoP is a useful signal, but it is not a guarantee of legitimacy and it does not automatically validate the underlying invoice or instruction.
This article is educational and not financial advice.
What Confirmation of Payee is doing in Tide
Tide describes CoP as a check performed before making UK payments to help reduce misdirected payments and add friction against some scam patterns, with results shown to the payer in the payment flow as described in Secure your payments with Confirmation of Payee.
At an industry level, CoP is a name-checking service for UK payments intended to provide additional assurance that the payment is being routed to the intended account holder, set out in UK Finance’s overview of Confirmation of Payee.
Where the CoP check appears in Tide
In Tide’s published flow, CoP is positioned around setting up and paying recipients: you enter payee details (including the name on the account and whether it is a personal or business account), then the check is performed and the outcome is displayed, as shown in Secure your payments with Confirmation of Payee.
This creates a practical distinction between:
- Collecting and saving recipient details
- Executing the payment
Those steps may sit in different roles and approval paths inside a business, depending on how payment permissions are structured.
The CoP outcomes Tide shows, and how they map to “match vs mismatch”
Tide’s CoP page sets out outcome categories including complete match, partial match, no match, wrong details, and not able to check, with short explanations and examples in Secure your payments with Confirmation of Payee.
Across the wider scheme, Pay.UK explains the common payer-facing outcomes (match, close match, no match, and variants where the service is unavailable) and how “close match” can be handled, in the Confirmation of Payee FAQs.
In practice, Tide’s “partial match” aligns to the same concept as “close match” in scheme-level explanations: the name is similar, but not identical.
Name matching: what is being compared
CoP is comparing the details entered against the name and account details held by the payee’s account provider. That is why “the name used on invoices” and “the name on the bank account” can diverge without either being “wrong”.
Tide also treats receiving-side name clarity as part of CoP outcomes: when a Tide account is being paid, the payer’s CoP result depends on the name associated with that Tide account, with Tide describing what details to provide when receiving payments in How do I receive payments with Confirmation of Payee?.
Common mismatch scenarios in Tide
Trading name vs bank account name (the most common business cause)
Many small businesses trade under a name that is not identical to the name held on their bank account. UK Finance notes that for businesses the payer is effectively trying to match the name registered to the bank account, which may differ from a trading name, in its guidance on Confirmation of Payee.
Tide’s own CoP guidance highlights this dynamic with examples (including sole trader trading names), and also describes how Tide accounts may present names when receiving payments under CoP checks.
Personal vs business account type entered
Tide’s CoP instructions include entering the account type (personal or business) when adding a payee, and the check is performed against what the receiving bank holds.
A mismatch can therefore arise where the payee is a business but the account is held as a personal account (or vice versa), or where the payer selects the wrong type during setup.
The practical impact tends to be operational rather than technical: payment initiation can pause while details are clarified, especially in workflows where payees are being added quickly (for example, supplier onboarding or first-time payroll payments).
“Close match” differences (similar but not exact)
Pay.UK describes “close match” as a situation where a similar name is used and the actual name can be presented for confirmation in its Confirmation of Payee FAQs.
This category is where small differences often surface: abbreviations, missing words, or a business being known by one name while the account is registered under another.
From a practical standpoint, “close match” is often where teams discover that internal supplier master data is out of sync with bank account naming conventions, which can create recurring friction across new-payee setup.
“No match” vs “wrong details”
Tide distinguishes “no match” from “wrong details” in its CoP explainer, describing “wrong details” as a situation where the details do not match any account at the recipient’s bank in Secure your payments with Confirmation of Payee.
Operationally, “no match” can still occur where an account exists but the name is materially different, whereas “wrong details” points towards a routing problem (for example, incorrect identifiers) rather than a naming difference.
UK Finance explains that CoP can be unavailable where it is not possible to check the name due to issues such as timeouts, opt-out, or where the account does not exist, and also notes that availability can depend on whether the relevant financial institution has enabled the functionality, in its Confirmation of Payee guidance.
Tide also describes “not able to check” outcomes and indicates that in some cases the recipient’s bank may not participate, in Secure your payments with Confirmation of Payee.
Practical implications for app-first payment operations
CoP is a point-in-time signal shown inside the payee setup/payment journey, so it sits directly in the same “moment” as authentication (unlocking and authorising activity in the app) rather than in back-office reconciliation.
Where device-led authentication and in-app authorisation shape payment workflows, a useful companion explainer is Biometric Login in Tide Explained: What Happens on Your Device vs in the App.
CoP prompts and outcomes are also experienced through Tide’s access channels, which can matter where finance teams use a mix of app and web access.
For channel constraints and operational differences, see Device and Browser Requirements for Tide Explained: App vs Web Access Differences.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Payee name matches the name held by the receiving bank | Complete match | Lower chance of accidental misdirection caused by name-entry differences |
| Payee name is similar but not identical | Partial / close match | Often introduces a pause in onboarding or first payment workflows while details are clarified |
| Payee name does not match | No match | Can indicate material naming difference or a potential scam pattern; often blocks “straight-through” processing in practice |
| Routing identifiers do not correspond to an account at the recipient’s bank | Wrong details | Suggests the account details are incorrect or incomplete, requiring rework before payment is attempted |
| The service cannot return a result | Not able to check / unavailable | Creates uncertainty: the payment flow may continue, but the name-check signal is absent |
| Supplier uses a trading name while bank account is registered differently | Partial / no match more likely | Repeated friction until records align with the bank-registered name |
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| First-time payment to a new supplier | Payee created > CoP check performed > result displayed | Match reduces friction; mismatch introduces decision points and operational delay risk |
| Data-entry variation | Name or account type entered differs from bank-held details | Close match/no match outcomes become more likely |
| Trading name usage | Invoice name ≠ bank account name | Mismatch outcomes can appear even when the supplier is genuine |
| Identifier error | Sort code/account number incorrect | “Wrong details” style outcome is more likely than a naming mismatch |
| Scheme availability limits | Timeout/opt-out/non-enabled institution | “Unavailable/not able to check” outcome; no positive assurance signal |
| Receiving payments into Tide | Payer’s bank runs CoP against Tide account name | Payers may see mismatch unless they use the account name associated with the Tide account |
Tide Business Bank Account
Tide’s payment and recipient flows (including CoP outcomes) sit inside a wider app-based business account proposition, with pricing and feature design that can affect day-to-day finance operations. A neutral overview is available in our Tide business account review.
Frequently Asked Questions
Tide positions CoP in the context of making UK payments in-app and describes it working across payment types such as Faster Payments, CHAPS and Bacs in its CoP explainer. In practice, whether a CoP check is shown can depend on how the payee is being set up and what information is entered.
Edge cases can occur where the name check cannot be completed, resulting in an “unavailable/not able to check” outcome rather than a match/no match signal. That is different from CoP “not existing”; it is the service returning no usable result for that attempt.
CoP is a signal displayed to the payer; it is not, by itself, an invoice validation process or a guarantee of legitimacy. Tide’s guidance indicates the outcome is shown and the payer can then decide how to proceed within the payment flow.
A practical complication is governance: where one person sets up payees and another approves payments, mismatches can become “handoff events” that slow processing because clarification is needed before a payment is released.
Tide describes “partial match” as a close-but-not-exact alignment between entered details and the receiving bank’s records, and “no match” as a non-alignment that can indicate higher risk.
In scheme-level descriptions, Pay.UK and UK Finance use “close match” for the partial-match concept and “no match” where the name cannot be matched.
In practice, “partial/close match” is where minor naming differences surface (similar names, missing elements, or different naming conventions), while “no match” is where the naming gap is large enough to trigger a stronger warning signal.
Tide’s CoP flow includes entering whether the payee account is personal or business, which becomes part of the information set being checked against the receiving bank’s records. If the account type is entered incorrectly, the check can produce a mismatch result even where other details are correct.
This is particularly relevant where the counterparty is a sole trader: they may trade under a business name but be paid into a personal-name account, which can create naming and classification complexity in first-time payment setup.
A supplier can be genuine while the bank account name differs from the name used in commercial communication. UK Finance notes that business payers may need the name registered to the bank account, which may not be the same as a trading name.
Close match outcomes also commonly surface when internal records are incomplete or inconsistent (for example, staff using slightly different versions of a name across invoice processing, onboarding forms, and the payee setup step).
Tide describes “wrong details” as meaning the details entered do not match any account at the recipient’s bank, which points towards a routing issue rather than a naming variation. In practical terms, this is the outcome most aligned to “the account identifiers are not valid for that destination”.
An operational edge case is that “wrong details” can arise where the receiving institution’s systems cannot recognise the combination of details supplied at that moment, which can feel similar to “unavailable” from a user perspective even though the label differs.
UK Finance describes “unavailable” outcomes as situations where it is not possible to check the name, including timeouts, opt-out, or where the account does not exist, and also notes that availability can depend on whether relevant firms have enabled the functionality.
In Tide’s framing, “not able to check” can also occur where the recipient’s bank is not participating. Practically, that means the payer receives no name-matching reassurance signal, which can increase operational uncertainty in first-time supplier payments.
When others pay a Tide account, their bank may run a CoP check against the name held on the Tide account. Tide’s guidance on receiving payments with CoP explains that the payer’s experience depends on being given the correct payment details and the right name associated with the account.
The most common edge case is sole traders: the name that produces a match may be the individual’s name rather than the trading name used on invoices. That can affect how invoice templates, payment instructions, and onboarding packs are written.
CoP is designed to help reduce misdirected payments and add friction against some scam patterns by highlighting mismatches between entered details and bank-held details, as described by Tide and by scheme-level explanations. It can therefore act as one signal in the overall fraud-risk picture.
However, CoP does not validate that the invoice itself is legitimate or that the payment instruction is authorised. A match result indicates that the name and account details align with bank-held records, not that the request is genuine or appropriate.
CoP is most commonly encountered when setting up a payee or making a first-time payment, because that is when name and account details are being entered and validated in the flow.
In many payment systems, a new check is more likely when key identifiers are added or changed than when paying an unchanged, previously-used payee.
An edge case is governance: if recipient records are edited or recreated, a business can effectively experience CoP again as part of the “new payee” journey. That is why payee lifecycle management and approvals can shape how often CoP results are surfaced operationally.
CoP is best seen as a “name-matching signal layer” that sits between payee data entry and payment execution. Its value is highest at the exact point where payment destinations are being created or changed, because that is when misdirection and manipulation risks are most acute.
Most business-facing friction comes from legitimate naming complexity: trading names, personal-name sole trader accounts, and differences in how banks store account names. CoP does not eliminate that complexity; it makes it visible at the moment of payment setup, which can improve control at the cost of occasional operational delay.
Related Content
