Maker-Checker Controls That Administrators Cannot Bypass

This is part of the engineering series behind our group pension administration case study. In a procedure document, maker-checker is a sentence: one person prepares the work and another approves it. In software, the control has to survive broad roles, demonstration accounts, emergency access, repeated transitions and a user who happens to hold every permission involved.

The central design choice is that authority and independence are separate questions. A permission answers whether the actor may approve this kind of work. An identity comparison answers whether this actor is independent of the maker. Both must pass. No role, including the broadest administrative combination, changes the second answer.

Why role-based maker-checker is insufficient

Suppose a contribution importer also holds the approval role. A role-only check sees an authorised approver and allows the batch through. The organisation may have assigned both roles for operational coverage, but it did not intend one person to approve their own import. Role membership establishes capability; it does not prove segregation.

GPAS records the maker's identity with the pending object and compares it with the acting user at approval. The check is repeated at the server transition, not inferred from which button the interface displayed. A user with every one of the system's nine roles still cannot approve the contribution batch they imported, check the benefit they calculated or post the payment they created.

This is why the system deliberately has no superuser. Administrative work is split across explicit authorities rather than concentrated in a magic account that bypasses business controls. Somebody can administer users or inspect audit records without acquiring the right to manufacture a complete financial event alone.

The contribution handoff

A contribution batch begins with imported member allocations and exception handling. Importing creates a proposed financial instruction; it does not post member money. Another authorised user reviews the batch, its matching and control totals. Only after that handoff can the entries move from suspense into the employee and employer member accounts.

The batch retains the importer, reviewer, source evidence and posting transaction. Retrying the approval does not create another posting, and rejecting or returning the batch does not erase its earlier state. This gives operations a visible queue and gives audit a chain from the sponsor's receipt through allocation to the balanced ledger event.

The transition is idempotent as well as authorised. If the checker submits again after a network timeout, the application returns the already-created posting instead of approving twice. Segregation answers who may act; idempotency answers how many times the permitted act may take effect. A financial control needs both.

Benefit approval is more than a second signature

A benefit case combines member status, the employee and employer sources, vesting, possible forfeiture and payment instructions. The calculator prepares the result. A checker validates the calculation. A separate payment actor posts the final event. The identity rules apply at each handoff, so collecting roles on one account does not collapse the path.

The workflow also corrects a defect we found in our own build. Beneficiary records, including shares and contingency, were captured at enrolment, while the first death-benefit path still directed payment to the member record. The feature looked present because both enrolment and benefit modules existed. Re-reading the complete principle—death benefits pay eligible beneficiaries—exposed the disconnect, and the payment path was corrected before release.

That finding matters to control design. A maker-checker gate can faithfully approve the wrong business instruction if the object being checked omits the relevant relationship. Four eyes do not compensate for an incomplete domain model. The approval screen must present the evidence and destination that define the actual event.

The clearance certificate is a state transition

A benefit cannot proceed to payment until the required revenue-authority clearance certificate is recorded. We model the waiting period as an explicit state between approval and readiness to pay. There is no payment route with an optional certificate warning and no administrative checkbox that says the document will be supplied later.

Putting the requirement in the transition changes its reliability. Every user interface, background job and future integration reaches the same guard. The procedure document still explains why the certificate is needed, but the application owns the rule that nothing crosses into payment without it.

Forfeiture is posted with payment rather than when the case first appears approved. Until the payment event, the case can be cancelled or corrected. Moving employer money to the smoothing reserve earlier would make a reversible workflow state cause an irreversible financial consequence and create needless compensating entries.

The annual close is the largest maker-checker event

Closing a scheme year classifies members, credits interest, charges fees, records forfeitures and moves the audit fee. The order is financially significant. The first implementation allowed one authorised actor to run the full close, even though the project named maker-checker as a non-negotiable control from the start.

