The approval that sinks your audit came from your own team. Here is how to prove who decided, and why.

Picture the audit. The reviewer pulls forty customer files at random. File twenty-three is a customer whose face did not match the photo on their government record. The check failed. The account is open anyway, and it has been moving money for five months.

Somebody approved it. The auditor asks three questions. Who? On what basis? Were they allowed to?

Your team logs in to the back office through one shared admin account, so the first answer is "operations". There is no note, so the second answer is a guess. Everyone on that login can approve anything, so the third answer is yes, which is the worst answer of the three.

Nothing was hacked. No fraudster beat your checks. The control worked, and one of your own people switched it off for one customer. That is insider risk in a compliance operation, and most of the time it is not a crime. It is a favour, a shortcut on a busy Friday, or a target that had to be met.

Why "who decided?" is the auditor's question

The standards you are measured against assume your staff are part of the risk. FATF Recommendation 18 (opens in a new tab) requires financial institutions to run programmes against money laundering, and its interpretive note says those programmes should include internal policies, procedures and controls, screening procedures when hiring employees, ongoing training, and "an independent audit function to test the system".

The Basel Committee's guidelines on the sound management of money laundering risk (opens in a new tab) describe three lines of defence, with internal audit as the third. Among the things it expects audit to evaluate is "the effectiveness of bank staff in implementing the bank's policies and procedures". The same guidelines say records should be good enough to provide an audit trail in the event of disputes, legal action or investigations.

So the auditor is not only testing whether your checks are good. They are testing whether your people followed them, and whether you can show it. A decision you cannot attribute fails that test even if it was the right decision.

There is some evidence on how often controls fail from the inside, though it is about fraud against employers and not about compliance approvals. The ACFE's Occupational Fraud 2024: A Report to the Nations (opens in a new tab) studied 1,921 cases from 138 countries and territories. It attributes 32% of them mainly to a lack of internal controls and a further 19% to an override of existing controls. The typical case ran for 12 months before it was detected. We have not found a figure of that quality for compliance overrides in African markets, so we will not offer one.

Four controls that answer it

None of these is new. NIST SP 800-53 (opens in a new tab), the US government's catalogue of security controls, is a useful plain-language reference even if you are not bound by it.

• Least privilege. The control asks you to allow "only authorized accesses" that are necessary to accomplish assigned tasks. In a compliance team that means the person who reads alerts cannot also change the rules that raise them.

• A second person on sensitive actions. NIST says separation of duties "addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion". One person can make a mistake or do a favour. Two people have to agree to it.

• One login per person, with a second factor. The catalogue asks you to uniquely identify each user, and to use multi-factor authentication for privileged accounts. A shared login defeats every other control, because the log can only name the account.

• An audit trail that names the person. Audit records should establish what happened, when, where, the outcome, and the identity of the individuals involved.

What that looks like in Toden

Here is how each control maps to the product today.

• Roles. Every person holds exactly one role, and a role is a set of permissions you choose. Approving or declining a verification needs verifications:review. Overriding a fraud decision needs fraud_prevention:override. Changing screening needs screening:manage, and changing a workflow needs workflows:manage. The built-in Member and Viewer roles are read-only. Permissions are checked on the server, and nobody can grant a permission they do not hold themselves.

• An override that stays visible. When a reviewer approves a verification, the verification is not rewritten. Its check status keeps saying what the checks found, and the status history lists every change with who made it and when. The reviewer can add a note saying why, which is kept in your audit log and on the timeline.

• A control switched off. A workflow with AML Screening turned off screens nobody, so that change deserves a name against it. Publishing a workflow is recorded in the audit log. Switching screening off for the whole organisation needs its own permission and an explicit acknowledgement, and is recorded too.

• Two-factor sign-in. Members sign in with authenticator-app codes or a passkey. An organisation can require two-factor for every member, and any session can be revoked at once.

• The audit log. Each entry holds the person's name and email as they were at the time, the role they held, the action, the record affected and the IP address. It is append-only: there is no way to edit or delete an entry from the console or the API. It holds no ID numbers, images or secrets, so you can hand it to an auditor. Actions Toden support takes on your account appear in your log, marked as such.

• Two people on a report. The person who drafts a suspicious activity report can never be the one who files it. We cover the report itself in writing a suspicious activity report, and the work before it in alert triage and case management.

What Toden does not do

The limits matter more than the features.

• It enforces a second person on one action only: filing a report. For approvals and overrides, the separation comes from the roles you design. If one person holds every permission, one person can still do everything.

• It does not stop a determined insider. A reviewer with the right permission can approve a failed check. What Toden does is make sure the approval carries their name and the failed check stays on the record.

• It cannot tell whether two people share one login. Requiring two-factor makes sharing harder. It does not make it impossible, and the policy against it is yours.

• Decisions your backend makes through the API are recorded against the API key, not a person. Who pressed the button in your own system is in your logs, not ours. See publishable and secret API keys.

• The audit log covers Toden. It knows nothing about your core banking system, your spreadsheets or the instruction that arrived by chat message.

• Toden does not hold SOC 2 or ISO 27001 certification today. Our security page says so, and lists the controls that exist.

What your regulator expects on internal controls, staff vetting and record keeping differs by country. We have cited the FATF, the Basel Committee and NIST here, not the Central Bank of Nigeria or any other national regulator. This is not legal advice for your situation.

Five things to check this week

• Does every person have their own login? Count the accounts, then count the people.

• Is two-factor required for everyone, or only recommended?

• Who can approve a failed check, and is that list shorter than the list of people who can see one?

• Can the person who changes a rule also clear the alerts it raises?

• Pick one approval from last month. Can you name who made it, and why, in under five minutes?

If the last answer is no, that is the file the auditor will pull.

Want to see who can do what in your own workspace? Open the Toden console (opens in a new tab) or read how Toden handles security.