How to Set Financial Permissions for a Small Team

Why 'permissions' is more than one switch

It's tempting to think of financial access as binary — someone either has access to the business account or they don't — but that framing misses most of the actual risk. The more useful way to think about it is as four distinct permissions that can be granted separately: who can view balances and transactions, who can initiate a payment or purchase, who can approve that it should go ahead, and who can actually release or execute the payment.

Most modern UK business banking and card platforms, including Tide, support exactly this kind of role-based access rather than forcing every user into an all-or-nothing login, which means the technical capability to separate these permissions usually already exists — the missing piece is normally a deliberate decision about who gets what, not a limitation of the tools.

Thinking in these four layers also makes it much easier to reason about risk for any given role. A bookkeeper might legitimately need to view everything but never initiate a payment. A team member handling supplier orders might need to initiate but never approve their own request. Separating the layers lets you grant exactly what a role needs, no more.

The four permissions, defined

View access means someone can see balances, transactions and statements, but cannot move money or authorise anything. This is the lowest-risk permission and can reasonably be given fairly widely — to a bookkeeper, an accountant, or a manager who needs visibility to plan without needing to spend.

Initiate access means someone can start a payment or purchase request — filling in the amount, the payee, the purpose — but the payment doesn't move until a further step happens. This suits people who need to be able to get things moving without being trusted to be the final check on whether they should.

Approve access means someone can review an initiated payment and sign off that it should proceed. This is the step that should never sit with the same person who initiated the payment, wherever you can possibly avoid it, because self-approval removes the entire point of having an approval step.

Release access means someone can actually execute the payment once approved — the final action that moves the money. In many small setups this collapses into the same action as approval within the banking platform itself, but it's still worth being clear in your own head that this is the point of no return, and treating it with proportionate care.

1. View — see balances and transactions.
2. Initiate — start a payment or purchase request.
3. Approve — sign off that an initiated payment should proceed.
4. Release — execute the payment.

Separation of duties in a very small team

The textbook version of separation of duties assumes enough people to genuinely split every step, which most businesses with fewer than ten employees simply don't have. That doesn't mean the principle is irrelevant — it means you apply it as far as your headcount allows, and use written trails to cover the gap where a true second person isn't available.

In a two-person business, full separation for every payment isn't realistic, but you can still avoid the worst version of the risk: don't let the same person both initiate and approve a payment above your higher threshold without at least a written message to the other person first, even if that person can't formally block it. A one-line 'about to pay £X to Y for Z, flag now if that's wrong' message, sent before the payment goes, creates a moment where an error can be caught, even without a formal approval workflow.

As the team grows past two or three people, build genuine separation in as soon as you reasonably can, starting with the highest-value payments first — these are where the cost of an error or a bad decision going unchecked is greatest, so they deserve the earliest investment in a proper second check.

In a very small team, perfect separation of duties isn't available. A written trail and a genuine second look are the next best thing, and are far better than nothing.

Matching permissions to roles, not to trust

It's natural to want to give broad access to people you trust and narrow access to people you're less sure about, but permissions work better when they're matched to what a role actually needs rather than to how much you personally trust the individual in it. Trust is not a control — it doesn't leave a record, it doesn't scale as the team grows, and it offers no protection if a trusted person makes an honest mistake or if their account is compromised.

A useful discipline is to ask, for every permission you're about to grant, 'what does this specific role need to do its job, on a normal week' — and grant exactly that, rather than the maximum available in the platform because it's easier not to think about it further. Narrower permissions also protect the individual: someone who could never have released a fraudulent payment because they simply didn't have that access is in a much better position than someone who had the access and is now being asked whether they used it properly.

Setting this up in practice

Start by listing every person who currently has any kind of financial access, however informal — including anyone with a shared login, a card, or visibility into the business account — and write down what each of them can actually do today. This audit alone often surfaces access nobody remembers granting, particularly for former contractors or early hires whose access was never removed.

Then map each person against the four permission layers and decide, deliberately, what they should have going forward. Where the current reality doesn't match what you'd design from scratch, change it — most business banking platforms let you adjust individual user permissions without disrupting the account as a whole.

Finally, write the resulting decisions down somewhere accessible, even briefly — who has view, initiate, approve and release access, and since when — so that the picture doesn't live only in your head and can be checked and updated as the team changes.

1. List everyone with any current financial access, including informal or forgotten access.
2. Record what each person can actually do today across the four permission layers.
3. Decide deliberately what each role should have, based on need rather than trust.
4. Adjust access in your banking or accounting platform to match the decision.
5. Write down who has what, and review it at least every time the team changes.

Shared logins are a control failure, not a shortcut

Sharing one login across multiple people is one of the most common financial permission mistakes in small businesses, and it undoes almost everything a permissions structure is meant to achieve. Once several people use the same credentials, you lose the ability to know who actually did what, you lose the ability to remove one person's access without disrupting everyone else, and you make it far harder to investigate anything that goes wrong.

The usual reason for a shared login is that setting up individual access felt like more admin than it was worth for a small team, but most current UK business banking platforms make individual, role-based user access straightforward to set up — it's rarely more than a few minutes per person, and it's one of the more effective controls available for very little effort.

Reviewing permissions as the team changes

Permissions decay if they're only ever set once and never revisited. Someone's role changes and their access doesn't follow; someone leaves and their access lingers because removing it wasn't anyone's specific job; someone is promoted into a role that needs broader access and nobody thinks to widen it until it becomes a blocker. Build a habit of reviewing access at three specific triggers: whenever someone joins, whenever someone's role changes materially, and whenever someone leaves.

The leaver trigger deserves particular discipline, because it's the one most likely to be missed in the rush of someone's final week. Make removing financial access a fixed line item on your leaver checklist, actioned on or before their last working day, not left as a follow-up task that can slip.