Explainable and AI in AML Software: A Practical Guide for 2026

 AI used in AML software must be able to justify its decisions to examiners, not merely make them. Here’s what explainability means in practice, and how to evaluate it during vendor selection. 

A model you can’t explain is a model you can’t defend. And a model you can’t defend is a model you don’t really control. In AML, that’s really expensive. 

Most AML software now carries machine learning somewhere inside it. Models rank alerts, score customers, resolve entities, and, in newer platforms, draft the first version of an investigation summary. The detection gains are real and well documented. 

The accountability problem is less discussed. A risk score of 87 is not evidence. It becomes evidence only when the institution can say which behaviours produced it, how much each mattered, and what the model looked like on the day it fired. Most compliance teams can describe their monitoring system at a general level. Far fewer can do it for one specific alert, from their own screen, after the model has been retrained twice since. 

That distinction is what explainable AI addresses. 

Explainable AI is a set of techniques and controls that make a model’s output reproducible and documentable, which is what converts a detection capability into a defensible one. 

This guide covers what explainability means inside AML software, why it matters legally and operationally, where implementations run into trouble, and what to ask vendors before signing. 

A New Failure Mode: Build-Your-Own AI Agents in AML 

One of the fastest-growing features in AML software is the ability for users to configure their own AI agents: an alert-investigation agent, a customer risk-rating agent, a deep-research agent or a narrative-drafting agent. The flexibility is attractive. The governance question is harder. 

An AML investigator is trained to assess financial-crime risk, follow evidence and document a defensible disposition. That does not automatically make the investigator an AI workflow designer, prompt engineer or model validator. A simple interface can make an agent easy to configure without making it easy to configure correctly. 

The question is therefore not only, “Can our analysts build an agent?” It is: “Who defines the expected output, who tests it, who approves it, and how do we prove that it continues to perform as intended after the prompt, model, data or workflow changes?” That is likely to be one of the first lines of inquiry from an examiner, auditor or model-risk team. 

At a minimum, a self-configurable AML agent needs: 

1. A documented purpose, permitted use and prohibited actions. 
2. Version control for its instructions, prompts, tools, data sources and model configuration. 
3. A representative test pack containing confirmed true positives, false positives, edge cases and deliberately incomplete or conflicting data. 
4. Defined acceptance criteria for factual accuracy, evidence traceability, completeness and the absence of unsupported or fabricated statements. 
5. Independent review and approval before production use, with renewed testing after material changes. 
6. Decision logs that preserve what the agent received, what it produced, which version ran, what the human changed and what final decision was taken. 
7. Ongoing monitoring for performance drift, recurring errors, overrides and outcomes that fall outside the institution’s risk appetite. 

Without these controls, “build your own agent” can quietly become “build your own uncontrolled model.” The configuration may sit with an analyst, but accountability remains with the institution. 

What Is Explainable AI in AML Software? 

Explainable AI, often shortened to XAI, refers to systems that can show the reasoning behind their outputs rather than only the outputs. 

The general definition is broad. The AML version is narrower and more demanding: for any output or automated action concerning a customer or transaction, the institution can state what drove it and reproduce that reasoning later, without help from the vendor. 

Each part of that matters. 

“Any output or automated action” includes alerts that fired, alerts that closed automatically, risk scores assigned, screening matches surfaced or suppressed, and statements inside AI-generated case summaries. 

“The institution” means your compliance team, from your interface. 

“Later” means after the model has retrained, potentially years after the decision was made. 

The opposite is a black box. It produces a risk score of 87 and no account of where 87 came from. The score may be accurate. It is still unusable as evidence, because a number without a rationale cannot support a SAR narrative, cannot be independently tested, and cannot be defended when an examiner asks why one customer exited and another wasn’t. 

One distinction is worth keeping straight, because vendors blur it. Interpretability is a property of the model itself: a decision tree is more interpretable than a deep neural network. 

Explainability is a property of the system built around the model, including the logging, versioning, documentation and analyst-facing interface. You can build an explainable system on top of a model that isn’t especially interpretable. Most institutions have to, because restricting yourself to interpretable models alone costs detection coverage. 

