Organisations should ensure that no single person can both initiate and approve the same transaction. The practical control is to split conflicting duties across different roles, enforce approval workflows, and review exceptions regularly. This creates checks and balances, reduces the chance of unauthorized payments, and makes both intentional fraud and accidental errors easier to detect before they become financial misstatements.
How approval and execution rights should be split
The control objective is simple: a person who can authorise a payment should not be the same person who can release, post, or reconcile it without an independent check. In practice, that means separating initiation, approval, and execution into different roles, then making the workflow enforce that separation rather than relying on policy language alone. The stronger the segregation, the harder it is for fraud to hide inside routine processing.
This is a classic checks-and-balances problem, so the design should focus on where a transaction can still be altered, duplicated, rerouted, or suppressed after approval. The right split is the one that removes unilateral control over the full transaction path while still keeping finance operations fast enough to work.
For financial processes, the pattern usually includes a maker-checker model, role-based limits, dual approval for higher-value items, and separate responsibilities for payment creation, approval, and bank release. If one person can both create a vendor, approve the invoice, and trigger the transfer, the control has failed even if a second signature exists somewhere else in the process.
A useful external reference for payment and control expectations is PCI DSS v4.0, PCI Security Standards Council, which reinforces least-privilege access and tighter handling of system and application accounts. For broader financial-sector resilience and third-party control expectations, DORA, Digital Operational Resilience Act is also relevant when payment workflows depend on ICT services and outsourced platforms.
Where payment authority sits inside systems rather than people, the same principle still applies: do not let the same account or workflow path both approve and execute a value-moving action. NHI Mgmt Group’s Lifecycle Processes for Managing NHIs is useful here because approval automation, service accounts, and shared integrations can quietly concentrate power if they are not governed as carefully as human roles.
Where fraud controls usually break down
Segregation of duties fails most often at exceptions, not in the normal workflow. Temporary access, emergency overrides, small-value thresholds, shared inboxes, delegated approval rights, and manual journal entries can all become back doors if they are not logged and reviewed separately from the standard payment path.
The other common failure is assuming that dual control exists because two names appear on a policy or screen. In reality, if one operator can prepare the transaction, control the destination details, and influence the approver, the independence is only cosmetic. Fraudsters look for exactly those gaps because they preserve the appearance of process discipline while removing the substance.
That is why approval evidence, execution logs, and exception review need to be tied together. If the approver is never shown the underlying invoice, vendor change, or bank-account change, the control may satisfy form but not reduce fraud risk. If exceptions are frequent, the organisation should treat them as a design issue, not an admin inconvenience.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
PCI DSS v4.0 and DORA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | Limits who can create, approve, or release payment actions. |
| 8.6 — System and Application Accounts and Authentication Management | Controls shared or automated accounts that can bypass human approval separation. | |
| Recommendation — Restrict payment-system access to only the roles needed for each transaction step. Tighten authentication and use of system accounts that can execute payment workflows. | ||
| DORA | ICT-3 — ICT Third-Party Risk Management | Payment workflows often depend on external systems that can affect approval and execution controls. |
| Recommendation — Assess outsourced payment dependencies for control gaps that weaken segregation of duties. | ||
Practitioner Guidance
What to verify: Check whether the approver can independently validate the business purpose, beneficiary, and amount, and whether the executor can alter any of those fields after approval. If the answer is yes, the segregation is not real enough for a fraud control.
Decision rule: If a role can create and release value-moving transactions, treat that role as incompatible and redesign the workflow before expanding transaction limits or adding more exception handling. If you cannot separate people, separate privileges and require compensating approval from a genuinely independent control owner.
What practitioners underestimate: The highest risk often sits in “small” exceptions, temporary access, and delegated approvals because they bypass the cleanest control path. Those cases deserve more review than routine transactions, not less.
Practitioner takeaway: The goal is not just to add a second signature, but to make sure no one person can complete the whole fraud chain from initiation to release.
Related resources from NHI Mgmt Group
- How should organisations design access governance to reduce employee fraud in financial systems?
- How should financial organisations reduce fraud risk in stablecoin payment flows?
- Who should own the balance between chargeback risk and approval rates in card-not-present fraud management?
- Why do device approval flows reduce password risk, and where can they still fail?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