We corrected the contradiction. The requester and executor must be different people, and the executor must also differ from the person who set the declared rate. The close will not complete until the active, vested, termination and smoothing-reserve positions reconcile exactly to the revenue-and-expenditure summary. Authority cannot override the arithmetic gate.

Reopening is a separate exceptional workflow requiring two named senior approvals. It does not reset the year to an unremarkable open state or remove evidence of the earlier close. Reports and later postings may already depend on that boundary, so reopening has to be rarer and more visible than closing.

Rules that price future work also need dual control

Another alignment review found a quieter violation: one person could create a rule version that would govern future fees, vesting and benefits. It was not a direct ledger posting, so the initial maker-checker inventory missed it. Economically, however, changing a rule can affect more money than approving one batch.

A new version now remains a pending draft until a different authorised user approves it. The previously approved rule continues to govern its date range in the meantime. The identity check is the same as the posting checks because the principle is the same: nobody should be able to create and activate a financial instruction alone merely because it is labelled configuration.

Compliance workflows should preserve their own handoffs

The quarterly supervisory return moves through draft, finance update, manager sign-off and submission. Each state identifies the kind of work completed and the actor responsible. Anti-money-laundering threshold events route to compliance on their operating cycle rather than appearing as an optional report somebody has to remember to run.

These workflows are not a generic approval table with renamed labels. Each transition has domain preconditions and evidence. A generic engine can provide consistent mechanics, but the pension domain still defines what must be true before the next state exists.

The evidence objects also have lifecycles. A certificate or source document is stored with a server-generated key and attached to the case that requires it. The transition checks the accepted evidence record rather than trusting a filename typed into a form. Replacing a document produces another auditable action instead of changing what an earlier approval appears to have reviewed.

An approvals inbox must show why the action is safe

The reviewer needs more than an approve button and a total. A contribution approval surfaces control totals, exceptions and source evidence. A benefit check surfaces the selected rule version, source-separated balances, vesting and destination. A close request surfaces reconciliation status and the identities already involved. The interface is shaped around the evidence the transition guard will enforce.

This avoids a common split where the server contains a strong rule but the reviewer cannot tell whether it is satisfied until pressing the button. A refusal should still exist at the boundary, but the approval surface should make the same preconditions legible before the user acts.

Demonstrate the refusal, not only the successful path

For demonstrations, one seeded account can hold all roles so the presenter can reach every screen. The briefing still instructs the presenter to switch identities at the three critical handoffs. The point is not to hide friction. The point is to show the application refusing to let the first actor complete their own work.

That refusal is often the strongest part of a regulated-system demonstration. A dashboard and a calculated figure show capability. A blocked self-approval shows that the operating control survives convenience, broad access and a carefully staged demo.

Audit the principles against every mutation path

The defects above were not found because a unit test failed. They were found by listing the system's own principles and asking where each was enforced. Which paths create money? Which paths change how future money is calculated? Which transitions release a payment? For each one, where is the independent identity check, and what evidence reaches the reviewer?

That exercise also found an outbox that accepted statement-delivery messages without any worker consuming them. The feature passed an inventory—it had a queue and success states—but did not produce the promised external effect. Control review has to follow an instruction through to the side effect, not stop at the point where the application says it was scheduled.

We also test the denials: the maker attempting approval, an authorised but unrelated role reaching the wrong transition, missing clearance evidence, unreconciled close figures and a second submission after completion. Successful paths prove capability. The refusal matrix proves the control has edges.

• Check actor identity as well as role membership at the server transition.
• Include configuration changes that alter future money in the maker-checker inventory.
• Keep regulatory evidence as a required state precondition, not an optional field.
• Make reconciliation a hard gate for close rather than a report reviewed afterwards.
• Trace queued and generated work to its actual consumer or delivery effect.

The takeaway

A strong maker-checker design does not assume roles imply independence. It records the maker, checks the approver's identity, removes the superuser escape hatch and places business evidence inside the state transition. Then it audits every route that posts money or changes future pricing against the same principle. The control works when the most powerful account in the system is still required to hand the work to another person.