The maker-checker process: what it is and how to automate it

What is the maker-checker process?

The maker prepares something that matters: a payment, a sanction, a change to a borrower’s bank details, a manual journal. The checker is a different person who looks at it and either approves or sends it back. Until the checker acts, nothing happens.

You will also hear it called the four-eyes principle or dual control. Same idea. The person who creates a transaction should never be the one who authorises it. That single rule catches a surprising number of honest mistakes, and it makes fraud a lot harder.

Where you actually need it

In a lending or fund business, the list is longer than most people expect:

• Credit sanctions, where the analyst prepares and someone with the right limit signs off.
• Disbursements and drawdowns. The person who raised the request shouldn’t release the money.
• Investment committee decisions, prepared by the deal team and approved by the committee.
• Vendor and borrower master data. Bank-account changes are the classic fraud route.
• Limit, rate and policy changes. If it changes a control, the change itself needs a control.
• Manual journal entries, especially the "one-off adjustment" kind.

How it breaks in email and Excel

Picture a Friday evening. An analyst emails a spreadsheet to the credit head with "please approve". The reply comes back from a phone: "Approved." On paper, that’s maker-checker. In practice, three things have gone wrong.

Nothing stopped the analyst from sending it to a colleague who didn’t have the authority for that amount. The approval isn’t tied to the version of the spreadsheet that was reviewed, and that file gets edited again on Monday. And three months later, when internal audit asks for every approval above ₹5 crore last quarter with the approver’s name, somebody loses two days in Outlook search.

None of this is anyone being careless. The tools just weren’t built to enforce the control.

What good automation looks like

When maker-checker runs inside a proper workflow, a few things change:

• The system won’t let a maker approve their own item. You don’t rely on people remembering.
• Approvals route by amount and product to someone whose limit covers it, and escalate above that.
• Committees get quorum rules. Two out of three, or all members, whatever your policy says.
• The checker approves a specific version. If anyone edits it afterwards, it goes back for approval.
• Pending items have an SLA. They don’t sit in someone’s inbox while they’re on leave.
• Every action lands in an audit trail that can’t be quietly edited: who, what, when, and on whose behalf.

Do you need a big system or a custom build for this?

Usually not. Teams traditionally got maker-checker by buying a large core system that has it baked into certain modules, or by asking developers to build approval logic into an internal tool. Both work. Both are slow to change, and your process will change: a new limit, an extra approver, a new product.

A no-code workflow platform is the third route. You set up the form the maker fills in, define the checker roles and limits, and the platform enforces them and writes the audit trail. When policy changes, your ops team updates the setup instead of raising a ticket. That’s how Averoic works, and teams typically go live in a few weeks.

Five questions to test your own setup

• Can a maker ever approve their own item? The honest answer should be "the system won’t let them".
• Does routing follow amount and authority, or whoever happens to be on the email?
• If an approved record changes, does it go back for approval?
• Could you list every approval, approver and timestamp for last quarter in ten minutes?
• Can you see what’s pending right now, and who is sitting on it?

Frequently asked questions