Tide Roles Explained: Admin vs Team Member vs Cashier and What Each Can Do

Tide describes the “first Admin” as the person who opened the account. In practical terms, that person starts with the highest permissions in the app, including the ability to invite other users and assign access levels.

An important edge case is continuity: where only one Admin exists, some account-level actions can become harder to manage if that Admin is unavailable (for example, if device access is lost or the Admin’s login details change).

This is not unique to Tide; it is a general feature of any role-based access model with a highest-permission user.

Tide states that additional company directors can be assigned Admin access, and that checks are performed against Companies House details for director status. That makes Admin access distinct from ordinary team access, because it is presented as tied to company officer records rather than only to an invitation.

A practical implication is that “director” and “day-to-day operator” are not always the same person. If a senior employee needs access, they may qualify as a team member with a specific access level, while Admin access may be restricted to directors depending on the product rules and checks.

Tide describes Admin as the highest level of access, and lists examples such as:

• Managing other users
• Activating products and services
• Managing membership plans and add-ons

Tide also notes scenarios where an Admin may be able to close the account if they are the only remaining Admin.

The edge case is that “highest access” often includes actions that are irreversible or operationally sensitive, like changing who else can use the account.

That is why many platforms treat Admin changes as higher risk than ordinary permission changes, and why adding or replacing Admins can feel more “process-heavy” than inviting a view-only user.

In everyday terms, “Team Member” is shorthand for “a non-admin user who can access the account”. In Tide’s design, that label is incomplete without the access level – because abilities vary from read-only visibility to payment-capable permission sets.

A common misunderstanding comes from assuming a “team member” can always perform the same tasks across different businesses or plans. In practice, the same label can describe very different permissions, so the assigned access level is the only reliable way to interpret what the user can do.

Tide describes Cashier as a type of team member role. The practical difference is the permission scope: the Cashier role is designed to accept card payments through Tide’s payment tools, while other account features remain unavailable.

An important boundary condition is that “payments” here means taking customer card payments, not sending money out of the business account.

This split can reduce the chance that a payments-only user can see balances or make outbound transfers while still allowing the business to operate in-person payment taking.

Tide describes onboarding checks for invited users, including identity and address details, and states that approval can take up to two days (while often being faster).

These checks are applied to the additional user being added, not only to the business entity that opened the account.

A typical edge case is timing: Tide states invitation links are valid for 7 days, so an invite may need to be reissued if it expires before the person completes onboarding.

Another common edge case is where the invited user cannot complete a verification step (for example, a phone-number or device step), in which case access cannot be granted until the onboarding checks are complete.

Access systems typically rely on identifiers such as email address and phone number to connect a user profile to a device and session. If those details change, the user’s experience can change even when the underlying permissions remain the same (for example, a re-verification step or a different login flow).

From a control perspective, changes to identity-related details can also be a re-check trigger because they affect how the provider confirms who is using the account. This does not automatically indicate wrongdoing; it can be a normal outcome of access controls that are designed to reduce account takeover risk.

Tide states that Cashiers do not have the option to view balances, access statements, or initiate bank transfers. For other team members, visibility and action depend on the access level that was assigned (for example, view-only versus a payment-capable level).

The practical edge case is mixed teams: one user might report “I can’t download statements”, while another user in the same business can, because their permissions differ.

Where internal processes depend on statements or transfers, the team’s operational experience can change simply because the access level chosen for each user is different.

Tide’s Admin role description includes managing membership plans and add-ons as an example capability. That implies billing-related control generally sits with Admin-level access rather than with narrower team permissions.

For businesses that want separation between “people who pay suppliers” and “people who can change the plan or add products”, this distinction can matter operationally.

For plan mechanics and billing artefacts, see our explainer on Tide membership billing: monthly fees, VAT, billing dates and invoices, which often sits alongside role design in day-to-day controls.

User roles affect who can act in the app, not the underlying regulatory status of the provider or product. Whether money has FSCS deposit cover (subject to eligibility) or is instead safeguarded depends on the account and provider arrangement, not on whether a user is an Admin or a Cashier.

For a neutral explanation of how non-bank payment providers are described and how safeguards differ at a high level, the FCA’s consumer page on using payment service providers summarises FSCS deposit cover versus safeguarding. Role management sits on top of the product structure; it does not change the underlying framework.