Explainable AI in AML: How to Use Models You Can Defend to a Regulator

Model risk has become a compliance issue in its own right. Regulators across APAC and globally no longer assess only whether an AML programme generates alerts. They examine how the underlying models were built, how changes to those models are governed, what analysts see when they review an alert, and whether the institution can reconstruct the evidence behind a suspicious matter report.

An AML model that produces accurate outputs but cannot be explained at the decision level creates several compounding problems. Analysts dismiss alerts they do not understand, either too readily or not readily enough. The audit trail for an STR contains a score but not the reasoning behind it. Model changes are difficult to defend when a regulator asks why alert volumes shifted after a retraining cycle.

Explainability in AML is not a feature that makes AI more palatable to sceptical regulators. It is the mechanism through which AI-generated decisions become defensible in a compliance context. This guide covers what explainability means at each level of the decision process, the governance lifecycle that regulators expect, and how to structure a programme that can withstand examination.

What regulators actually ask about AI models

Regulatory examinations of AI-assisted AML programmes have become more specific. The questions that matter are not "do you use AI?" but rather:

• Can you explain what the model learned, and which factors it considers most important across all customers?
• Can you explain what drove a specific alert, in terms an investigator can use to document their decision?
• How are model changes governed, and who approves a model before it goes into production?
• What happens to alert volumes and detection coverage when a model is retrained? How is that change documented?
• How long is model version history retained, and can you demonstrate what model was active at any point in the past?

These questions reflect the model risk management frameworks that BSP, the OCC, and the PRA have published, and that other APAC regulators reference in examination guidance. An institution running AI in AML without answers to all five is carrying model risk in addition to financial crime risk.

Three levels of explainability

Explainability in AML operates at three distinct levels, each serving a different function in the compliance programme.

Global explainability

Global explainability describes the model as a whole. It answers: which features does the model consider most important across all customers, how do those features influence predictions, and what overall decision logic has the model learned?

Techniques that provide global explainability include global feature importance rankings and surrogate decision trees that approximate the model's behaviour in terms that compliance leadership and model risk reviewers can follow. Global explainability is relevant when a chief compliance officer or model risk committee asks whether the detection framework is aligned with the institution's risk appetite, or when an examiner asks to understand the basis on which the model was approved for production use.

Without global explainability, a compliance team cannot answer the question: does this model detect what we intend it to detect, and is there anything it weighs heavily that we would not expect?

Local explainability

Local explainability describes an individual alert or prediction. It answers: which features drove this customer's score, how strongly did each factor affect the result, and what decision path did the model follow?

This is the level investigators use at the point of alert review. When an analyst opens an alert, the local explanation shows them the same evidence the model used to generate it. They can see that the alert fired because transaction velocity increased sharply over a 14-day period, a new counterparty in a high-risk jurisdiction appeared in the last three transactions, and the customer's profile has not been updated since onboarding two years ago. They can assess whether that combination warrants escalation or dismissal, and they can document their reasoning with reference to specific evidence rather than just recording a score threshold.

Without local explainability, analysts either trust the score and escalate without documented reasoning, or dismiss without being able to articulate why. Both create audit trail gaps that examinations surface.

Contextual explainability

Contextual explainability takes the local evidence one step further: it translates technical feature weights into financial crime language. Rather than showing the analyst a list of risk indicator scores, contextual explainability describes the behaviour those scores represent.

An analyst with contextual explainability sees: this alert corresponds to a structuring pattern consistent with a typology in the AFC Ecosystem library involving split transactions below reporting thresholds across multiple accounts. The customer's behaviour over the last 30 days matches several indicators associated with this typology. To learn more about how the AFC Ecosystem works, explore our comprehensive guide.

This translation does not require data science expertise. It is written in the language of financial crime investigation, which is what the analyst needs to document their decision and, if they escalate, to write the STR narrative. It removes a translation step that currently takes investigator time and introduces inconsistency in how alerts are documented.

The five-stage governance lifecycle

Explainability at the decision level is one part of what regulators expect. The other is a documented governance lifecycle for model changes. Without governance, explainability at the alert level is incomplete: you can explain what a model did, but not whether the model was approved to do it.

FinCense's model governance runs on a five-stage lifecycle:

Stage 1: Alert creation. When an alert is generated, the contributing signals behind the score are frozen onto the alert record and made immutable. The evidence that drove the alert cannot be changed after the fact. This means the audit trail for every alert reflects the exact state of the model and data at the moment the alert was created, regardless of any subsequent model update.

Stage 2: Analyst feedback. True positive and false positive determinations made by investigators feed back into the model as labelled inputs for threshold tuning. This creates a supervised signal from real analyst decisions, rather than relying solely on historical data that may not reflect current typologies. The feedback loop is governed: analyst determinations that go into model tuning are recorded and attributable.

Stage 3: Pre-promotion shadow testing. Before any new or updated model goes into production, it runs a shadow-testing window against the current production model. Alert volumes, detection coverage, and precision are compared between the challenger and the champion on live transaction data. The comparison results are documented. A challenger model is not promoted unless the shadow-testing evidence supports it.

