What a strong QA function should tell you.

A low QA error rate is easy to celebrate as evidence of a healthy Financial Crime operation.

It may also be a sign of an ineffective QA process.

In any sizeable Financial Crime function, analysts manage high case volumes across multiple systems. Procedures change, and many decisions rely on judgement. Some inconsistency is inevitable.

The value of QA lies in what it helps the organisation understand. Rather than simply counting errors, it should explain where weaknesses are emerging, why they occur and what needs to change.

When QA only measures performance, it reports the past. When it explains patterns, it helps improve the future.

An error rate is only the starting point

Headline error rates provide a consistent measure of quality over time and can highlight whether performance is improving or deteriorating.

What they don’t explain is why errors are happening.

A score cannot tell you whether a finding is an isolated mistake or part of a wider pattern. It does not show whether the problem sits with one analyst, one team or the design of the operation itself. Nor can it explain whether the cause is an unclear procedure, inconsistent policy interpretation, poor data, a confusing workflow or gaps in ownership.

Imagine a QA reviewer notices that an analyst failed to obtain a required document during a customer review. On its own, that looks like a straightforward analyst error.

Over the following weeks, similar findings appear across several experienced analysts working in different teams. Each case involves the same document and the same point in the process.

At that stage, the issue is unlikely to be individual performance. It suggests something in the operating environment is contributing to the error. The procedure may be unclear. The system may not present the requirement at the right point. Different teams may interpret the policy differently.

The priority is to identify the common cause and remove it. One improvement to the process can prevent the same error from recurring across the operation.

Look for patterns, not just individual mistakes

Strong QA functions treat individual findings as a build-up of evidence rather than isolated cases.

By grouping findings by their likely cause, they show where the operating environment is creating unnecessary risk.

This is where QA really starts creating value.

It can show whether an issue is concentrated within one team or affects the whole function. It can highlight where experienced analysts reach different conclusions on identical facts. It can also reveal manual activities or poor data that are creating unnecessary inconsistency.

Without this analysis, organisations spend time correcting individual cases while leaving the conditions that generated those errors unchanged.

There is also value in testing whether processes work for less experienced analysts. Experienced people tend to know which procedures need interpretation, which workarounds are needed and how to handle situations the documented process doesn’t quite cover. A junior analyst following the same procedure may struggle because they do not yet have that knowledge. Where a process only works because experienced people know how to navigate it, that is a weakness in the operating environment rather than simply an individual capability issue.

Respond to the cause, not the symptom

Once a pattern has been identified, the response should reflect both its significance and its cause.

Frequency matters, but so do impact and reach. Leaders need to understand how many customers, cases or teams are affected.

A recurring error in a specialist case type may require expert oversight or better case allocation. A relatively minor issue affecting thousands of routine cases may justify changes to procedures, systems or controls because its cumulative impact is much greater.

Too often, organisations respond to every QA finding in much the same way.

Training, for example, is often the default solution because it is visible, straightforward to organise and easy to evidence.

Training may well be appropriate where there is a genuine capability gap, but adds little value when analysts already understand the requirement and the cause lies elsewhere.

If procedures are unclear, rewrite them. If data quality is poor, improve the data. If the workflow encourages the wrong decision, change the process.

Some findings may justify coaching for a particular team. Others may require clearer guidance, better examples for difficult judgement calls or specialist handling for complex work.

Effective QA helps leaders match the intervention to the cause. Address the cause, and the symptoms usually disappear.

What leaders should expect from QA

Senior leaders should expect QA reporting to help them understand:

• Which patterns are emerging
• What is most likely causing them
• How significant and widespread they are
• Where improvement effort will have the greatest effect

That leads to a more useful governance discussion.

Instead of reviewing a score and a list of completed actions, leaders can assess whether the organisation is learning from its findings, whether the proposed response matches the underlying cause and whether improvement effort is focused where it will have the greatest impact.

QA also provides stronger evidence for decisions about process redesign, control improvements and technology investment. Repeated manual errors may strengthen the case for automation. Recurring data issues may justify system changes. Inconsistent judgement may indicate that policy or guidance needs to be clearer.

Use QA as operational intelligence

A strong QA function helps the organisation understand how its operation is performing and where it is becoming vulnerable.

It distinguishes between isolated mistakes and weaknesses built into the operating environment. It explains why issues continue to recur and where improvement will have the greatest effect.

A low error rate may still reflect a healthy operation, but your confidence in that number should come from the quality of the analysis behind it.