Maker-checker controls
Two humans, two entries, one approved transfer. Regulator-mandated for treasury.
By Solomon Ajayi · Free to read, no signup
Your CFO wants to move ₦5,000,000 from your operating cash to the sponsor-bank FBO (to pre-fund expected user deposits). Regulator rules, and your own audit policy, require that no single person can authorize a transfer of this size. One human (the 'maker') proposes the transfer; a different human (the 'checker') reviews and approves. Only on approval does the cash actually move. The maker-checker pattern enforces this at the ledger: the proposal is a JOURNAL ENTRY in a 'pending' state, the approval is a SEPARATE entry from a DIFFERENT actor that finalizes it. Two entries, two actors, full audit trail.
Some money movements are too large to trust to one person and one button. The control regulators mandate for treasury is separation of duties: the human who proposes a transfer cannot be the human who approves it. Maker-checker is how you encode that rule in money rather than in a permissions matrix. The maker drafts the move; a different checker has to sign off before any cash actually leaves.
The trick is to make 'pending approval' a real place money sits, not a flag in application code. When Alice submits, the ₦5,000,000 leaves Operating Cash and lands in a Pending Maker-Checker holding account; the FBO does not move yet. When Bob approves, a second entry drains Pending into the FBO. Two entries, two actors, two timestamps, and the ledger itself records who did what and when. If Bob rejects instead, the second entry simply returns Pending to Operating Cash.
The actor recorded in each entry's metadata is what makes this auditable years later. The two entries carry actor=alice and actor=bob, so the ledger is itself the proof that no single human moved the money. Notice the holding account is modeled as an asset: the cash has left Operating Cash but has not yet reached the FBO, so it has to live somewhere on the books in between, fully balanced, never floating.
Worked example, step by step
Set the stage: ₦10,000,000 in operating cash
Operating Cash starts at ₦10,000,000. FBO and Pending are zero. We need to move ₦5,000,000 of operating into the FBO to pre-fund user deposits.
| Account | Debit | Credit |
|---|---|---|
| Operating Cash (1200) | ₦10,000,000.00 | |
| FBO at Sponsor Bank (1300) | ₦10,000,000.00 |
Standard funding state. Operating Cash debit ₦10,000,000.
Maker (alice@yourco.com) proposes ₦5,000,000 transfer
Alice from treasury opens the internal admin tool. Fills in the transfer form: ₦5,000,000 from Operating Cash to FBO. Hits Submit. Her submission writes an entry into the ledger, but it does NOT touch the destination yet. The amount moves from Operating Cash into a 'Pending Maker-Checker' holding account. Bob (the checker) gets a notification.
| Account | Debit | Credit |
|---|---|---|
| Pending Maker-Checker (1900) | ₦5,000,000.00 | |
| Operating Cash (1200) | ₦5,000,000.00 |
Operating Cash DOWN ₦5,000,000 (earmarked). Pending Maker-Checker UP ₦5,000,000 (held awaiting approval). FBO UNCHANGED. The metadata on this entry records actor=alice@yourco.com so the audit trail shows WHO submitted. Alice CANNOT also approve, the system blocks the same user from making AND checking the same entry.
Checker (bob@yourco.com) approves, finalize to FBO
Bob (a different treasury team member) reviews Alice's request. Verifies it matches the day's funding plan. Hits Approve. A SECOND entry posts: Pending Maker-Checker clears to zero, FBO grows by ₦5,000,000. The transfer is now real.
| Account | Debit | Credit |
|---|---|---|
| FBO at Sponsor Bank (1300) | ₦5,000,000.00 | |
| Pending Maker-Checker (1900) | ₦5,000,000.00 |
Pending Maker-Checker DOWN ₦5,000,000 (cleared). FBO UP ₦5,000,000 (cash arrived). Metadata: actor=bob@yourco.com. The audit trail now shows BOTH entries: Alice initiated at timestamp T1, Bob approved at T2. Two different actors, two different timestamps, ledger-level proof that no single human moved this money. If Bob had rejected, the second entry would have been the inverse (Pending → Operating Cash) returning the funds.
Takeaway
Maker-checker enforces 'two-human approval' at the ledger level. Maker submits an entry that earmarks funds into a pending account; checker (with a different login) approves with a second entry that finalizes to the destination. Two entries, two actors, two timestamps, and the audit trail proves that no single person moved the money. Required by regulators for treasury operations at every licensed institution. The wrong place to enforce it is application code (a single bug bypasses it); the right place is at the ledger schema where the maker's entry literally cannot finalize itself.
Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.