Maker-checker, also called the four-eyes principle, means the person who prepares a transaction (the maker) cannot be the person who authorises it (the checker). A second person, with the authority to decide, reviews exactly what will be written before it takes effect, and the system records who did each. In a finance company the acts worth gating are the ones that move money out, change the books by hand, undo something already done, or change what the institution knows about a customer: loan approval and disbursement, manual journals, reversals, write-offs, period close and reopen, and client activation. Who decides is a combination of role, branch and number of people, and the maker is never one of them.
What maker-checker is, and what it is not
Maker-checker is a preventive control. The transaction does not happen until the second person agrees. That separates it from detective controls, such as a supervisor reviewing yesterday’s transactions or an internal audit sample, which find a problem after the money has moved. Both are needed, but only the first stops a payout.
It is also not the same as a second login. If a branch manager approves a disbursement by walking to the officer’s desk and typing on the officer’s session, the system records one person doing both halves. The control exists only if the system can tell the two people apart and refuses to let one of them act twice.
Four properties of a control that works
1. The maker cannot approve their own item, and the system enforces it. A written policy that says “do not approve your own loans” is a hope. The system must refuse the attempt. It also depends on each user account belonging to one person. If a colleague can raise an item under your login, the system cannot tell the two of you apart, so signing in must need more than a password that can be shared.
2. The checker sees what they are signing. The approver must see the actual entry, amount, account and borrower that will be written, not a summary line in an email. And nothing should be written until they approve. A journal that posts first and is “approved” later has been reviewed, not authorised.
3. The decision is recorded and cannot be changed. Who approved, when, and under which rule should be stored beside the record and never edited. When an auditor asks why a write-off went through, the answer should be a record, not a recollection.
4. The world is checked again at the moment of approval. An item raised on Monday and approved on Thursday should be validated on Thursday. The period may have closed, the account may have been deactivated, or the borrower’s other loan may have gone into arrears in between.
What to gate
Gate an act when a mistake or a fraud in it is expensive and hard to undo. A reasonable starting list for a lender:
| Act | Why it is gated |
|---|---|
| Loan approval | Commits the institution to lend; sets the amount and the price |
| Disbursement | Money leaves the institution |
| Undoing a disbursement | Reverses a payout and its posting after the event |
| Manual journal entry | The one posting a person types by hand, and the most abused |
| Reversal of an entry or a receipt | Changes figures that staff and customers have already relied on |
| Write-off | Removes a receivable and moves the result |
| Till close with a difference | Cash short or over is money unaccounted for |
| Period close and reopen | Closing locks the month; reopening lets figures change after reporting |
| Client activation | The point at which a customer’s identity checks are accepted |
| Release of collateral from a live loan | Gives up security while money is still owed |
| Reactivating a dormant savings account | Nobody has watched the account for months, which makes it a target |
What not to gate
Every gate costs a person’s time and delays a customer. Gate too much and approvers start clicking Approve without reading, which is worse than no gate, because it looks like a control on paper.
Routine, high-volume acts that are already checked another way usually do not need a second person each time. A counter receipt is checked by the till count at the end of the day and by the receipt’s own gap-free number. A scheduled repayment is checked by reconciliation of the loan book to the ledger. Put the gate where the other controls do not reach.
Use conditions to keep gates small. A reversal of LKR 500.00 and a reversal of LKR 5,000,000.00 are different risks, so let the amount decide which gate an item goes to.
Who decides
A useful gate answers four questions.
Which permission. The approver must hold a role that allows the decision: a branch manager for a branch-level disbursement, the finance manager for a manual journal.
Which office. A branch manager in Kandy should approve Kandy’s items, not Galle’s. The rule should follow the office of the record being approved, not the office of whoever happens to open the queue. For some acts, a regional office should also be able to decide for the branches under it.
How many people. Most gates need one approver. Some deserve two of a group: for example, two of the three managers who can approve at a branch. Two approvals should mean two different people.
By when. A deadline makes sure an item does not sit unseen. It should remind someone, in working days that respect the branch’s holidays, and it should never approve anything by itself. Silence is not consent.
An example policy, with fictional amounts, for disbursements:
| Amount | Who decides |
|---|---|
| Up to LKR 500,000.00 | One manager at the loan’s branch |
| Above LKR 500,000.00, up to LKR 2,000,000.00 | One manager at the branch or the region above it |
| Above LKR 2,000,000.00 | Two managers at the branch or the region above it |
The amounts and the number of levels are the institution’s decision. What matters is that the rule is written in the system, not in a circular that staff are expected to remember.
Where maker-checker fails
- Shared credentials. One manager’s password known to three officers makes every approval theirs. Mandatory second-factor sign-in on each person’s own device makes this much harder.
- Approvals outside the system. A manager replying “OK” on a messaging app is not a record the auditor can rely on. The approval must happen where the transaction is.
- Posting before approval. If the entry is written first and “confirmed” later, the control only detects.
- Editing after approval. If an approved item can be changed before or after it posts, the approval covered something else.
- Rubber-stamping. Too many gates, or gates with no information on them, train approvers to stop reading.
How Fused handles this
In Fused, each institution draws its approval flows on a visual canvas, one per event. A flow can branch on the item’s own fields, such as the amount, compared as an exact decimal, and ends either with an outcome or at a gate. See approvals and controls.
- A gate states who, how many and by when. Who is a permission plus an office rule, judged against the record’s office: someone at the record’s own branch, someone at that branch or an office above it, or anyone. How many is a number of distinct people, such as 2 of 3 managers at the branch. The deadline is counted in the branch’s working days and sends reminders. It never decides.
- The raiser cannot approve. The person who raised an item is refused as its approver. A decision is recorded once per person per gate and cannot be edited. Any rejection settles the gate.
- Nothing is written at the gate. A manual journal is posted only when the last approval arrives, in that approval’s own transaction, and its conditions are checked again at that moment. A rejected entry leaves no voucher number behind.
- Gated events include client activation, loan approval and disbursement, manual journals, reversals, receipts, period close and reopen, holidays applied to signed schedules, savings reactivation and collateral release. An event with no flow drawn is not gated, so each institution decides where its gates are.
- One inbox per person lists what is waiting for them, and each record’s history panel shows who decided and when, read from the hash-chained audit trail.
- Sign-in needs an authenticator app for every staff member, and roles are scoped by office: the whole institution, one branch, or a branch and those below it.
Two limits, stated plainly: Fused does not have approver groups, voting committees, a separate authority-matrix table or delegation to a substitute today. Thresholds are drawn as conditions on the canvas.
To see an approval flow drawn around your own policy, book a walkthrough.