Why AFC Programmes Fail Audit: Five Gaps Between Work Done and Work Evidenced

Audit-proofing is not about the evidence pack. It is about how you run your anti financial crime (AFC) programme. On the face of it, your AFC programme is operating well. Policies are documented. Alerts are being reviewed. Screening hits are being discounted. Suspicious activity reporting (SAR) decisions are being made.

Then audit asks: ‘Show me why that decision was made?’ That is where the gap appears. Not because nothing happened. Because the evidence was never captured in a way that can be retrieved and explained under scrutiny.

That is where many AFC programmes are exposed. Not in the absence of activity, but in the gap between work being done and work being evidenced.

A programme can be busy, staffed and active - and still be hard to defend.  

Why the ‘pre-audit prep’ is never enough

When audit preparation is treated as a pre-audit clean-up exercise, a few things usually happen.

Evidence is reconstructed rather than retrieved. Teams search email trails, shared drives, old meeting notes and individual spreadsheets to piece together what happened. That introduces gaps, inconsistencies and version-control problems.

Policies, procedures and risk assessments are pushed through a review cycle just before the audit starts. The issue is not that they were reviewed. The issue is that they were not being kept current as part of the normal review. If the review happens only because audit is coming what does that say about the governance process.

Known issues become liabilities. The team may have understood the weakness, discussed it and even started to manage it. But if it was not logged, escalated and tracked, it looks unmanaged.

Auditors are not looking for perfection. They are looking for a programme that understands its own risk, can explain its decisions, and can show weaknesses are being managed.

The five audit failings

Audit findings rarely come from the total absence of a control. More often, they come from a broken chain between risk identification, controls, decisions, evidence and oversight.

1. Risks are understood, but not well documented

What firms think: We know our risk profile. The EWRA is complete. The high-risk areas are understood by the team.

What audit asks: How does the EWRA drive the control framework?

What the gap is: The risk assessment exists, but the risk-to-control chain is weak

Most firms have an enterprise-wide risk assessment (EWRA). It has been drafted, reviewed and approved. It usually covers the expected risk categories: customer risk, product/services, geography and delivery channel. The problem often appears when audit asks a more practical question: how does the EWRA inform the AFC control environment?

The EWRA may identify certain sectors, products or channels as higher risk, but there is not always a clear risk-to-control inventory showing which controls respond to those risks, who owns them, how they work, and how their effectiveness is measured.

In onboarding, high-risk merchant sectors may be subject to enhanced due diligence checks. But the link and the risk-based approach used between the EWRA, the customer risk assessment, onboarding standards and approval may not be clearly documented.

In transaction monitoring, the EWRA may point to mule activity, rapid movement of funds or higher-risk corridors as high-risk areas. But if no one can show which scenarios cover those risks, why thresholds are set where they are, or where residual gaps remain, the control framework becomes difficult to defend.

Good practice is to maintain a live risk-to-control inventory. Each material risk in the EWRA should map to the controls that mitigate it, the owner of those controls, the evidence of the control and how its effectiveness is assessed, and any known gaps or limitations.

The question is not does the EWRA exists. It is whether the programme can show that the EWRA genuinely drives the control framework.

2. Control changes happen without an audit trail

What firms think: We tuned the control for a valid reason.

What audit asks: Show me the rationale, testing, approval and post-change validation.

What the gap is: The change happened, but the evidence chain did not.

Control changes are one of the places audits will look closely at, especially in areas such as screening or transaction monitoring.

A transaction monitoring (TM) threshold may have been adjusted, or a suppression rule in screening may have been introduced. In each case, the change may have been reasonable and value adding by reducing noise, removing duplication or responding to a genuine shift in customer activity. The problem by the time audit rolls around is you cannot rely on memory, or on the fact that everyone involved understood the rationale at the time.

Audit will want to see the control change record. What triggered the change? What risk or operational issue was it meant to address? What testing was performed? What impact was expected? Who reviewed and approved it? When did it go live? What did post-change validation show?

There may be a Jira ticket, an email chain or a meeting note, but not a complete record showing that the change was risk-assessed, tested, approved and monitored after implementation. A static control environment is not evidence of maturity, but every material control change alters risk exposure in some way and if it’s not documented well, it can show up as an audit failing.

Good practice is to make control change records mandatory and consistent. For TM, that means every material scenario, threshold, segmentation or suppression change should have a clear rationale, test results, expected impact, approval record, implementation date and post-change review. The same discipline should apply to screening logic, onboarding risk models, quality assurance (QA) sampling methodology and SAR escalation procedures.

The question is not whether the TM change made sense. It is whether the programme can prove it was understood, tested, approved and monitored after it went live.

3. Decisions without rationale

What firms think: The case was closed correctly.

What audit asks: Can an independent reviewer understand how that decision was reached?

What the gap is: A closure code is being treated as a rationale.

An alert outcome or decision is not the same as a rationale. Most AFC programmes can show that an alert, case or referral reached an outcome. The screening hit was discounted, a SAR was filed, or a high-risk customer was approved after enhanced due diligence (EDD). The harder question is whether the record explains how that outcome was reached.

