How Segregation of Duties Actually Works in Payments
"Maker/checker" is usually explained as a rule — one person can't do everything. What it actually is is a chain of independent roles, each with its own record of who acted, enforced twice: once by your own workflow, and again by the bank.
Initiator (maker)
Creates the payment instruction — beneficiary, amount, account, date — from a source document or process.
✕ Cannot approve or release their own instruction, even if no one else is available.
Approver (checker)
Reviews the instruction against supporting documentation and authorization limits, then approves or rejects it.
✕ Cannot approve an instruction they initiated, or approve above their own authorized limit.
Releaser
Submits the approved instruction to the bank — the step that actually moves money, on some setups merged with the approver's.
✕ Cannot release an instruction they initiated, and on a well-controlled setup, cannot release one they alone approved.
The flow, stage by stage
Initiation
MakerThe instruction is created: beneficiary details, amount, currency, value date, and a reference back to the underlying invoice, payroll run, or contract.
Control: The system records who created it and when — this identity can never also approve or release it.
Approval
CheckerOne or more approvers review the instruction against the supporting document and the account's authorization matrix (who can approve up to what amount).
Control: Approval limits are enforced per account, not just per user — a checker's limit on one account doesn't carry over to another.
Release
ReleaserThe approved instruction is submitted to the bank over the live channel (host-to-host, EBICS, bank portal) — this is the step with no undo.
Control: Many banks enforce a minimum number of distinct signatures at this step independently of what your TMS already required.
Bank-side check
BankThe bank validates the instruction against its own mandate on file — who is authorized to sign for this account, and under what combination.
Control: This is a second, independent enforcement of segregation — your internal workflow and the bank's mandate should agree, not just coincidentally match.
Where it quietly breaks
The rule fails most often not because it's missing on paper, but because one of these combinations exists in practice.
Same person initiates and approves
A fabricated or altered payment can go straight through with no independent review.
Same person approves and releases alone
One person's judgment call is the only thing standing between a mistake (or fraud) and the bank actually moving the money.
Approver can edit the instruction after review
What was approved and what gets released can silently diverge — approve should freeze the fields that were reviewed.
One person holds the only bank token or mandate
No practical checker exists even if the workflow says there should be one — a paper control with no real second signature.
Map who currently holds which of these roles on your own accounts with the Access & Approval Matrix — it flags it directly if the same person can initiate and approve.