Why Explainable AI Matters in AML Compliance 

Few AML-specific regulations use the term “explainable AI” explicitly. However, several regulatory and supervisory expectations require capabilities that are difficult to meet without it. 

In the US, the Federal Reserve, OCC and FDIC replaced SR 11-7 on 17 April 2026 with revised model risk management guidance, issued as SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026. It also supersedes SR 21-8, the 2021 interagency statement covering BSA/AML systems. 

The revision is shorter, principles-based and explicitly non-binding, but that should not be read as permission to relax control. It makes proportionality the organising principle: the testing, validation, monitoring and governance applied to a model should reflect its complexity, materiality and use. For example, SR 26-2 expects testing to determine whether a model performs as intended; outcomes analysis against real-world results; ongoing monitoring as products, customers, data and market conditions change; and documentation of model limitations, exceptions and remediation. For a customised vendor model, the institution should also understand and evaluate the changes made for its own business. 

Generative and agentic AI are expressly outside the formal scope of SR 26-2. However, the guidance says that an institution’s own risk-management and governance practices should determine appropriate controls for tools and systems outside scope. That distinction matters: an institution cannot defend a self-configured AML agent merely by saying that the guidance did not prescribe how to validate it. 

Separately, the FFIEC examination framework requires independent testing of monitoring systems, which becomes difficult when decision logic, configuration history or evidence trails are not available. 

Internationally, FATF pairs its encouragement of new technology with expectations around transparency and human oversight. GDPR Article 22 creates protections around certain solely automated decisions with legal or similarly significant effects. Under the EU AI Act implementation timeline, Article 50 transparency obligations applied from 2 August 2026, while obligations for certain Annex III high-risk systems were extended to 2 December 2027 under the AI Omnibus. 

If you have read some of my recent posts on the EU AI Act, you will have seen a recurring point: the Act is useful not only as a classification exercise, but as a practical AI governance playbook. Its human-oversight logic is relevant well beyond systems that ultimately fall into the “high-risk” category. In AML, human-in-the-loop should mean that a trained investigator can understand the AI output, challenge it, trace it to evidence, override it and remain accountable for the final disposition. A human who can only click “accept” is not meaningful oversight. 

The constant across all of them: the institution remains accountable for decisions made with, or automatically executed by, its AML software. 

Importance of XAI in AML Compliance Operations 

The regulatory case is one argument. The operational case is separate, and it shows up in the numbers a financial-crime compliance leader watches. 

1. Time per alert: Opaque alerts force the analyst to establish the basis for the alert before doing anything with it. That work repeats on every alert and scales directly with volume. Explanations available at triage remove a step from tens of thousands of cases a year. 

1. Consistency across a team: When analysts articulate the reasoning themselves, case file quality varies with who handled it. That variance is invisible day to day and expensive in a look-back, when a reviewer has to judge whether a decision was reasonable from documentation that doesn’t say why. 

1. Tuning with evidence: Threshold changes affect coverage, false positives and workload at once. Teams without explainability adjust settings and observe the consequences afterwards. Teams with it can reason about the effect first. 

1. Cheaper validation: Producing model documentation retrospectively, in the weeks before a validation cycle, costs far more than having the system generate it as a byproduct of running. 

1. Visible alert quality: Explanations expose patterns that aggregate false positive rates hide. If a system keeps flagging customers for a reason that doesn’t stand up, the reason is on screen rather than buried in a percentage. 

1. Analyst retention: Investigators asked to act on scores they can’t interrogate either over-escalate or stop engaging. Neither is fixed by training or hiring. 

How XAI Improves AML Monitoring and Screening 

Explainability changes specific workflows rather than the programme in the abstract. 

1. Sanctions and PEP screening: A match with no context has to be re-derived by hand. Screening with explainability shows which field matched, at what strength, against which list entry, so a name collision can be dismissed with a documented reason instead of an unrecorded judgement. Screening carries much of the alert volume at most institutions, so this is where the aggregate time saving is largest. 

1. Adverse media: Media alerts are the least self-explanatory in AML. Explainability means surfacing the specific article, the entity match behind it, and the risk category assigned, so an analyst can separate a genuine hit from a common name quickly. 