This is where audit often identifies issues, because alert dispositioning is one of the clearest windows into the quality of AFC decision-making. A closure reason such as ‘no suspicion’, ‘expected activity’, ‘false positive’ or ‘discounted match’ may complete the workflow, but it does not explain the judgement of the analyst.

For a screening alert, it may be correct to discount a match because the date of birth does not align, the geography is different, or the adverse media relates to another individual. But the file still needs to show the source checked, the basis for discounting, and why the decision is independently reviewable.

This is also where escalation and dispositioning need to work together. The record should show what triggered the alert or referral, which risk factors were considered, who reviewed the matter, what decision was made, what action followed, and whether the matter was closed.

Good practice is to summarise decisions using consistent language, with closure reasons, escalation outcomes, all tagged uniformly. The aim is not longer case notes. It is better decision evidence: clear rationale, consistent terminology, reliable tagging and enough context for an independent reviewer to understand why the outcome was reached. Where escalations are made the record should show what triggered the escalation, which risk factors were considered, who reviewed the matter, what decision was made, what action followed, and whether the matter was closed.

The question is not whether the alert was dispositioned or the case was closed incorrectly. It is so an independent reviewer can understand the decision without needing someone to explain it verbally.

4. MI and reporting are limited, inconsistent or too activity-focused

What firms think: We report AFC management information (MI) to governance every month.

What audit asks: What did the MI tell management, what challenge took place, and what action followed?

What the gap is: Discussed at committee, is not the same as governed.

MI and governance is another area where programmes can look stronger on paper than they are in practice. The board may see screening alert volumes, onboarding turnaround times, TM alert closures and SAR filing numbers. Those metrics are useful, but they do not always show whether the control environment is working, where risk is increasing, or whether decisions are improving.

That weakness often carries through into governance reports. A committee may have discussed a backlog, a spike in screening alerts, repeat QA findings or a concern with SAR timeliness. But if the minutes do not show challenge, decision, ownership or follow-up action, it is hard to evidence effective oversight. From an audit perspective, ‘discussed at risk committee’ is not the same as governed.

There is also a consistency problem. Definitions vary between teams. Exceptions are removed manually. Commentary changes from pack to pack. One team reports ‘case ageing’ from the date an alert was created, another from the date it was assigned. When audit asks for the underlying data, the metric may be difficult to recreate or explain.

Good practice is to build MI around outcomes as well as activity - does it explain whether high-risk onboarding referrals are increasing in a particular sector? Does it track TM alert quality, escalation rates and SAR conversion by typology? Does it identify repeat QA findings and whether they led to control changes? That means clear metric definitions, reliable source data, named owners, consistent commentary and a documented link to governance action. AFC reporting should show what changed, what deteriorated, what was escalated, and what management decided to do about it.

The question is not whether MI is being produced. It is whether it helps the programme understand risk, evidence oversight and drive action.

5. Assurance is limited to quality checking, not control effectiveness

What firms think: We have QA and testing in place

What audit asks: What did assurance tell you about whether the control is working?

What the gap is: Assurance fixes the file, but not the control.

Assurance is often present, but too narrow. Many AFC programmes have QA, sample reviews and periodic testing which results is files being checked, errors are recorded and feedback is given to analysts. A checklist is completed.

More often than not, assurance fixes the file rather than improving the control. The individual case is fixed, but the pattern is not analysed. Repeat issues are not treated thematically. Findings do not consistently feed into policy, training, system configuration, or workflow design. Or assurance that finds recurring analyst errors but cannot show that training was updated is incomplete. The evidence chain includes upskilling staff - who was trained, on what, to what standard, and what changed when QA found errors.

The same issue applies to technology. AFC tooling is often assumed to be working because it is live. But audit will expect evidence that the technology underpinning the control has been tested: data feeds are complete, rules are firing as intended, screening lists are updating, workflow permissions are appropriate, risk rating cannot be manually bypassed without approval, mandatory fields are enforced, audit logs are retained, and reports reconcile back to source data.

Good assurance should look beyond file quality. It should test whether controls are designed properly, supported by the right tooling, operating consistently, producing reliable evidence and leading to the right outcomes. Where findings repeat, they should trigger root cause analysis and control change, not just analyst feedback.

The question is not whether QA is happening. It is whether assurance is testing the full control environment - including the systems, data and workflows the programme relies on.

The real test is defensibility

A strong AFC programme can evidence not just activity, but judgement: why decisions were made, what trade-offs were accepted, what residual risk remained and who signed off. That is the difference between a programme that operates and a programme that can defend how it operates.

The next question is whether the programme’s data, technology and workflows are designed to produce that evidence naturally - or are teams are forced to reconstruct it every time audit arrives.

Because under audit, the issue is rarely whether people were busy. It is whether the programme can prove that the right risks were identified, the right controls operated, the right decisions were made, and the right oversight took place.

‍