Maker-checker without grinding the branch to a halt

Maker-checker is one of the oldest controls in banking and one of the most reliably misapplied. The principle is sound: the person who initiates a transaction should not be the person who authorises it. The implementation usually goes wrong in one of two directions, and both are expensive.

The first failure is applying it everywhere. Every field change, every address update, every small transaction routed through a second person. This looks rigorous and produces the opposite of rigour. When a supervisor has three hundred approvals in a queue at close of business, they stop reading them. They approve in bulk, by rhythm, glancing at nothing. You now have a control that produces an audit trail asserting review took place while providing no actual review — which is worse than not having it, because it manufactures false assurance and lets everyone stop worrying.

The second failure is applying it by role rather than by risk. A senior teller's ten-dollar correction requires approval; a system administrator's change to interest configuration doesn't, because administrators are trusted. The largest exposures in most core banking systems are not transactions at all. They are configuration: rate tables, fee structures, limit parameters, GL mappings, user permissions. These change rarely, are almost never queued, and can move far more money than any single teller.

Getting it right starts with a boring exercise: list what can actually be done in the system, and for each thing ask what the worst plausible outcome is if it were done maliciously or in error. Then apply the control where that answer is serious. You usually end up with far fewer approval points than the current configuration, and several new ones nobody had thought about.

Three design details make the difference between a control people use and one they route around.

Approval needs enough context to be a decision. A queue entry saying that user AMOYO modified customer 44821 is not reviewable. The approver needs the before and after values, who initiated it, why — a mandatory reason, in free text, that appears in the queue — and any related recent activity by the same user. If a checker has to open three screens to understand what they are approving, they will stop opening them.

Segregation has to be real. If the same two people are maker and checker for each other all day, you have a mutual arrangement, not a control. Rotation, and hard rules preventing self-approval through any indirect path — including a supervisor approving something they instructed a junior to enter, which is the most common way this is defeated in practice and the hardest to detect from logs.

And there has to be a break-glass path with teeth. Someone will need to act outside the normal flow: an emergency, an absent approver, a customer in the branch. If the system offers no legitimate exception, staff invent one — usually a shared password. So provide it, make it require a higher authority, make it demand a written reason, and put every use into a report a real person reviews the next morning. A break-glass facility nobody reviews is just a back door with a form attached.

The measure of whether you have this right is not the number of approval points configured. It is whether checkers reject things. If your rejection rate across a quarter is effectively zero, your control is decorative — either the thresholds are set so low that nothing meaningful passes through, or approvers are rubber-stamping. Both need fixing, and you will not discover either from the configuration screen.

Apply it where the money is. Give the checker something to actually check. Then it works.