Article map
Maker-checker is commonly described as “one person prepares and another approves.” That principle is valuable, but two names in an audit log do not guarantee independent control. The checker may not see the relevant changes, may share another conflicting role, may approve after execution or may rely on the maker's explanation without evidence.
Effective segregation of duties requires a view of the entire transaction and access lifecycle. It identifies incompatible capabilities, provides approvers with meaningful information, restricts privileged administration and monitors circumvention. This article explains how to build that model.
1. Define the risk addressed by each role
Role design should begin with the adverse action to prevent: create a false obligation, redirect a beneficiary, prepare an unauthorised payment, release it, conceal it in reconciliation or grant access to do so.
Each control should map to an assertion. Commercial approval confirms obligation; beneficiary approval confirms destination; payment approval confirms amount and timing; bank release confirms authorised execution; reconciliation confirms outcome.
Duplicating the same superficial approval adds delay without addressing a new risk.
2. Map the complete capability chain
The capability map should include source creation, vendor or beneficiary maintenance, transaction preparation, validation override, approval, release, cancellation, reconciliation, accounting, reporting and user administration.
Conflicts often arise across systems. A user may lack payment approval in the treasury platform but hold bank-portal signing authority. Another may not prepare payments but can change beneficiary data in the ERP.
The segregation model should therefore operate at enterprise role level, not only within one application.
3. Separate master data from transaction approval
A user who can change the payment destination and approve the transaction has a strong conflict. Beneficiary request, verification and activation should be separated from payment preparation and approval.
The same principle applies to bank accounts, instrument terms, counterparty limits and exchange rates. Master-data changes can alter the result of otherwise controlled transactions.
Sensitive changes should be visible to transaction approvers and may require reapproval of affected items.
4. Design approval matrices around risk
Approval can vary by legal entity, account, transaction type, amount, currency, counterparty, urgency and exception. A routine internal transfer within policy may need fewer approvals than a new high-value external beneficiary.
Thresholds should be cumulative where splitting risk exists. The system can detect multiple related transactions below a limit.
Authority should align with legal mandates and bank signatories. Internal approval that cannot produce valid external authority, or bank authority exceeding internal delegation, creates a gap.
5. Give the checker decision-quality information
The checker should see source purpose, beneficiary status and recent changes, amount, currency, value date, account, duplicate alerts, policy checks, supporting evidence and maker comments.
Highlighting changes and exceptions is more useful than displaying every field equally. The reviewer should be able to drill into source data rather than relying on screenshots.
Approval interfaces should discourage rapid blind approval. Batch approval can remain efficient while flagging exceptional lines for individual review.
6. Enforce approval before irreversible action
The workflow should prevent release, settlement, posting or master activation before required approval. Retrospective approval is evidence of review, not preventive control.
Where preapproval is impossible in an emergency, policy should define limited authority, independent confirmation and mandatory post-event review. The exception should be visible and rare.
The system should also invalidate approval when material fields change. Approval belongs to a specific version, not to a record name.
7. Control delegation and absence cover
Delegation should specify role, scope, entity, limit, start and end date. It should require approval and be visible to other reviewers.
Permanent shared delegate arrangements can undermine independence. The system should prevent a user from acting as both maker and delegated checker for the same item.
Absence procedures should be planned before urgent periods. Pressure created by unavailable signatories is a common reason for bypass.
8. Address small-team constraints proportionately
Small teams may not have fully separate staff for every step. Compensating controls can include CFO approval, independent bank release, central shared-service review, post-transaction reconciliation by finance, restricted transaction limits and automated anomaly monitoring.
The design should document residual risk. “Team too small” is not a reason to allow one person to create beneficiary, payment, bank access and reconciliation without oversight.
Higher-risk activity can be centralised or scheduled when appropriate reviewers are available.
9. Govern privileged administration
Administrators can create users, change roles, alter workflow or access data. Their power can override transaction controls.
Privileged access should be limited, separately approved, logged and reviewed. Production changes should follow change management. Emergency access should expire and be retrospectively assessed.
Where technically feasible, administrators should not approve business transactions. Database-level changes to sensitive records should be monitored.
10. Reconcile internal and bank authority
Bank portals and connectivity channels have their own user and signing models. Treasury should periodically reconcile bank users, accounts, limits and signatory rules with internal roles and authorised mandates.
Departed employees, expired delegates and changed responsibilities should be removed promptly. Dormant access should not remain because it is difficult to recreate.
A payment can be internally controlled but externally vulnerable if bank access is broader than the enterprise model.
11. Prevent credential sharing and proxy approval
Shared credentials eliminate accountability. Authentication should identify the individual and use strong controls appropriate to the risk.
Users should not approve on behalf of another by using their token or password. Where executive support teams prepare information, the authorised approver must still perform the decision and authentication.
Logs should identify anomalous location, device, time and rapid sequential approvals where relevant, subject to privacy and policy.
12. Monitor collusion and circumvention indicators
Segregation reduces single-person risk but does not eliminate collusion. Monitoring can identify repeated maker-checker pairs, unusual approval speed, transactions just below thresholds, repeated override, new-beneficiary payment, after-hours activity and reciprocal approvals.
Indicators require investigation, not automatic accusation. They help direct review toward patterns that formal role design may miss.
Rotation, leave and independent audit can add deterrence and detection.
13. Recertify roles and conflicts periodically
Managers and control owners should review whether users still require roles and whether combinations remain appropriate. Recertification should include internal systems, bank channels and privileged access.
Organisational changes, transfers and project roles can create conflicts even when original access was valid. Event-driven review should supplement periodic certification.
The reviewer should see actual usage. A role unused for a long period may be removed rather than retained “just in case.”
14. Keep an evidence trail of the decision
The record should show maker, checker, time, version, information presented, alerts, comments and final outcome. It should also show rejected and returned actions.
Evidence should distinguish automated approval based on configured rules from human approval. Both can be valid, but reviewers need to know the control mechanism.
A workflow screen showing two usernames without the approved data version is incomplete evidence.
15. Test the control, not only the configuration
Control testing should attempt prohibited combinations and scenarios: maker changing data after approval, user granting self-access, split payments, expired delegation, bank signer outside internal authority and emergency override.
Testing should confirm the business outcome and audit log. Configuration documentation alone may not reveal integration or sequencing gaps.
Changes in systems or processes should trigger regression testing of segregation rules.
Test approval quality, not only approval completion
An approval log can show that control occurred while giving no evidence that the checker examined the relevant risk. Quality testing should sample decisions and confirm that the reviewer saw changed fields, source obligation, policy warnings and authority. The test can compare approval time with the complexity of the item, review comments where an exception existed and verify that rejected items were handled correctly.
Metrics such as median approval time, proportion approved without opening supporting evidence and repeated same-pair approval can identify where workflow has become mechanical. They should be interpreted carefully, but they provide a stronger signal than a simple percentage of transactions with two usernames.
Build controls that remain effective against collusion
No role model can eliminate coordinated misconduct, but the design can make collusion more difficult and more detectable. Sensitive activity can require independent data verification, transaction approval, bank release and post-settlement reconciliation by different organisational lines. Rotation, mandatory leave, analytical monitoring and audit sampling add layers that are not controlled by one pair of users.
The control should also reduce opportunities for threshold gaming. Related payments can be aggregated by beneficiary, obligation, day or requestor when testing approval limits. Reciprocal approval patterns and repeated use of emergency routes should be reviewed. Segregation is strongest when formal roles are supported by evidence and behavioural monitoring.
Practical illustration: two approvers, one unresolved conflict
A company requires one payment maker and two bank signers. The maker cannot approve payments, so the process appears segregated. Review finds that the maker can also change supplier bank accounts in the ERP, while the first bank signer relies on the batch total and does not see beneficiary changes.
The company separates beneficiary activation, adds a changed-account alert to the approval screen and prevents payment release until the change is independently verified. The original dual approval was not useless, but it did not address the most important conflict.
Implementation checklist
Effective maker-checker and segregation should include:
- risk and assertion defined for each approval;
- cross-system capability and conflict mapping;
- separation of sensitive master data and transactions;
- risk-based, cumulative approval thresholds;
- decision-quality information for checkers;
- pre-execution control and version invalidation;
- time-bound delegation and planned cover;
- documented compensating controls for small teams;
- restricted and monitored privileged administration;
- reconciliation of internal and bank authority;
- individual authentication and no credential sharing;
- monitoring for split, reciprocal and unusual approvals;
- periodic and event-driven recertification;
- versioned audit evidence; and
- scenario-based control testing.
Common segregation failures
Common failures include designing roles within only one system, allowing approvers to see only batch totals, retaining approval after data changes, using permanent delegations, excluding administrators from review, leaving former employees active at banks and assuming dual approval eliminates collusion.
Another failure is adding more approvers without clarifying what each should verify. Repeated approval can create diffusion of responsibility rather than stronger control.
Closing perspective
Segregation of duties is a design of independent capabilities, not a count of signatures. It should prevent one person from creating, directing, executing and concealing value while giving reviewers the information and authority required to challenge.
When role conflicts, master data, bank access, administration, versioning and monitoring are connected, maker-checker becomes a meaningful control rather than a procedural formality.
Frequently asked questions
What is maker-checker control?
Maker-checker requires one user to prepare or initiate an action and a separate authorised user to review and approve it before execution.
Why can two approvals still be weak?
Approvers may lack relevant information, hold conflicting roles, share credentials, act under collusion or approve after the transaction. Independence must be designed across access, data, timing and authority.
How should small treasury teams handle segregation?
Use risk-based role design, senior or cross-functional approval, bank-side controls, independent reconciliation, restricted administration and periodic review rather than eliminating segregation entirely.