AML model validation is the independent check that a monitoring or screening model does what it claims, before and after it goes live. For a model that is partly AI, validation adds tests for drift, bias and explainability to the usual below-the-line and above-the-line work. A lean team can do it, with a documented method and an independent reviewer.
Supervisory expectations on AI are converging but still mostly principle-level. The specifics below follow standard-setter statements and the BSP's own AI governance memorandum; confirm the current requirements with your supervisor and the Compliance Advisory Lead before relying on them.
This guide is written for heads of AML, model owners and compliance officers at lean teams who buy or tune AI-assisted monitoring and have to evidence that it works.
What is AML model validation?
It is the independent assessment of whether a model is conceptually sound, correctly built and performing as intended, documented well enough for a reviewer to reproduce the conclusion.
Validation is the discipline that separates a model you can defend from one you merely trust. For a transaction monitoring or screening model it covers three questions. Is the design sound for the risk it addresses? Does it perform against a stated baseline on a population like yours? And does it keep performing once customer behaviour and typologies change? The work should be done by someone independent of the team that chose or built the model, and recorded so a reviewer can follow it later. This is the same evidence standard an examiner applies to any control, which our guide to independent testing sets out.
What do standard-setters now say about AI in monitoring?
That AI should complement traditional monitoring, not replace it, that a person makes the final suspicious-transaction decision, and that outputs must be explainable.
The Basel Committee's AML/CFT supervisory newsletter, BCBS Newsletter No. 37 of 19 October 2026, summarises a supervisory stocktake and an industry workshop on AI in transaction monitoring. It states that AI systems must complement traditional approaches, not replace them. Human involvement stays critical for validating models, reviewing alerts and deciding on suspicious transaction reports, and explainability is essential for regulatory compliance. It names poor-quality data and algorithmic bias as key obstacles. The workshop material dates from 2024 and the newsletter is a supervisory summary, not binding guidance, so treat it as a neutral benchmark for governance evidence, not a rulebook.
How does BSP's AI governance memorandum apply to validation?
It asks institutions to run risk interventions across the model lifecycle, including an independent validation step, and keeps accountability with management whatever the model recommends.
BSP's Memorandum M-2026-031, Governance Principles for AI in Financial Services, dated 24 June 2026, sets out the STARS principles. It asks institutions to build their own AI governance frameworks, with risk interventions across the model lifecycle. Under its accountability principle, management stays responsible for decisions despite AI recommendations. The memorandum is voluntary, but BSP describes the principles as minimum supervisory expectations and applies a shared-responsibility model to outsourced providers, which matters when the model is a vendor's. Our note on the FSB's sound practices for vendor AI covers the third-party side of that responsibility.
What does a validation method look like for a lean team?
A sequence a small team can run: baseline, below-the-line and above-the-line testing, shadow running, bias and drift checks, and a documented sign-off.
The method does not need a data-science department. It needs discipline and a record.
State what the model is compared against, on a population similar to yours, before claiming any improvement. A claim without a baseline is not a result.
Test the alerts the model would suppress below its threshold and the alerts it raises above it, to size what it misses and what it adds, the same calibration logic our threshold tuning guide applies to rules.
Run the model on live transactions without letting it generate alerts, so its behaviour is visible before it touches the analyst queue.
Check the training data for the biases the BCBS newsletter names, and confirm the data is complete and correct, because a model inherits the quality of what it learns from.
Confirm that an analyst can say which inputs drove a given alert, and that a reviewer can reproduce that reasoning from the case record months later.
Record the model version, the tests, the results and the independent approver, and repeat the review on a schedule.
AI-specific
AI-specific
How is validating an AI model different from validating a rule?
The core tests are shared, but an AI model adds drift, bias and explainability, because it learns from data and can change behaviour over time.
A fixed rule does the same thing until someone changes it, so validation confirms it fires as written. A model trained on data can degrade as behaviour shifts, can carry bias from its training set, and can be hard to explain. Those three additions are the AML-specific part of model validation, and they are why a model needs monitoring after go-live, not just a one-time test. The choice between the two approaches, and where each fits, sits in our comparison of rules-based and AI transaction monitoring.
What should a lean team get right first?
An independent reviewer, a stated baseline, and a documented sign-off, before any sophistication in the model itself.
Three things carry most of the value. First, make the validation independent, even if that means one colleague checks another's work, because a model validated by its own builder is not validated. Second, insist on a baseline, so performance claims mean something. Third, document the version, tests and approver, so the evidence exists when an examiner asks. A small team rarely has a model-risk function, so the honest move is to keep models assistive, where a person still decides, until the data and the validation capacity are in place. The buyer's guide covers the questions to ask a vendor before any of this.
How does Fyscal ARCX support model validation?
Fyscal ARCX is built so that the evidence a validation needs is produced as the system runs. A compliance team defines its own variables and scenarios and tests them against historical data before activation, which is the below-the-line and above-the-line step. Scenario and model changes are versioned, and each alert carries the reason an analyst reads, which supports the explainability test. One case per customer holds the disposition and the approver, so an independent reviewer can reconstruct a decision. The scope of any AI-assisted features should be confirmed with the team before a validation relies on them.
Frequently asked questions
- AML/CFT supervisory newsletter, BCBS Newsletter No. 37, Basel Committee on Banking Supervision, 19 October 2026
- Governance Principles for Artificial Intelligence (AI) in Financial Services, BSP Memorandum No. M-2026-031, Bangko Sentral ng Pilipinas, 24 June 2026 (copy hosted by a law firm)