Stage 4: Production monitoring. Once a model is in production, it is monitored for drift against the calibrated baseline. Scheduled monitoring intervals check whether the model's performance characteristics have changed materially since promotion. If drift is detected, a review is triggered before the next scheduled interval. This prevents a model from degrading silently between review cycles.

Stage 5: Versioning and retention. Every model version, the dataset snapshot used to train it, and the evidence used to approve its promotion are retained for audit. A compliance team can reconstruct which model version was active at any point in the past, what threshold settings were applied, and what evidence supported the promotion decision. This answers the regulatory question: what model was running at the time this STR was generated?

The champion-challenger framework in practice

Within this governance lifecycle, model updates are managed through champion-challenger comparison. The current production model is the champion. A retrained or alternative model is the challenger. The challenger runs in parallel on live data during the shadow-testing window and is compared with the champion on performance, stability, and explainability metrics.

The challenger is promoted only when it demonstrably outperforms the champion. Promotion is a governed decision with documented evidence, not an automated deployment triggered by a retraining schedule. Rollback to the previous champion is always possible, and the version record of both models is retained.

This approach addresses one of the most common model risk findings in AML examination: model changes that were not documented, not approved through a formal governance process, or not tested against the production model before deployment.

What documentation regulators expect

The documentation that satisfies regulatory examination for an AI-assisted AML programme includes several elements that go beyond what most institutions currently maintain.

For each model in production: the training dataset, the validation results, the approval decision and the evidence that supported it, the feature importance ranking, and the threshold settings and the rationale for them.

For each model update: the shadow-testing results comparing challenger with champion, the promotion decision and who made it, and the version record showing what changed between the previous model and the current one.

For each alert: the signals that were frozen onto the alert record at creation, the analyst decision and the documented reasoning, and, if escalated, the STR narrative and its connection to the alert evidence.

For each false positive dismissal: the basis for the dismissal, the identity of the reviewing analyst, and confirmation that the decision was made at the appropriate authority level.

FinCense's governance lifecycle is designed to produce this documentation as a byproduct of normal operations rather than as a retrospective exercise before examination.

How FinCense implements explainability and governance

FinCense provides all three levels of explainability across its transaction monitoring, screening, and customer risk scoring modules. Global feature importance and surrogate decision trees are available for model risk reviews. Local alert-level explanations are presented to investigators at the point of triage. Contextual financial crime language is generated from the local evidence and connected to the relevant typology from the AFC Ecosystem library.

The five-stage governance lifecycle is built into the platform. Alert signals are immutable on creation. Analyst feedback feeds the tuning pipeline with proper attribution. Shadow testing runs before any model goes live. Production monitoring checks for drift at configured intervals. Every version, dataset, and promotion decision is retained in the audit trail.

Model risk reviewers and examiners can access the full governance record through the same case management environment that investigators use for daily operations. There is no separate reporting system to maintain or reconcile.

For how the underlying AI architecture operates across FinCense, see our guide to what AI-native AML means. For how the three-stage ML process works in transaction monitoring specifically, see our guide to how machine learning works in AML transaction monitoring.

To see how FinCense's explainability and governance framework works for your programme, book a demo with our team.

Frequently asked questions

What is explainable AI in AML?

Explainable AI in AML means that the decisions made by machine learning models — which alerts to generate, how to score customers, which matches to flag — can be understood and documented at three levels: what the model learned overall (global), what drove a specific alert (local), and how the evidence maps to financial crime context in plain language (contextual). Without all three levels, an AI-assisted AML programme cannot fully satisfy model risk requirements or produce the documentation regulators expect.

What do regulators require from AI model governance in AML?

Regulators require institutions to demonstrate that models were approved through a formal governance process before production deployment, that changes to models are documented and tested against the current production model, that the model version active at any point in the past can be reconstructed, and that the evidence behind individual alerts and STRs is retained immutably. These requirements align with model risk management frameworks referenced by BSP, the OCC, and the PRA.

What is the champion-challenger model governance approach?

Champion-challenger governance keeps the current production model (the champion) running while a retrained or alternative model (the challenger) is tested in a shadow-testing window against the champion on live data. The challenger is promoted only when it demonstrably outperforms the champion across performance, stability, and explainability metrics. Every promotion decision, dataset snapshot, and model version is retained for audit.

What is the difference between local and contextual explainability in AML?

Local explainability shows which features drove a specific alert and how strongly each contributed to the score. Contextual explainability translates that technical evidence into financial crime language — describing the behaviour those features represent and connecting it to the relevant typology. Both are necessary: local explainability gives investigators the evidence; contextual explainability gives them the language to document their decisions and write STR narratives.

Why does AML model governance require immutable alert records?

When an alert is generated, the signals behind it reflect the state of the model and customer data at that moment. If those signals can be changed after the fact, the audit trail for the alert no longer represents what actually happened when the alert was created. Regulators expect to be able to reconstruct the evidence that existed at the time of an STR filing. Immutable alert records ensure that reconstruction is always possible.

How does explainability improve investigator performance?

Investigators who understand why an alert was generated assess it more accurately and document their decisions more thoroughly. Local explainability reduces the time spent determining what evidence exists for an alert. Contextual explainability reduces the time spent translating that evidence into STR-appropriate language. Both effects reduce per-alert investigation time while improving the quality of the documentation produced.