1. Transaction monitoring: Behavioural models don’t tie back to a single readable threshold, so without alert-level explanation the analyst is reverse-engineering the model’s reasoning from raw transaction data. That is slow and produces documentation that describes the transactions rather than the concern. 

1. Alert investigation: This is where the effects compound. Velocity iInvestigate automates the evidence-gathering and investigation workflow, not the final compliance decision. It links entities, surfaces behavioural patterns and networks across cases, and produces evidence-backed reports with detailed audit trails for human review. Its AI Investigators are built using open-source models deployed within a controlled, institution-specific environment. Client data remains segregated and is not used to train or enrich another financial institution’s environment. The models and investigation workflows are tailored to the institution’s business model, products, risk policies, customer activity and monitoring scenarios, which helps avoid the generic output produced when a general-purpose model is given an alert with little institutional context. At one Tier-3 regional bank, the module integrated sanctions, PEP and adverse-media sources and generated summaries consolidating findings across systems. Average alert review time fell from 45 minutes to 15, a 65 percent reduction, while team productivity increased threefold and case summaries became more consistent for audit and regulatory review. 

1. Customer risk rating: Ratings drive review frequency, enhanced due diligence and exit decisions. When a rating is challenged, the contributing factors have to be retrievable for the date it was assigned, not just for today. 

What Are the Challenges of Implementing XAI in AML Compliance 

Five obstacles come up consistently, and only the first is widely discussed. 

1. Reproducing a decision after the model has moved: Adaptive systems retrain, thresholds get tuned, data sources get added. If the configuration that produced an alert in March can’t be identified in December, the institution can’t account for a decision it has already made and closed. This is a records problem more than a modelling one, and it’s usually discovered late. 

1. Explaining generated text rather than scores: A drafted narrative reads as confident whether or not it’s grounded in the case data. If a summary states that funds arrived from three high-risk jurisdictions, the reviewer needs to reach those three transactions from inside the case file. Explaining a score means disclosing inputs. Explaining a narrative means demonstrating provenance, which is a different technical requirement and a newer one. 

1. Explanations built on unreliable records: When the same customer exists twice under variant spellings, or country data arrives in three formats from three systems, the model reasons correctly over wrong inputs. The resulting explanation is internally coherent and factually meaningless. Entity resolution and country standardisation are prerequisites for explainability. 

1. The translation gap: Technical attributions don’t belong in case files. A weight of 0.31 on a feature means nothing to a reviewer; a description of the behaviour that weight represents means everything. Where the platform doesn’t bridge this, analysts do it individually, which is slow and produces inconsistent documentation across a team. 

1. Retrofitting cost: Explainability depends on what the system captured at the moment of decision. A platform that didn’t record contributing factors at alert creation can’t reconstruct them afterwards. This is why explainability is a selection criterion rather than a roadmap item, and why “it’s coming next release” is not a satisfactory answer during procurement. 

How to Evaluate AML Software for Explainability 

Seven questions, about twenty-five minutes of a demo. They separate the best AML software from the well-marketed kind faster than a feature matrix. 

1. Open a real alert and show me why it fired, Contributing factors, ranked, in the screen an analyst uses daily. Not a slide about explainability. 

1. Show me a closed alert from a previous model version, This tests reproducibility. Ask what is retained, whether the configuration in force at the time is identifiable, and whether the institution can retrieve it without vendor intervention. 

1. What documentation supports independent validation? Methodology, training approach, performance monitoring, known limitations. Ask to see the package before signing rather than after. 

1. Where’s the boundary between rules and models? A clear line makes the system easier to validate, tune and defend. Vendors who can’t draw it usually can’t explain either side. 

1. What are the auto-close criteria, and who reviews them? Ask for the configuration screen, not a description of it. 

1. Can an analyst trace a statement in an AI-generated summary back to source case data? For any platform that drafts narratives, this is the question fewest vendors are ready to answer. 

1. If our users can configure their own agents, show me the testing and approval process – Ask how prompts, tools, data access and workflow changes are versioned; what test cases are required; who approves deployment; how overrides and errors are monitored; and whether a complete decision log can be exported for audit. 

