In this guide 6 sections
Ask for four controls: a second person approving each sensitive entry, limits set by role, history nobody can edit quietly, and a recorded reason for every override. Test all four with your own risk scenarios before you sign off the build, and keep the screenshots as evidence for your auditor.
Two person approval means two different people
Maker checker splits a task. One person enters or changes a record, such as a payment instruction, a rate or a customer’s limit, and a second person reviews it and releases it. Until release it stays pending.
A control lives or dies on enforcement. The software must refuse approval by the maker even when the maker also holds a senior role, and it must stop one person from working under two logins. Tie each login to one employee record. Block shared accounts at the counter.
- The maker cannot approve their own entry, whatever their role
- Pending items are visible, but do not post to the ledger
- Rejected items return to the maker with the checker’s note
- Approval applies to edits and deletions, not just new entries
- Checkers see the old and new values side by side
Limits belong to roles, not to people
Define each role’s powers and ceilings. A teller may enter a receipt up to one ceiling, a branch manager may approve up to a higher one, and anything above goes to the credit committee.
Write limits as settings your compliance head can see and change, not as code that needs a developer, and route every change to a limit through maker checker.
Review who holds each role every quarter. Leavers are the second weak spot. A relationship manager moved to operations often keeps the old rights, and nobody notices until an auditor lists the users against the current organisation chart.
- Entry and approval limits by role and by product
- Escalation to a second approver above the ceiling
- Separate roles for creating users and for approving them
- Quarterly list of users by role for review
A history nobody can quietly edit
An audit log should record who did what, on which record, when and from which device, with values before and after, plus approvals, rejections, failed logins and exports.
Ask how the log resists tampering. Options include write once storage, chained hashes that break if a row changes, or copies held by a separate system that the database administrators cannot reach.
A log nobody reads is decoration. Ask for filters by user, record and date, and for a monthly summary that goes to someone outside the team, such as the internal auditor.
- Before and after values for every field changed
- Timestamp from the server, not the user’s machine
- Exports and report downloads logged too
- Retention period agreed with your auditor
Overrides need a reason, a name and a review
Every firm has urgent cases. A borrower waits at the counter, the checker is on leave and the entry is blocked, so a supervisor override is acceptable if it is rare, visible and reviewed.
Make the reason a required field. Free text such as “ok” should be rejected, so offer a short list of reasons plus a note, and send each override to a named reviewer next day.
Count overrides by user and by month. A rising count means the limits or the staffing are wrong, so fix the cause and do not blame the person who used the override.
Test the controls before you sign off
Write scenarios from your own risks. Approve your own entry. Raise a limit without a checker. Delete a log row through the database. Try a leaver’s login the day after exit.
Run them with your compliance head watching, record each result with a screenshot, and ask your internal auditor to review the whole list before go live. This describes controls the software supports and is not legal advice, so confirm the rules for your licence with your own adviser before you rely on it.
Approval and audit control test sheet
Table on a single page, one row per control, with columns for scenario, role used, expected result, actual result, evidence screenshot and signer. Rows cover self approval, limit breach, edit after approval, log tampering, override with no reason, leaver login and report export, plus a blank row for your own risk.
Open a blank worksheet to printQuestions owners ask
What is maker checker in simple terms?
It is a rule that one person prepares a sensitive entry and a different person approves it, and the entry has no effect until release, with both people recorded.
Does every screen need maker checker?
No. Apply it to money movement, rates, limits, customer master changes and user access, because covering every screen slows staff and encourages them to share logins. A short list keeps the control credible.
What should an auditor see in the log?
Auditors should see who acted, what changed, the before and after values, the time, the device and the approver, plus failed attempts and overrides filtered by user. They should export it without asking a developer.
Can a small firm afford this?
The controls are mostly settings and discipline rather than extra staff, since a two person team can separate entry from approval by rotating who does which. The software must enforce the split. Name a cover for leave days.