Maker-Checker in Banking Systems: Why Four Eyes Beat Two
Maker-checker — the four-eyes principle — is banking's oldest control, and the one most software only pretends to enforce. What maker-checker means in onboarding systems, where it must apply, and how to tell enforcement from policy.
Ask a banker to name the industry's oldest control and you will hear some version of the same answer: no one acts alone. One person prepares, a different person approves — the maker-checker principle, also called four-eyes or separation of duties. It predates computers by a century, it appears in every operational risk framework and central bank guideline on internal controls, and it survives because it addresses both halves of the risk equation at once: fraud (one person cannot push something through alone) and error (a second pair of eyes catches what the first missed).
The interesting question in 2026 is not whether banks believe in maker-checker — they all do. It is whether their software enforces it, or merely assumes it. This article covers what maker-checker means concretely in banking systems, where it must apply in account opening, and how to tell real enforcement from a policy document with a login screen in front of it.
What is maker-checker, precisely?
Maker-checker is a control pattern with three requirements, all of which must hold:
- Two distinct actions — a make (create, edit, prepare, recommend) and a check (review, approve, publish, authorise) — with the checked thing taking effect only after the check.
- Two distinct people — the checker must not be the maker of the thing being checked. Not "should not": cannot. The system must compare identities and refuse.
- A record of both — who made, who checked, when, and what exactly was checked, preserved immutably.
The third requirement is the one that turns a workflow feature into a control: without the record, the bank cannot demonstrate the control operated — and a control that cannot be evidenced does not exist, as far as an auditor is concerned. That evidential thread runs through everything in audit-ready account opening.
Where does maker-checker apply in account opening?
Two places — one obvious, one routinely missed.
The obvious one: application decisions
No application should be approvable by the person who prepared or shepherded it. In a staged review workflow — submission, compliance check, document verification, internal review, approval — the stages naturally distribute across roles: a compliance officer clears screening, a verifier checks documents, a reviewer completes the internal assessment, an approver decides. Role-based queues make the separation structural, and decision records ("approved by, with reason") make it evidenced. The corporate world has run on this for decades — it is the same logic that requires a board resolution rather than one director's say-so.
The missed one: configuration — especially forms
Here is the modern blind spot. Banks now change their onboarding behaviour not by writing code but by editing configuration: application forms, document checklists, product definitions, routing rules. A no-code form builder puts real power in business hands — which means the form itself is now something one person could quietly change. Remove a declaration question, drop a document requirement, loosen a validation — and every application thereafter inherits the weakness.
Configuration therefore needs maker-checker exactly as transactions do: the person who last edited a form draft must be unable to publish it. A second, differently-permissioned person reviews and publishes; the attempt by the editor is refused by the system, not discouraged by policy. Published versions are immutable and numbered; in-flight applications stay pinned to the version they started on; and the version history records who edited and who published, forever.
This is how BAOS enforces it: form-builder permissions split editing from publishing, the platform rejects a publish by the draft's last editor outright, and every published form version is immutable with its maker and checker on the record — the same discipline for configuration that the six-stage workflow applies to the applications themselves.
How can you tell enforcement from theatre?
Five tests, runnable in any product demo:
- Try to self-approve. Log in as the person who edited the form (or prepared the review) and attempt the approval. The only acceptable outcome is a refusal by the system — not a warning, not a convention.
- Check where the rule lives. If the answer is "we train staff not to" or "the process document says", the control is policy, not enforcement. If the answer is "the service compares the checker's identity to the maker's and rejects the request", it is real — and it should hold even for administrators.
- Ask what the checker actually sees. A checker approving blind is theatre. For forms: a preview of the draft exactly as applicants will see it, plus what changed. For applications: the full record — answers, documents, screening coverage — on one screen.
- Ask for the evidence, later. Pick an old approval and ask the system to show maker, checker, timestamps, and the exact content checked — including, for forms, the version as it was then. If reconstructing that takes an engineer, the control fails its audit the same way.
- Probe the emergency path. Every institution has a "we needed it out on Friday night" story. The right answer is an expedited second person, never a bypass — and the record should show expedited approvals distinctly.
Doesn't maker-checker slow everything down?
Only when it is implemented as bureaucracy rather than workflow. The slow version routes everything through one overloaded approver with no visibility. The fast version distributes checks across roles with queues, SLA timers and escalation — so the second pair of eyes is measured in minutes, and the institution can prove it. Speed and control are not the trade-off they are reputed to be; unmeasured workflow is the actual enemy of both.
Separation of duties is ultimately an architectural property: either the system makes one-person action impossible and records everything, or the bank is relying on good intentions at scale. For how this control fits the wider platform decision — workflow, audit, configuration governance — see the bank account opening software guide, or book a demo and run the five tests above against a live system.
