What is segregation of duties in treasury?

Segregation of duties (SoD) is the control principle that no single person should be able to complete a sensitive end-to-end process alone — most importantly, that the person who initiates a payment or trade cannot also approve and release it. Splitting these powers means fraud or a serious error requires collusion between people rather than the action of one, which is a far higher bar. In treasury, where the system moves real money, SoD is the foundational control.

Why is segregation of duties critical in treasury systems?

Because treasury systems execute payments and trades — they move money out of the company — which makes them a prime target for both fraud and costly error. A single person able to create a payment, approve it, and change the beneficiary bank details unchecked can divert funds. SoD, combined with approval workflows and audit trails, ensures no individual has that unchecked power, so the system's ability to move money is always subject to a second pair of eyes.

What duties should be separated in a treasury system?

The key separations are: initiating a payment or trade versus approving and releasing it (four-eyes); dealing versus settlement and confirmation; and transacting versus maintaining static/master data such as bank account details and standing settlement instructions. The static-data separation matters as much as the payment one, because changing a beneficiary's bank details is functionally the same as redirecting a payment.

Segregation of Duties in Treasury Systems

Segregation of duties (SoD) means no single person can initiate, approve and release a payment or trade alone. The powers are deliberately split, so that fraud or a serious error requires collusion between people rather than the act of one — a far higher bar to clear. In a treasury system, which exists to move money, SoD is not one control among many; it's the foundational one. Combined with approval workflows, access control and audit trails, it's what keeps the system's power to move funds always subject to a second pair of eyes.

Why treasury specifically

Most systems hold data; a treasury system moves money out of the company. It executes payments, releases trades, and settles obligations. That makes it a prime target for both external fraud (business email compromise, payment redirection) and internal fraud — and it makes ordinary errors expensive in a way that a wrong report never is. The whole point of treasury controls is that no individual should be able to move company funds on their own authority.

A treasury system's defining feature — it moves money — is also its defining risk. Segregation of duties is what stops that feature from being a single point of failure.

The key separations

Three separations matter most:

Initiate vs approve/release. The person who creates a payment or trade cannot be the one who approves and releases it. This is the classic four-eyes control on outgoing money.
Deal vs settle/confirm. The person who strikes a deal shouldn't also confirm and settle it — otherwise a fictitious or off-market trade can be booked and settled by one hand.
Transact vs maintain static data. The person who processes payments shouldn't also be able to change master data — beneficiary bank details, standing settlement instructions, approval limits — unchecked.

Four-eyes approval workflows

SoD is enforced through approval workflows: a payment or trade moves through defined states — created, approved, released — each requiring a different user with the right authority, often with limits (larger amounts need higher or additional approvers). The system must enforce this, not rely on people remembering. A workflow that can be bypassed, or where one person holds every role, is SoD on paper only.

The most under-controlled risk isn't the payment — it's the bank details behind it. Changing a beneficiary's account number is functionally identical to redirecting a payment, but it often lives outside the payment approval flow. So a change to standing settlement instructions or beneficiary bank data must itself be a four-eyes, audited action. Many real payment frauds are a quiet master-data change, not a fraudulent transaction — the payment then looks perfectly normal.

Access control

SoD depends on roles that actually restrict what each user can do — and on there being no super-user who quietly holds all of them. Access should be least-privilege (only what the role needs), reviewed periodically (people change jobs; access lingers), and free of the accumulation where someone ends up able to both create and release because two old roles were never removed.

Audit trail

Every sensitive action — a payment approved, a rate overridden, a bank detail changed — must leave an immutable record of who did what, when. The audit trail is both a deterrent and the means of investigation. A control you can't evidence after the fact is a control you can't prove you had.

What usually goes wrong

SoD on paper only. The policy exists but the system doesn't enforce it, or one person holds every role in practice.
Super-users. An admin account that bypasses every separation "for convenience."
Unguarded static data. Payment approvals are locked down, but changing beneficiary bank details isn't — the actual fraud path.
Access creep. Old roles never revoked, so individuals accumulate conflicting powers.
Uncontrolled emergency access. "Break-glass" access used routinely, unlogged, defeating the whole model.

Split initiate from approve, deal from settle, and transacting from maintaining master data; enforce it in workflow, not policy; guard static data as tightly as payments; and make every sensitive action auditable. That's what lets a system move money safely — the entire reason treasury architecture treats controls as a first-class design concern, not a bolt-on.

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