VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Segregation of Duties | Why One Person Should Not Control an Entire Banking Transaction

HOW BANKING WORKS · OPERATIONAL BANKING 54

A banking transaction becomes dangerous when the same hand can create it, approve it and hide the evidence.

Segregation of duties breaks one powerful role into several independently controlled steps.

The control is simple in principle: the person who initiates a sensitive transaction should not usually be the same person who independently approves, settles and reconciles it.

This article continues Batch 14 under How Banking Works.

The quick answer

Segregation of duties reduces the chance that one error, one dishonest employee or one compromised account can complete an entire high-risk transaction without independent challenge. It separates incompatible responsibilities so that control depends on more than one actor, system entitlement or record.

The control begins with one uncomfortable assumption

A bank cannot design itself on the assumption that every authorised employee, system account and process will always behave correctly.

People make mistakes. Passwords are stolen. Managers can be pressured. Insiders can collude. Software can mis-route authority. The control architecture therefore assumes that a sensitive action should need more than one independent condition before value leaves the bank.

authority should be sufficient to do the job, but insufficient to do the whole dangerous job alone.

Maker-checker is the simplest visible form

In a maker-checker process, one person prepares or initiates the transaction. Another reviews and approves it.

The checker should not merely click approval. The role exists to challenge the transaction: beneficiary, amount, supporting documents, authority, limits and unusual features.

If the checker becomes a ceremonial second click, the organisation has two names but only one real control.

The full transaction chain contains more than maker and checker

  1. Initiation: someone creates the instruction.
  2. Approval: someone independently authorises it.
  3. Execution or settlement: the system or operations team releases value.
  4. Recording: the ledger reflects the event.
  5. Reconciliation: another control proves the event matched external or independent records.
  6. Review: exceptions and unusual patterns are investigated.

Different banks split these steps differently. The principle is that no one actor should control all states needed to create value, release it and conceal the result.

Why reconciliation should remain independent

If the same person who moves money also reconciles the account, they can potentially hide a discrepancy by manipulating both the transaction and the evidence used to detect it.

Independent reconciliation creates a separate witness.

Read Bank Reconciliation.

A simple payment example

A treasury employee prepares a S$5 million payment to a supplier. A second authorised officer confirms the beneficiary, contractual support and amount. The payment engine releases the transaction only after both valid approvals. A separate operations team later reconciles the bank statement and ledger.

One person can make a mistake at one stage. The control system asks another independent stage to catch it before the entire chain completes silently.

Segregation protects against fraud as well as error

An employee who can create a beneficiary, initiate a payment, approve it and alter the reconciliation record possesses an end-to-end fraud capability.

Splitting those rights means an insider needs collusion, compromised credentials or another control failure to complete the fraud. That does not make fraud impossible. It raises the number of independent barriers that must fail.

Access rights are the digital form of segregation

Modern banks enforce segregation partly through identity and access management. System roles determine who can create customers, change limits, initiate trades, approve payments, alter reference data or release code.

Good policy is useless if the software grants incompatible entitlements to the same user.

Periodic access reviews therefore ask whether employees still need the rights they were given and whether conflicting permissions have accumulated over time.

Privilege should follow the job, not the person’s status

A senior executive does not automatically need unrestricted technical access. Broad privilege creates concentrated operational risk.

The better principle is least privilege: give each user the minimum access needed for legitimate duties, then add stronger approval for exceptional actions.

Temporary access can be safer than permanent access

Some tasks require unusual privileges during a migration, incident or maintenance window. Granting that access permanently creates unnecessary exposure.

Time-limited privileged access, documented reason and post-use review can reduce the chance that emergency permissions become invisible normal permissions.

Collusion is the main human failure boundary

If maker and checker agree to commit fraud together, simple role separation can fail. Banks therefore add other controls: surveillance, transaction monitoring, mandatory leave, rotation, independent audit and anomaly detection.

Segregation lowers single-person risk. It does not remove coordinated misconduct.

Small teams create a practical problem

A small branch or specialist team may not have enough people to split every duty perfectly. The bank then needs compensating controls.

  • higher-level independent review;
  • system-enforced limits;
  • centralised settlement;
  • daily exception reporting;
  • independent reconciliation by another unit;
  • more frequent audit.

The goal is not organisational symmetry. It is to prevent one unchecked path from controlling the full transaction.

Emergency override creates another edge case

During a major incident, normal approval chains may be unavailable. A bank can need an emergency route to release critical payments or restore systems.

Emergency authority should therefore be designed in advance: who can invoke it, under what conditions, what limits apply and what independent review follows.

Otherwise resilience becomes an excuse to bypass the very controls designed to protect the bank.

Developers should not silently approve their own production changes

Segregation applies beyond money movement. A developer who writes code, deploys it to production, changes access rights and validates the result without independent review holds a powerful end-to-end capability.

Code review, change approval, controlled deployment and independent testing apply the same banking principle to software.

Credit approval also needs independent challenge

A relationship manager is rewarded for serving customers and originating business. A credit-risk function is expected to challenge risk independently.

If one person controls both sales pressure and final risk approval, incentives can collapse into one direction.

This connects segregation of duties to How Banks Decide Whether a Borrower Can Repay.

Trade capture, valuation and settlement should not become one closed loop

In markets businesses, front office executes trades. Independent functions can confirm transactions, value positions, manage collateral and reconcile settlement.

This separation makes it harder for a trader to create a false trade, assign a false value and suppress the settlement break alone.

Segregation becomes weaker when everyone shares one administrator account

Shared credentials destroy individual accountability. If ten people use the same powerful account, the audit trail cannot reliably show who performed an action.

Strong control requires attributable identity: the bank should know which person or service account performed each privileged action.

Audit trails are the memory of segregation

Role separation works best when the system records who initiated, who approved, when each action occurred and what changed afterward.

Without reliable logs, the institution may have segregated roles operationally but be unable to prove the control operated.

A control can become performative

A maker sends the checker a message saying “please approve urgently.” The checker trusts the maker and clicks without inspecting the evidence. Formally, two people participated. Substantively, one person made the decision.

Good segregation therefore depends on independence of judgement, not just separate usernames.

The Basel control principle is broader than one transaction

The Basel Core Principles require banks to maintain adequate internal control frameworks and independent control functions. Segregation of duties is one practical expression of that wider governance architecture.

Operational-risk guidance also emphasises a control environment able to identify, assess, monitor and mitigate failures in people, processes and systems.

Four misconceptions to remove

MisconceptionBetter model
“Two approvals automatically mean strong control.”The second approver must independently inspect evidence rather than provide a ceremonial click.
“Segregation is only for payments.”Credit, trading, technology changes, access rights, accounting and reconciliation all use the same principle.
“Role separation eliminates insider fraud.”It reduces single-person capability but collusion and credential compromise still require other controls.
“Senior staff should have broad access.”Privilege should follow job need, with stronger controls for exceptional authority.

A mastery test

  1. Which duties in a sensitive banking transaction should not normally sit with one person?
  2. Why must reconciliation remain independent from transaction execution?
  3. How does access management enforce digital segregation?
  4. Why does collusion remain a failure boundary?
  5. What compensating controls can help when a small team cannot separate every duty?

If those answers connect, segregation of duties becomes visible as engineered distrust used constructively: the bank does not accuse every employee of wrongdoing; it simply refuses to make one unchecked person the single point through which money, authority and evidence can all pass.


Continue through operational banking

Source note: Basel operational-risk and internal-control references were checked on 4 September 2026. This article explains the control principle; actual approval and access requirements depend on the institution, activity and jurisdiction.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading