By: Money Navigator Research Team
Last Reviewed: 11/02/2026
FACT CHECKED
Quick Summary
In Tide, payees are saved “recipients” used to speed up bank transfers. Adding and removing recipients is controlled by access level: it is positioned as an Admin capability and as part of “View, Draft, Send & Pay” team access, rather than a view-only action.
“What gets logged” is best understood as what Tide retains and shows later – saved recipient details, recipient-level views of sent transactions across a date range, and payment-level evidence (for example payment confirmations).
This article is educational and not financial advice.
What Tide means by “payee” and “recipient”
Tide’s help content uses “recipient” for the saved set of payment details you select when creating a transfer. In its published flow, a recipient record stores the details you would otherwise re-type each time you pay someone, and it can be organised (for example by using a display name or favourites).
The clearest description of the fields and management options is in Tide’s guide on recipients: Add payees and set up payments | Tide Business.
A key distinction is that a saved recipient is not a payment in itself. A recipient record is a stored pointer to payment details; a payment remains a separate event that is authorised and then appears in account activity.
Who can add and remove payees in Tide
Tide describes payee management (“add or remove payees”) as part of the capabilities available to Admins, and also to team members who have “View, Draft, Send & Pay” access. That statement appears in Tide’s own Team Access feature overview: Tide Team Access | No more password sharing | Tide Business.
Tide also distinguishes this from view-only access, which it positions as visibility without actions. In practice, that means “who can add/remove payees” is primarily a permissions question rather than a feature question.
For adjacent internal coverage (broader than this article), our sitemap also includes separate guides focused on Tide roles and on payment approvals.
What gets stored when a payee is added
Tide’s recipient flow for UK domestic recipients lists core fields such as account holder name, sort code and account number, with an optional display name.
It also shows an explicit “approve” and “authorise” step when adding a recipient, which indicates that recipient creation is treated as an authenticated account action in the product flow.
Once saved, Tide’s recipient management view is described as supporting:
deleting a recipient
setting a display name
adding a recipient to favourites
viewing transactions sent to that recipient within a chosen date range
Those options (including the recipient-level activity view) are described in Tide’s recipient guide linked above.
Confirmation of Payee and “verified” recipients
In UK domestic payments, Confirmation of Payee (CoP) is a name-checking service designed to reduce misdirected payments and increase assurance that payments are being sent to the intended account holder. Pay.UK explains CoP at scheme level here: Confirmation of Payee – Pay.UK.
UK Finance also summarises typical CoP outcomes (for example “match”, “close match”, “no match” and “unavailable”) and how the check is intended to be used in practice: Confirmation of Payee | Policy and Guidance | UK Finance.
Confirmation of Payee and “verified” recipients
In UK domestic payments, Confirmation of Payee (CoP) is a name-checking service designed to reduce misdirected payments and increase assurance that payments are being sent to the intended account holder. Pay.UK explains CoP at scheme level here: Confirmation of Payee – Pay.UK.
UK Finance also summarises typical CoP outcomes (for example “match”, “close match”, “no match” and “unavailable”) and how the check is intended to be used in practice: Confirmation of Payee | Policy and Guidance | UK Finance.
What gets logged
In day-to-day business use, “logged” usually means “what can be evidenced later” rather than “what internal systems might store”. For payees in Tide, there are three practical layers:
1) Recipient-level record (payee list and activity view)
Tide’s recipient screens retain the saved recipient details and provide a recipient-level view of outgoing transactions across a selected date range. This is the closest thing to a “payee log” that Tide describes publicly, because it ties an individual recipient to visible sending history.
2) Payment-level record (timeline and confirmations)
Separately, each payment remains a distinct transaction in the account timeline. Tide describes producing a payment confirmation document from the timeline for a specific payment, which can function as operational evidence of a transfer: How do I send a payment confirmation? | Tide Business.
3) Authentication context (who the system treats as giving instructions)
Tide’s membership terms describe access via personalised security credentials and explain that if those credentials are used to access the account, Tide assumes the person using them is the person giving instructions. That matters in multi-user settings because “who did it” is inherently tied to the credential used at the time. See: Tide Membership and Product Terms | 2 February 2026 (PDF).
Alongside these product-layer records, organisations handling personal data must keep it secure and limit access and changes to authorised people.
The ICO summarises this expectation within the UK GDPR security principle, including that personal data is only accessed or altered by those authorised to do so: A guide to data security | ICO.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Admin adds a new domestic recipient | Recipient is saved and becomes selectable for future payments | Repeat payments become faster; recipient-level activity can later be reviewed by date range |
| Team member with “View, Draft, Send & Pay” adds a recipient | Recipient is saved within that access model | Operational delegation is possible without sharing credentials |
| View-only access user reviews recipients | Recipient visibility can support oversight without changes | Helps separation between monitoring and control |
| Recipient is deleted | Recipient no longer appears in the selectable list | Future payments may require re-adding details if needed again |
| Proof is needed that a payment was sent | A payment confirmation can be generated for the transaction | Supports supplier and audit workflows where evidence is requested |
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| Create recipient | Enter recipient details and complete the in-app approve/authorise steps | Recipient record is retained for selection in later payments |
| Organise recipient list | Apply display names, favourites, and list sorting/filtering | Faster navigation and reduced selection errors in repeat workflows |
| Review recipient history | Open a recipient and view outgoing transactions for a date range | Recipient-centred “sending history” view is available |
| Evidence a payment | Select a payment in the timeline and generate a confirmation | Shareable proof-of-payment document is available for that payment |
| Remove recipient | Delete the recipient from the recipients area | Recipient record is removed from the selectable list for new payments |
Tide Business Bank Account
Tide offers UK business accounts and related tools through its app and web experience. Availability of specific controls can vary by access level and plan, and Tide’s own help content is the definitive reference for current in-app steps.
For a neutral overview of the wider Tide account proposition, see our Tide business account review.
Frequently Asked Questions
Adding a recipient in Tide stores the recipient details for later selection. That makes repeat transfers quicker because the details do not need to be re-entered each time.
A payment remains a separate event. In practical terms, “recipient created” and “money moved” are different records: one is a saved recipient entry, the other is a transaction that appears in account activity and can be evidenced later.
Tide positions adding/removing payees as part of Admin capabilities and as available to team members with “View, Draft, Send & Pay” access, rather than as part of view-only access.
This matters because payee management changes the set of selectable payment targets. In multi-user environments, the permission boundary helps separate who can observe from who can change payment setup.
In Tide’s published recipient flow, adding a recipient includes an “approve” and “authorise” step. In general product terms, that indicates an authenticated action rather than a passive edit.
For logging and accountability, an authenticated step also matters because it ties the change to an account session and credential context, which is relevant where multiple users may have access.
Tide’s recipient setup flow lists fields such as account holder name, sort code and account number, and also indicates that a display name can be optional. That combination reflects two layers: core payment routing details and optional organisation metadata.
Recipient management also includes organisational features like favourites and recipient-level viewing of outgoing transactions across a date range. Those features are “what gets retained” in everyday operational terms, even if a separate audit log is not exposed to end users.
Tide describes some recipient changes (such as display name, favourites and deletion) as options in the recipient management view. That makes it clear that not all adjustments are treated the same way.
Where core routing details change, many payment products treat this as a new payment target rather than a silent edit. The practical implication is that a recipient list can contain historical entries alongside current ones, and deletion removes an entry from selection rather than rewriting past records.
Confirmation of Payee is designed to reduce misdirected payments by checking whether the name matches the account details for a UK payment. It is a scheme-level control, and results depend on scheme participation and availability at the time of the check.
“Unavailable” can occur for reasons beyond the payer’s control (for example timeouts or where a firm is not enabled for the service). In operational terms, CoP is an additional check signal rather than a guarantee of successful delivery.
Tide notes that, as a security measure, it may limit how much can be sent to a newly added payee within the first three hours. That indicates a time-based risk control around first-time sending behaviour.
The practical impact is that a recipient can exist and still be subject to short-term limits on outgoing payments. This is relevant for payroll runs, supplier payments, and any workflow where first-time payment targets are created shortly before funds are sent.
Tide describes scheduled payments (standing orders and future-dated payments) as a separate feature area with its own management steps, including cancellation and deletion of scheduled items. That indicates scheduled instructions are not simply “the payee list”.
Because recipients and scheduled payments sit in different parts of the product, deleting a recipient does not necessarily describe what happens to an already-scheduled payment. The operational implication is that a scheduled payment is best assessed within the scheduled payments area rather than inferred from the recipient list alone.
At transaction level, a payment confirmation document provides a clear, shareable artefact tied to a specific payment. It is typically the most portable evidence when a counterparty requests proof.
At recipient level, a date-range view of outgoing transactions to that recipient can support internal reconciliation and checking “what was paid and when”, even when a payment confirmation is not being shared externally.
Tide’s terms frame account access around personalised security credentials and treat actions as being instructed by the person using those credentials at the time. In multi-user settings, that means accountability is closely linked to access configuration and credential use.
From a governance perspective, this aligns with the broader expectation that access and changes to personal data are expected to be limited to authorised individuals. In payment operations, payee changes are a form of control change, so the credential boundary is part of how “who did it” is commonly understood.
Payee lists exist to reduce friction in making repeat payments, but they also concentrate operational risk: a single saved recipient can become a default destination for future transfers.
The only practical way to manage that risk at product level is permissioning (who can change the list) and authentication (how the platform decides which user instructed the change).
That is why “what gets logged” is rarely just one thing. Tide describes a recipient record with recipient-level sending history, payment-level records (including confirmable evidence), and instruction/accountability through credential use.
Taken together, those layers explain why “payee management” is both a usability feature and a governance control: it affects day-to-day efficiency, and it also affects how a business later evidences who created or removed a payment target, and how later questions or disputes are investigated.
Sources & References
Related Content
