When a compliance team buys AI-assisted screening or monitoring, accountability for the AI's output stays with the institution, not the vendor. The Financial Stability Board's draft Sound Practices make that explicit, with a dedicated practice on third-party AI risk. For a lean AML team, "the vendor handles the model" is turning into an evidence burden the buyer has to carry.
The FSB's Sound Practices for the Responsible Adoption of AI were published as a consultation report in June 2026, and the consultation has since closed. They are not yet final, so treat the detail as firm direction, not settled rule, and watch for the final version.
This guide is written for CCOs, CTOs and heads of AML who are buying AI-assisted tools for AI in AML compliance and need to know what evidence they must hold for each AI-assisted control, whoever built the model.
What are the FSB's Sound Practices for AI?
A set of twelve practices for the responsible adoption of AI in finance, covering governance, risk management, data, explainability, human oversight and third-party risk.
The FSB's consultation report, published on 10 June 2026, sets out twelve sound practices. They run across strategic direction and oversight, governance and accountability, AI in the risk-management framework, organisational adaptability, materiality and risk assessment, model selection, data governance, explainability and transparency, performance management, human oversight, cyber and ICT risk, and third-party risk management. As Skadden's analysis notes, the consultation has closed and the FSB is expected to consider feedback before finalising, so the practices are a strong signal of the global direction, not yet a binding standard.
Why does the third-party practice matter most for AML?
Because most lean AML teams buy their AI rather than build it, so the third-party practice is the one that governs their situation directly.
Sound Practice 12 addresses third-party AI risk. It asks institutions to expand vendor due diligence, strengthen contractual protections, monitor the provider, and plan an exit, and it flags risks of performance, transparency, data quality, supply-chain and concentration, and business continuity. The crucial point sits in the FSB's framing of the accountability gap: an institution remains accountable for AI outcomes even when it did not build the tool in-house. Buying the model does not transfer the responsibility for what it does. This mirrors the shared-responsibility model that BSP applies to outsourced AI providers under its own AI governance principles, which our work on AI in AML and on vendor model governance covers, and it is the same logic our guide to rules-based versus AI monitoring applies to the detection question.
How does this line up with Southeast Asian regulators?
The direction is converging. The FSB sets the global frame, MAS has consulted on detailed AI risk-management guidelines, and BSP has already issued dated AI governance principles.
Three standard-setters are moving the same way. The FSB's twelve practices are the global reference. MAS has consulted on proposed guidelines for AI risk management, which remain at consultation stage. BSP issued its AI governance principles in a dated 2026 memorandum, applying a shared-responsibility model to outsourced providers. The principles are described as supervisory expectations, not a hard deadline. For a BSP-supervised institution, the practical reading is that third-party AI accountability is already an expectation, and the global and regional detail is filling in around it. None of the three lets a buyer point at the vendor when the model is wrong.
What evidence does a buyer need for each AI-assisted control?
A materiality assessment, a performance-monitoring record, a human-oversight record, and the third-party due-diligence and contract file, held for each AI-assisted control.
The practices translate into a concrete evidence pack. For each AI-assisted control, a lean team should be able to produce four things, mapped to the practices below.
This is the same evidence discipline an examiner already expects for monitoring and testing, extended to the model. Our guides to independent testing and to who checks the auditors describe what a defensible record looks like.
What should a buyer ask an AI vendor now?
Ask for the documentation that lets you build the evidence pack, and the contract terms that let you keep it current.
The practices give a buyer a checklist against any AI-assisted tool. Ask how material uses are classified and what controls follow. Ask how the model is validated, how performance is monitored, and what you will receive to evidence it. Ask how a human reviews or overrides an output, and whether that is logged. And ask for the contract terms on documentation access, audit rights, monitoring, and exit, because the third-party practice is only as good as what the agreement lets you see. Our AML software buyer's guide lists the wider questions, and our build versus buy framework weighs the accountability that comes with each route.
How does Fyscal ARCX support the evidence pack?
Fyscal ARCX is built so that the institution holds the record its accountability requires. The Admin Control Center lets compliance leadership govern each AI function and keeps the audit trail, so human-oversight and configuration decisions are logged. Transaction Monitoring holds the calibration and dry-run history that supports performance evidence, and Case Management keeps each determination with its reasoning and approver, so an AI-assisted suggestion that a person confirmed is traceable to the person. The evidence an examiner or a board asks for is retrievable from one place.
If you want to see what the four-part evidence pack looks like for an AI-assisted control, book a walkthrough of Fyscal ARCX and bring your AI governance policy to test it against.