Multi-user business banking permissions: give staff the access they need without giving everyone full control

Modern business bank accounts usually support several users with different roles. A bookkeeper may need statements, an accounts-payable employee may need to prepare payments, and a finance director may need to approve them. Good permission design keeps those duties separate so one compromised or mistaken user cannot do everything.

Design bank roles around real job responsibilities

Start by listing what each finance role actually needs to do: view balances, download statements, create payments, approve payments, add beneficiaries, manage cards or change account settings.

Do not give full administrator rights merely because that is the easiest setup. Excess permission becomes hidden financial risk the moment the user account is compromised or the employee changes role.

Use view-only access for people who do not move money

Accountants, auditors, finance analysts and some managers often need transaction data without payment authority. View-only access can reduce password sharing and manual statement exports.

Check whether view-only users can still see sensitive payroll, customer or personal data and limit account visibility where the bank supports it.

Separate payment creation from payment approval

Maker-checker control allows one employee to prepare a payment and another to release it. This is stronger than one user creating and approving the same transaction.

Use dual approval for material payments where available and set thresholds that reflect business risk rather than one universal limit.

Restrict beneficiary creation and bank-detail changes

Adding a new beneficiary can be more dangerous than creating a payment to a trusted one. Limit who can add or amend payees and require independent verification before approval.

Where possible, require one user to create the beneficiary and another to approve it before payments are allowed.

Use user and transaction limits

A payroll administrator may need to upload a £500,000 salary file but only £10,000 of ad hoc Faster Payments. Banks can support different permissions and limits by payment type.

Review limits after promotions, acquisitions and staff changes. Temporary increases should have expiry dates rather than becoming permanent.

Remove access immediately when employment or responsibility changes

Bank users should be part of the employee offboarding checklist. Disable access when staff leave and reduce rights when someone moves out of finance.

Do not rely on changing a shared password because shared bank accounts should not be the normal model. Named users create a stronger audit trail and easier removal.

Worked example: a company gives its bookkeeper statement access, its AP clerk permission to create payments up to £25,000, and two finance managers approval rights above £10,000. The AP clerk cannot add a new beneficiary without manager approval, and no single user can create and release a £100,000 supplier transfer.

Review the user list at least quarterly and compare it with HR records. Dormant users are easy to miss because they create no daily problem, yet their credentials can remain valid for years.

Keep emergency administrator access controlled. One or two senior users may need broad rights for outages or staff absence, but those accounts should have stronger authentication and more frequent review than routine users.

Worked example: a 40-person company has one bookkeeper, two AP staff, one finance manager and one CFO. The bookkeeper can view and download statements, AP staff can create supplier payments, the finance manager can approve up to £50,000 and the CFO approves above that. Only the finance manager and CFO can approve new beneficiaries. This is stronger than giving all five people administrator access.

Review account scope as well as action scope. An employee can need payment rights on the operating account but no visibility of payroll or acquisition accounts. Bank platforms that support account-level restrictions can reduce unnecessary exposure to sensitive information.

Keep holiday and absence cover pre-planned. Emergency permission changes made on payday are more likely to be rushed. A second trained approver should already exist rather than temporarily sharing someone else's login or token.

Document administrator actions. Adding users, resetting authentication and changing limits can be as sensitive as approving payments, so administrator events should appear in the periodic access review.

Use a permission matrix that lists every bank, account and role. Groups often have several portals, and one employee can be appropriately restricted at Bank A while still retaining excessive rights at Bank B. Quarterly review should compare all providers, not one portal at a time.

Where the bank supports payment templates, restrict who can edit template beneficiary details. A trusted template is only valuable if ordinary users cannot quietly change the destination account before release.

Review permission conflicts. A user who can both create beneficiaries and approve high-value payments may defeat the intended maker-checker design even if the portal shows two separate permission categories.