How Velocity Fits In 

Velocity’s transaction monitoring runs as a hybrid, using rules-based logic, AI and machine learning, or a combination, so prescribed scenarios stay as readable rules while models handle behavioural detection. 

Velocity iInvestigate’s AI Investigators automate the investigation, not the decision. They assemble customer, account, transaction, counterparty, screening and prior-case context; analyse patterns and anomalies; and produce a detailed, explainable report for human validation. Where an institution chooses to enable an AI recommendation, the recommendation, confidence and rationale remain visible, while the compliance team retains authority for the final disposition. 

The models are built on open-source foundations and deployed within a controlled environment, allowing each implementation to be tailored to the institution’s products, customer base, transaction behaviour, scenarios and risk policies. Institutional data remains segregated rather than being used to train or enrich another client’s model. 

In relevant client workflows, investigation time has fallen from approximately one to two hours to under ten minutes for cases within the configured investigation scope. This represents a reduction of more than 83 percent and approaches 92 percent against a two-hour baseline, supporting at least six times the potential case-processing capacity before accounting for human review, quality assurance and case complexity. 

Underneath, Entity Resolution merges fragmented customer records into a single profile and Country Resolution standardises country data across systems, removing a category of alerts that were never explainable because the underlying records were wrong. 

Every investigation retains the evidence trail needed to understand what the AI reviewed, what it found and how its output was produced. The platform can be deployed in the cloud or on-premise, which matters where security architecture and data-residency requirements apply. 

If you want to understand how this could work inside your institution, give me a shout. My team and I would be happy to facilitate a short discovery session, followed by a focused demo. We love showing the software, but, more importantly, we love showing how it can fit the way your compliance team actually works. 

Frequently Asked Questions 

Let’s close with questions that have come up in real AI Investigator and AML software discussions. I have framed them in the language used by different types of financial institutions because the operating concern changes slightly by sector, even when the underlying governance principle does not. 

1. If an examiner selects one alert, what exactly should we be able to reproduce?

A question I heard from a digital banking client. 

You should be able to show the alert inputs, contributing factors, applicable rule or model, configuration and version in force, evidence used by the investigation, AI-generated output, human review or changes, and final disposition. A current explanation of how the system generally works is not enough; the institution needs the historical explanation for that specific alert. 

2. Do we have to use only simple models if we want the system to remain explainable?

A question I heard from a regional bank evaluating behavioural transaction monitoring. 

No. Interpretability belongs to the model; explainability belongs to the complete system around it. A hybrid platform can keep prescribed scenarios as readable rules while using more sophisticated models for behavioural detection, provided that their inputs, limitations, outputs, versions and alert-level reasons are documented and available for challenge. 

3. We process very high payment volumes. Will explainability actually reduce false positives?

A question I heard from a high-volume payments client. 

Not by itself. Explainability exposes why alerts are firing, allowing tuning teams to identify weak features, thresholds, data issues and scenario combinations rather than reacting only to an aggregate false-positive rate. It also reduces the time spent on false positives that remain because the reason for the alert and the supporting evidence are already available at triage. 

4. Can an AI Investigator close alerts automatically, or must a person make every decision?

A question I heard during an insurance-sector implementation discussion. 

The safest primary operating model is investigation-only: AI produces a detailed, explainable and audit-ready report, while a human decides whether to close, escalate or investigate further. An institution may configure controlled automation for defined low-risk outcomes, but the criteria should be explicit, approved, tested, monitored and reproducible for every alert. Automation does not transfer accountability to the software provider. 

5. Our analysts can configure their own AI agents. How do we prove those agents were tested properly?

A question increasingly raised by banks and payment companies considering self-service agent builders. 

Treat every material agent configuration as a controlled change, not as an analyst preference. Define the agent’s purpose and boundaries; version its prompts, tools and data access; test it against representative and adversarial cases; establish measurable acceptance criteria; obtain independent approval; and retain complete execution and decision logs. If the institution cannot reconstruct which configuration produced an output, the agent is not ready for regulated use.