Access Management and User Provisioning in Treasury Systems

In a treasury system, access management is a first-order control, not IT housekeeping. The system exists to move money, so deciding who can do what inside it is deciding who can create, approve or release a payment, or change the bank details behind one. Get it wrong and the tidiest segregation of duties design in the world is fiction, because it assumes roles are defined correctly and assigned to the right people — which is exactly what access management is supposed to guarantee.

Access is the layer under everything else

In eighteen years across SAP FI, treasury and risk systems, the pattern is consistent: teams design segregation of duties carefully, then treat the access model underneath it as an afterthought. That's backwards. SoD says the person who initiates a payment can't approve and release it — but that separation is only real if the system actually restricts each person to their role, and if nobody has quietly accumulated both. Access management is the mechanism that makes the separation true. Without it, SoD is a policy document, not a control — which is why this article is about the layer beneath the companion control: how you grant, shape and remove the rights that SoD then divides up.

Role-based access control and least privilege

The foundation is role-based access control (RBAC). Instead of switching permissions on user by user — a path that produces a landscape nobody can reason about within a year — you define roles that bundle the rights for a job: cash management, payment initiation, payment approval, static-data maintenance, reporting. A person is assigned the role matching what they do and inherits exactly its rights.

RBAC is paired with least privilege: each role carries the minimum the job needs, and nothing more. The instinct to grant a bit extra "so they're not blocked later" is how access bloat starts. If someone needs more, that's a role change with its own trail — not a quiet grant no one remembers making.

"

Every access right you grant "just in case" is a control you'll have to explain to an auditor later — and won't be able to.

Done well, RBAC makes access reviewable: you can look at a role and know what it permits, and look at a person and know which roles they hold. That legibility is the whole point — and it's what per-user permission grants destroy.

The joiner–mover–leaver lifecycle

Access isn't a thing you set up once; it's a lifecycle, and provisioning is how you manage it. There are three moments:

• Joiner. Someone arrives and needs the roles for their job — granted deliberately, at least privilege, not copied wholesale from whoever sat there before.
• Mover. Someone changes role. This is the dangerous one. The new access gets added because the person needs it to work; the old access almost never gets removed, because nothing forces it and no one is watching. Over a few moves, a person accumulates rights they no longer need — and eventually holds a combination that breaks segregation of duties, like being able to both create and release a payment because two old roles were never revoked.
• Leaver. Someone departs and their access must be promptly de-provisioned. An account that outlives its owner is a live credential with no accountable human behind it.

Orphaned accounts from leavers and accumulated rights from movers are among the most common findings in any access audit. Both are provisioning failures, and the mover case is the quiet killer: nothing breaks when access is left behind — it just sits there until an audit or an incident makes it visible.

Privileged and administrative access

Not all access is equal. Privileged and administrative accounts — the ones that can change configuration, alter roles, or reach beyond a normal user — can rewrite the rules, so they need tighter control than everything else: few, individually attributable rather than shared, granted narrowly, logged, and reviewed more often than ordinary access. A shared admin login "for convenience" is the fastest way to make your entire access model unprovable, because you can no longer say who did what with it.

Periodic access recertification

Even with good provisioning, access drifts — so you check it deliberately. Access recertification is a periodic exercise where someone accountable — usually the manager or role owner, not IT — re-confirms who holds what and explicitly approves or revokes it, on a defined cycle, because entitlements accumulate faster than anyone notices.

The recertification has to have teeth. A review where everyone clicks "approve" to clear the queue is theatre. The value is in the revocations — the access someone looks at and says "they don't need that anymore," which is precisely the accumulated-mover access that would otherwise sit there causing a problem later.

Authentication: the front door

Everything above governs what a user can do; authentication governs whether the right person is behind the login at all. Single sign-on (SSO) centralises identity so access follows one governed source rather than a scatter of local accounts, and multi-factor authentication (MFA) raises the bar on a stolen or guessed password. For a system that moves money, MFA — especially on privileged access — is a baseline, part of the same security posture that guards against payment fraud. Strong internal roles are worth little if the front door opens to anyone with one leaked password.

Docs–vs–reality

Here's what actually happens. At go-live, access is beautiful. Roles are defined, least privilege is honoured, SoD conflicts are checked, the system of record has clear owners and the access matrix is a thing of pride. Everyone signs off.

Then time passes. Movers keep old rights alongside the new. Leavers linger for weeks because de-provisioning depends on someone remembering to raise a ticket. A "temporary" admin grant becomes permanent. The recertification goes unrun, or gets rubber-stamped. Two years in, the elegant model has quietly rotted into a mess where several people can do things the SoD design swore they couldn't — and no one notices, because nothing breaks. It just erodes, silently, until an audit surfaces it or a fraud exploits it.

The lesson I keep relearning: provisioning is a lifecycle, not a launch task. The go-live access model is the easy part. Keeping it true through every joiner, mover and leaver — that's the actual control, and it's the part that gets no attention until it's the finding on an audit report.

Define access through roles at least privilege; provision it across the full joiner–mover–leaver lifecycle, treating the mover case as the risk it is; hold privileged access to a higher standard; recertify on a cycle that actually revokes; and put SSO and MFA on the front door. Do that and segregation of duties has firm ground to stand on. Skip it and the whole treasury architecture's control layer rests on assumptions that stopped being true long ago.

Part of the Treasury Systems Architecture guide. See also segregation of duties in treasury systems and the reference architecture. The newsletter sends one finance-systems pattern every two weeks.