Dormant online banking users: disable access that no longer has an active business need

A dormant online banking user is an account that remains provisioned even though the person has not used the service recently or no longer needs the banking role. This guide explains the mechanics, evidence, failure points and controls a UK business should understand before relying on the process.

What this means in practice

A dormant online banking user is an account that remains provisioned even though the person has not used the service recently or no longer needs the banking role. Treasury should convert the idea into an operating rule because the consequence normally appears in funding, timing, reconciliation or control.

Inactivity should trigger review rather than automatic trust: the user may be on leave, moved roles, left the organisation or simply retain unnecessary privileged access. The team should use current transaction facts because small differences in entity, date, currency or service configuration can change the answer.

How the process works

The operating sequence should move from identification to validation, approval, external action and then confirmation. For this topic, the critical mechanics are: Inactivity should trigger review rather than automatic trust: the user may be on leave, moved roles, left the organisation or simply retain unnecessary privileged access.

Timing should be planned backwards from the required result. Notice periods, value dates, processing windows and internal approval deadlines can make a correct instruction operationally late, so the workflow needs a repair margin.

The data and evidence that matter

The working file should contain user, legal entity, bank portal, role, last login, last approval, employment status, manager, MFA status, review decision and disablement date. Keeping those fields together lets another reviewer reproduce the decision without relying on the original operator's memory.

The record should distinguish internal intention from external outcome. An approved request proves what the company intended; a bank acknowledgement, lender consent, statement entry or counterparty confirmation proves what actually happened.

Where the process can fail

An old account can become attractive to an attacker because nobody expects normal activity and the business may not notice its misuse quickly. The problem usually becomes harder and more expensive to fix as the settlement, testing, maturity or payment date gets closer.

Repeated emergency workarounds are evidence that the design is weak. If the same override is needed month after month, management should repair the timetable, configuration or data rather than normalise the exception.

Worked example: test the mechanics

A former regional finance manager retains view-and-approve access to three bank portals six months after moving to a non-finance role. The user has not logged in, but inactivity alone has not removed the authority. A dormant-user review should disable or reduce the access.

The figures are illustrative rather than universal terms. In a live case the team should replace every amount, date and threshold with current source evidence, then repeat the test before treating cash, consent or coverage as available.

Governance and control design

Set inactivity review thresholds, reconcile users to HR and role data and require fresh approval before reactivating dormant banking access. The evidence should sit beside the transaction so later review can separate a deliberate approved exception from a control that was simply missed.

Useful oversight includes dormant banking users by privilege level, days inactive and time from review trigger to disablement. This turns the policy into an operating discipline with a measurable escalation point.

A post-event review should identify whether any exception came from data, timing, authority, system design or misunderstanding of the external rule, then assign remediation that can be tested in the next cycle.

Ownership should survive absence and staff turnover. The procedure for dormant online banking users should state who acts, who reviews, where evidence is stored and how unresolved items are escalated when the normal owner is unavailable.

Documentation should be short enough to use under pressure. A one-page operating checklist can point staff directly to user, legal entity, bank portal, role, last login, last approval, employment status, manager, MFA status, review decision and disablement date while the full policy keeps the legal, technical or scheme background.

The business should define an escalation trigger around dormant banking users by privilege level, days inactive and time from review trigger to disablement. Reporting becomes useful only when a threshold leads to a named decision, owner and deadline rather than adding another number to a monthly pack.

Repeated overrides should not be normalised. If the same workaround appears month after month, the issue is no longer exceptional; it is evidence that the timetable, data model, authority design or bank setup needs to change.