![What is the maker-checker process? How dual approval works [UPDATED]](https://243133756.fs1.hubspotusercontent-na2.net/hubfs/243133756/xtrm-hero-maker-checker.jpg)
What is the maker-checker process? How dual approval works [UPDATED]
One person prepares a payment. Someone else approves it. It sounds almost too simple to matter, which is exactly why teams underestimate it.
The maker-checker process, also called the four-eyes principle or dual approval, is one of the oldest controls in finance. No single person can both create a sensitive transaction and release it. That one rule catches honest mistakes, like a misplaced decimal or a payment sent to old bank details, and it makes fraud harder, because a single bad actor can no longer finish the job alone.
This guide covers what the process is, how a typical workflow runs, where it helps and where it can slow you down, and how approval policies bring it into a payout platform.
Key takeaways
- One person initiates, a different person approves. That separation is the whole control.
- It catches errors and makes fraud harder, because one person can no longer complete a sensitive transaction alone.
- Thresholds keep it practical. Small, routine payments can move with lighter review while large ones get more scrutiny.
- The approval record matters as much as the approval, since it is what you show an auditor.
- The control only works if the system enforces it. If someone can approve their own request, it is decorative.
What is the maker-checker process?
The maker-checker process splits a sensitive action into two roles. The maker prepares or initiates a request, such as a payment, a new payee, or a change to bank details. The checker reviews that request and approves it, rejects it, or sends it back with questions. The two roles belong to different people, and the system should enforce that rather than assume it.
The idea comes from a broader internal control principle called segregation of duties. The US Government Accountability Office's Standards for Internal Control in the Federal Government, known as the Green Book, treats it as a core control activity: dividing key duties and responsibilities among different people to reduce the risk of error, misuse, or fraud. Banks and finance teams have applied the same thinking for decades.
It is worth being clear about what the process does not do. It does not assume your people are dishonest. Much of its day-to-day value comes from catching ordinary mistakes before they become expensive ones. The fraud protection is real, but it is the second benefit, not the first.
How the maker-checker process works
The details vary by system, but most workflows follow the same four steps.
1. The Maker Initiates the Request
The maker creates the transaction or change and attaches what the checker will need to judge it: the amount, the recipient, the reason, and any supporting documents. The maker can start the request but cannot finish it.
2. The Checker Reviews It
The request goes to the checker, usually with a notification. The checker confirms that the details match the source, that the amount is right, and that the request fits company policy. For a large or unusual payment, that can mean checking the recipient's details against an independent source rather than the request itself. That matters most for bank detail changes, a request type fraudsters often target in business email compromise schemes.
3. Approve, Reject, or Escalate
The checker approves, rejects with a reason, or escalates. Many systems route larger amounts to more senior approvers automatically, so the level of review rises with the size of the risk.
4. Execution and the Record
Once approved, the transaction proceeds. The system should log who initiated it, who approved it, and when. That log is what turns the control into evidence: when an auditor asks how a payment was authorized, you can show them rather than tell them.
Key benefits of maker-checker
Fewer Costly Mistakes
A second reviewer catches errors the first person missed, especially the small ones that are easy to make under a deadline: an extra zero, a transposed account number, a payment to last year's bank details.
Fraud Becomes Harder
When one person cannot complete a transaction alone, fraud needs two people to cooperate, which is harder to arrange and easier to spot. It is not a guarantee, but it removes the easiest path.
A Clear Record for Audits
Every approval step leaves a record of who did what and when. That record supports internal reviews, external audits, and the occasional uncomfortable question about a payment that went out months ago.
It Scales With You
As volumes grow, approval rules can grow with them. Thresholds let routine payments move quickly while larger ones get more eyes, so control does not have to mean a queue.
Industry use cases
The principle applies anywhere a single mistake is expensive or hard to reverse.
- Banking and finance: wire releases, loan approvals, and customer onboarding, where one person enters the details and another verifies them.
- Payouts and expense management: one person prepares a payment file or expense claim and another approves it before money moves, often with amount thresholds deciding who reviews what.
- Software and other fields: code review before a deployment follows the same idea, as do second-person checks in healthcare and quality control.
Bringing maker-checker to Xtrm with approval policies
Xtrm calls its maker-checker controls approval policies. They let you designate makers and checkers, the people allowed to approve, for six types of action:
- Creating wallets
- Linking a bank for bank transfers
- Linking a debit card for Rapid Bank Transfer (USA only)
- Transferring funds to a linked bank
- Moving funds from one wallet to another
- Submitting mass payment files
Policies are set at the entity level, and approvers must belong to the entity they approve for. For mass payments, designated approvers receive an email when a payment file is submitted, and the file is not processed until it is approved. You can require a single approver, or add an optional second approver, in which case both must approve, in either order. Policies apply across every program linked to the same entity or wallet, so you do not need to set them up program by program.
Approval Levels for Transfers
For transfers to a linked bank and wallet-to-wallet moves, you can set up to three approval levels by amount, each with its own approvers. For example:
- Level 1: transfers up to $1,000, approved by a team lead
- Level 2: $1,001 to $10,000, approved by a manager
- Level 3: $10,001 to $100,000, approved by a senior leader
The top of the highest active level is also the most anyone can transfer from that wallet, so in this example nothing above $100,000 can leave it. By default every transfer needs approval, but you can set an amount below which transfers skip review, such as $500.
Our help center guide to approval policies has the full configuration details, and our overview of Xtrm's security features covers how approval policies fit alongside other controls.
Best practices for implementation
1. Enforce the Separation in the System
The maker and checker must be different people, and the system should make it impossible to approve your own request. A simple test: try it. If it works, the control is not real. Small teams are where this usually breaks down, because three people under a deadline end up sharing permissions.
2. Set Thresholds That Match Your Risk
Decide which amounts need review and who reviews them. Set the bar too low and approvers start rubber-stamping a flood of small payments. Set it too high and meaningful amounts move unchecked. Revisit the levels when your volumes change.
3. Treat Bank Detail Changes as High Risk
A change to where money goes deserves at least as much scrutiny as the payment itself. Verify changes through a channel the requester did not choose, and consider requiring approval to link new banks. Our guide to payout controls covers this and the other checks that sit alongside dual approval.
4. Keep the Record and Review It
Approval logs are only useful if someone looks at them. A periodic review of who approved what, and how quickly, catches patterns a single approval cannot, such as one approver signing off on everything within seconds. We cover the most common ways these workflows go wrong in our guide to maker-checker workflow mistakes.
Frequently asked questions about maker-checker workflows
What is a maker-checker process?
A maker-checker process is a dual-approval workflow in which one person, the maker, initiates a transaction and a different person, the checker, reviews and approves it before it takes effect. It is also called the four-eyes principle, and it is a practical form of segregation of duties.
Why is the maker-checker process important in finance?
It puts an independent review between a decision and the movement of money. That catches errors, makes fraud harder because one person cannot complete a sensitive transaction alone, and creates an approval record that auditors can review.
How can automation improve maker-checker workflows?
Automation routes each request to the right approver, applies thresholds consistently, sends notifications, and records every step without anyone having to remember to. It also enforces the separation itself, so the rule does not depend on people following it.
Can maker-checker processes slow down operations?
They can, if every payment needs the same level of review. Thresholds help: low-risk, routine payments can move with lighter review, while larger or unusual ones get more scrutiny. Naming a backup approver also keeps things moving when someone is out.
Does Xtrm support maker-checker workflows?
Yes. Xtrm's approval policies let you designate makers and checkers for six types of action, including mass payments, transfers to a linked bank, and wallet-to-wallet moves, with up to three amount-based approval levels for transfers. Our help center guide to approval policies has the full details.
Beyond compliance: Why maker-checker is worth the extra step
The maker-checker process asks for one extra step: a second person looks before money moves. That step catches the mistakes that are easiest to make, removes the easiest path to fraud, and leaves a record you can show when someone asks how a payment was approved. The part that takes real thought is the design, from thresholds that match your risk to a separation the system actually enforces.
If you are setting up approval workflows for payouts or reviewing the ones you have, we are glad to walk through how approval policies would work against your current process.
Last updated: October 12, 2026
Post by The Xtrm Team
Oct 11, 2026, 10:13:44 PM
