FSB AI Sound Practices Final Report: A Governance Gap Analysis

On 15 October 2026 the Financial Stability Board (FSB) published the final report on its FSB AI sound practices: twelve practices for the responsible adoption of artificial intelligence by financial institutions, released alongside an overview of the roughly 160 responses to the June consultation. Its operative request goes to boards and senior management, which the FSB strongly encourages to reference the twelve practices when developing and refining their institution’s AI governance, risk management and control frameworks. No return, template or compliance date is attached.

For governance and compliance teams, the useful material sits below the headline list. The report spells out what an AI documentation record can contain, separates the materiality of an AI use case from its risk, lists six common forms of human oversight, and sets out the contract terms and notifications it expects institutions to seek from third-party AI providers. The final text also expands its treatment of agentic AI, meaning autonomous agents that can plan and execute multi-step tasks.

The practical use of the report is as a gap analysis. The legal requirements and supervisory expectations an institution can be examined against still come from its own jurisdiction: the EU AI Act and DORA, the Monetary Authority of Singapore’s AI supervisory guidelines, prudential model risk and outsourcing rules. The twelve practices give a common structure for checking whether the evidence behind those requirements and expectations is complete.

Related reading: FSB AI Sound Practices: Consultation Closes, Final Report Next

FSB AI sound practices: the dates around the final report

• 10 June 2026: the FSB publishes the consultation report on sound practices for responsible AI adoption.
• 22 July 2026: the consultation closes.
• 6 August 2026: the FSB publishes the public (non-confidential) responses.
• 12 October 2026: the FSB publishes its Chair’s letter to G20 Finance Ministers and Central Bank Governors; the accompanying release says that focusing on safe adoption of AI across the financial system will remain an important feature of the FSB’s agenda next year.
• 15 October 2026: the final report and the overview of consultation responses are published.

The final report contains no implementation date and no request to report progress to the FSB. The forward commitment it does make is general: as AI technologies and applications evolve, the FSB will monitor developments and update the sound practices as necessary. Any date that applies to an institution comes from local law or supervisory guidance, covered in the mapping section below.

What the final report commits a firm to, and what it leaves alone

The FSB describes the twelve practices as a practical toolkit that institutions can tailor to their context and risk profile and fold into existing frameworks, including those for cyber and third-party risk. The report then sets three limits on its own reach. It states that the practices do not establish an international standard, that they do not prescribe how institutions should adopt AI, and that applying them does not absolve an institution of its obligations under local legal and regulatory requirements related to AI adoption. The inside cover adds the FSB’s standing Charter wording: its activities, including any decisions reached in their context, shall not be binding or give rise to any legal rights or obligations.

Two readings of that status both go wrong. One treats non-binding as irrelevant, although the report is addressed to boards and senior management and says the practices also aim to promote coordination, cooperation and information-sharing among financial institutions, supervisors and other stakeholders, within and across jurisdictions. The other treats the practices as a checklist that, once ticked, discharges AI obligations. The FSB rules that out in terms, and the legal instruments in the mapping section below contain requirements the FSB text does not, such as the EU AI Act’s duty to inform people subject to certain high-risk systems.

Proportionality is built in. Each institution is expected to weigh relevance and applicability against its business model, complexity, role in the financial system, structure, size and the extent of AI use in critical or material functions, and lower-risk use cases may warrant only the relevant practices, or modified ones.

The case studies need the same care. They range from an agentic system at a large internationally active bank that proposes new fraud detection rules for human approval to a credit union that chose a highly explainable model so it could tell members which factors drove a preliminary assessment. The FSB states that they are illustrative only and do not represent expected outcomes or benchmarks for any institution, so a case study figure quoted in a board paper as a target misreads the document.

The twelve practices at a glance

The report organises the practices into two groups. Sound Practices 1 to 4 cover organisation-wide AI governance and are designed to be cross-cutting. Sound Practices 5 to 12 cover the AI lifecycle: practices 5 to 10 relate to particular stages of development and deployment, while practices 11 and 12 apply across all stages.

Section 3.1 of the report gives an illustrative seven-stage lifecycle: inception, design and development, verification and validation, deployment, operation and monitoring, re-evaluation, and retirement. The FSB is explicit that there is no standard, one-size-fits-all set of stages, and that institutions may use their own lifecycle processes or adopt the stages set by other regulation, guidance and standards. A footnote gives the NIST AI Risk Management Framework as an example, with a four-stage lifecycle of plan, design, develop and deploy.

What changed between the June consultation and the final text

The final report retains a proportionate, principles-based framework that financial institutions can adapt to their contexts and risk profiles. The substantive edits are narrower:

• Board and senior management: the final report clarifies their respective roles and explains how smaller institutions can apply the governance practices by using existing roles and external expertise.
• Documentation: Sound Practice 3 now makes clear that effective documentation should support accountability, traceability and the reconstruction of actions, particularly for agentic AI use cases.
• Explainability and transparency: Sound Practice 8 was refined to give more weight to transparency for higher-risk and higher-materiality use cases and to its role in engagement with supervisory authorities.
• Performance: the final Sound Practice 9 places express emphasis on independent performance assessment for high-materiality or high-risk use cases and on real-time monitoring where dynamically acting AI warrants it. The June consultation already discussed using subject-matter experts to evaluate generative AI (GenAI) performance.
• Third parties: the final Sound Practice 12 makes the identification of material embedded AI explicit and elaborates on sub-outsourced activities and wider AI supply-chain dependencies. Third-party concentration risk and exit planning were already covered in the June consultation.
• Agentic AI: the risk discussion was updated and the practices now include specific considerations for highly autonomous AI, plus a new agentic case study.

The final report discusses correlated behaviour and systemic dependencies arising from common AI models, data and infrastructure. Its twelve sound practices focus on governance and risk management within individual financial institutions. The report also describes sound practices specific to agentic AI and multi-agent systems as nascent and potentially requiring fuller treatment as understanding of these technologies develops.

Board and senior management: Sound Practices 1 to 4

Sound Practice 1 puts AI inside the risk appetite. The board and senior management set boundaries for AI adoption when they set and review risk appetite and tolerance; the report’s examples include criteria for adopting high-risk or high-materiality use cases and prohibitions on specific uses, such as fully automated decision-making in critical business areas where the assessed risks exceed appetite. AI adoption is also aligned with the institution’s conduct standards, which inform decisions on explainability, human oversight and redress for specific use cases.

A footnote spells out the management information (MI) the board receives: business plans, risk reports including high-risk uses, performance reports, failures and mitigation actions, and audit reports, with adoption metrics such as time savings and staff uptake as possible additions. The MI should let the board assess whether the institution’s approach, including previous decisions not to adopt AI for certain use cases, remains aligned with strategy and risk appetite. A rejected use case is part of the record.

Sound Practice 2 builds on existing structures such as the three lines of defence. First-line functions assess outcomes, controls, materiality and risk for their use cases, and specific first-line executives may be designated as accountable for high-materiality or high-risk use cases. The second line keeps an organisation-wide view of AI risk and independently assesses or validates first-line work. The third line provides assurance proportionate to materiality and risk.

The narrow point inside Sound Practice 2 concerns AI that watches AI. Where one AI model or system monitors the performance and risks of another, the report expects the monitoring AI to be independent of the system under review. It does not define how that independence is demonstrated. Control functions, for their part, are expected to stay objective and functionally separate from development teams and business users.

Sound Practice 3 is covered in the next section because it carries the documentation detail. Sound Practice 4 asks institutions to learn and adapt: foundational AI training for all staff, role-specific expertise for developers, validators, risk managers, auditors and compliance teams, targeted oversight training for the board and senior management, and the preservation of human expertise so that staff can still operate when AI tools are unavailable, degraded or producing incorrect outputs. It also asks institutions to treat relevant anomalies, drift events and near-misses as triggers to assess and, where needed, refine controls.

A footnote on terminology matters for groups operating across jurisdictions. The report uses “board of directors” and “senior management” as labels for distinct decision-making functions and acknowledges that legal frameworks differ, including jurisdictions where the board mainly supervises the executive body and has no executive functions. Mapping the FSB’s board-level expectations onto a group’s actual committee structure therefore involves interpretation, and the report leaves that step to the institution.

The AI inventory and documentation record

The documentation list in Section 2.3 is the most directly usable part of the report for compliance teams, because it describes the record a reviewer would ask for. The FSB lists documentation and lifecycle records that can include:

• a description of the use case: underlying models or systems and the rationale for their selection; approved, intended or prohibited applications; and whether it was built in-house, uses open-source tools or was acquired from a third-party AI provider;
• the materiality and risk of the use case and its mitigants;
• business lines, regions, products, customers and market participants affected;
• key assumptions and limitations;
• data sources used during inference and, if developed in-house, training data;
• allocation of accountability, meaning the use case owner and other key roles;
• dependencies on other AI uses, models, systems, critical data sources, third-party AI providers, cloud services or fallback arrangements;
• lifecycle stage and status;
• findings from testing, ongoing monitoring and performance assessment;
• information related to validation or independent review; and
• relevant information from third-party AI providers, such as acceptable use policies or model and system cards.

The report expects institutions to protect these records from unauthorised modification or deletion and, if possible, to make them immutable or keep immutable copies, especially where they contain critical information. A footnote provides the proportionality release: documentation may not involve documenting every use case to the full extent described, especially those that are much less material.

For GenAI, the report adds prompt versioning and version control that allow rollback to earlier configurations, and chain-of-thought logging to help explain outputs. Separately, a footnote warns that natural-language explanations generated through chain-of-thought prompting may not accurately represent the factors causing a model’s behaviour. Such explanations should not be treated as authoritative records of the model’s reasoning without additional validation. This qualification should be distinguished from the separate discussion of logging and retaining lifecycle records.

Agentic AI gets its own record-keeping test, built on visibility and traceability. Visibility means assigning each AI agent a unique identifier so the institution can see which actions it took and which humans configured and oversaw it, and so agents can be told apart from human users and other ICT systems. Traceability means being able to follow what triggered an action, what information and tools the agent accessed, what steps it took and whether it acted within its permissions. As agent use scales, the report expects a risk-based approach to logging that focuses on actions, decisions and steps able to affect the risk profile.

The inventory case study in the same section describes some large internationally active banks running centralised, software-supported AI inventories, and observes that some banks with more limited AI adoption rely on spreadsheets. Where banks deploy agents, it lists extra inventory attributes: agent-specific identifiers, the tools the agent can access, its components and its guardrails, and in more mature organisations an agent’s “certified” status and permitted scope. An inventory keyed only by model would not show which agents share a model but hold different permissions.

Materiality and risk are assessed as distinct concepts under Sound Practice 5

The report treats materiality and risk as related but different concepts, and the distinction changes how a use case is tiered. Materiality is the importance of the use case to the institution’s viability, its critical operations and its ability to meet key legal and regulatory obligations, including obligations towards customers. Consistent with other FSB publications, the assessment considers four factors: financial, operational or strategic importance; the tolerance for disruption of the operations supported; the nature of the data used for training or accessed to produce outputs; and substitutability, including the availability and cost of equivalent models or systems.

Risk is the potential harm the use case may cause to the institution or its customers. The report’s example is precise: a highly autonomous agent performing a low-materiality task, or operating in a contained training environment, could cause significant harm if it acts outside defined boundaries or escapes that environment. A tiering method that only asks how important the supported process is will under-rate that agent. The risk dimensions listed include the AI’s autonomy, capabilities, complexity and access to systems and sensitive data; cyber and ICT vulnerabilities, data and third-party dependencies, explainability, reliability and susceptibility to degradation; the feasibility of human oversight and the level of reliance on outputs; and relevant legal and regulatory requirements.

Both inherent risk (before mitigation) and residual risk (after mitigation) are assessed for each use case, and assessments are dynamic. Materiality is reassessed at regular intervals and at milestones such as a decision to scale a use case into critical operations, which the report links to institutions often starting AI in non-critical areas and scaling later. Risk assessments are generally repeated periodically or after events such as incidents or performance degradation, and a reassessment can move a use case to a higher or a lower tier.

For agentic AI, the FSB asks institutions to agree a risk tolerance for each agentic use case at inception, which informs how much autonomy and access the agent receives. Its most practical sentence for change control is about permissions: the risks of an agent’s access to tools and systems may compound multiplicatively, not additively, as permissions expand. When extending an agent’s access, the report expects institutions to consider the combined risks of the new and existing access together. A change ticket that evaluates only the new permission in isolation does not follow that approach.

Selection, data and explainability: Sound Practices 6 to 8

Sound Practice 6 opens by noting that institutions have the ultimate choice of whether to adopt AI for a given use case at all. Where they do, the selection stage decides between in-house development, third-party procurement, open-source or open-weight tools, or a combination, and between traditional AI, GenAI, agentic or other models. The cost assessment is meant to be total: commercial, computing, energy, financial and staffing costs, the potential for usage costs to rise rapidly as adoption scales, and the cost of business continuity and contingency planning with third-party providers. After selection, the report expects documented change management across the lifecycle, particularly for high-materiality or high-risk use cases.

Sound Practice 7 defines fit-for-purpose data as accurate, complete, consistent, reliable and secure. The operational detail with the widest reach concerns data the institution sends out as well as data it trains on. The data governance framework is expected to cover prompts, internal documents or other context the institution provides to a third-party tool, and tools that access the institution’s data to produce outputs, for example a tool built on a large language model (LLM) that uses retrieval-augmented generation (RAG) over confidential or sensitive data. The report asks for procedures for proper use of RAG, such as confirming that retrieved and ingested data are secure, representative and trusted. For agents, it asks institutions to separate an agent’s goals, permissions and rules from the data it can reach, and to apply access controls, classification and retention requirements to all data accessible to the agent wherever that data sits.

Sound Practice 8 treats explainability as a continuum. Limited explainability can be acceptable in some uses: the report gives fraud detection as an example where superior predictive power may warrant a less explainable model, while AI heavily relied on for credit decisioning, insurance underwriting and other activities with potentially high customer impact may warrant greater explainability. Where explainability is constrained, it lists compensating controls: guardrails such as stricter limits on permissible use cases, benchmarking or challenger models, sensitivity and stress testing, enhanced data governance, more extensive validation and testing, and increased human oversight. If compensating controls cannot bring the risk within appetite and tolerance, the institution considers alternatives such as a more explainable AI or a non-AI model, even if performance is inferior.

The transparency half of Sound Practice 8 contains a qualification that is easy to over-read. The report says appropriate transparency may include telling end-users that they are interacting with AI, that AI might materially influence decisions affecting them, that the system has limitations, and what rights they have to explanations, contestability or redress. It adds that appropriate transparency does not necessarily entail disclosing AI use to end-users in all circumstances. A footnote notes that, depending on the jurisdiction and the type of decision, fully automated decisions may not be permitted at all. That flexibility belongs to the FSB text; a binding regime can remove it, as the mapping section shows for EU credit scoring.

Testing and human oversight a reviewer can evidence: Sound Practices 9 and 10

Sound Practice 9 asks institutions to specify thresholds for every relevant performance dimension, separating acceptable performance from results that warrant further investigation or indicate significant issues. The dimensions named are accuracy, range of output, robustness, stability, and sensitivity or stress testing. Where possible, thresholds are defined before the AI generates outputs (ante hoc), which the report calls generally preferable to deciding after the fact what counts as acceptable. High-materiality and high-risk use cases are expected to be subject to independent assessment by dedicated validation staff or others tasked with independent review.

Ongoing monitoring includes testing on data not used in training, checking for data or model drift, confirming the scope of activity stays within designated parameters, and red-teaming. Compensating controls such as output overlays may be appropriate when results disappoint, but the report notes that in many cases they are temporary until underlying issues are addressed. For GenAI, where there may be no ground truth, subject-matter experts may act as evaluators. For agents, monitoring covers interim steps and interactions as well as final outputs, and the results serve as a key basis for deciding whether to grant an agent more autonomy.

Sound Practice 10 defines effective oversight as meaningful: the humans involved have sufficient ability, authority and incentive to intervene, as opposed to nominal or tick-the-box oversight. The report’s risk section names the misconception directly. The assumption that human involvement ensures effective oversight is listed alongside the assumptions that AI behaves predictably and nearly always produces correct output. Under this practice, a loan file showing a human signature on every AI recommendation is only part of the evidence. The report also asks for incentive alignment against automation bias, such as performance metrics that reward the quality of oversight decisions, tracking of when humans override AI recommendations, and assessment of whether overseers are providing effective oversight.

The report lists six common forms of oversight, which can be combined or used at different lifecycle stages, without treating the list as closed:

• human-in-the-loop: human approval of all decisions made by AI;
• AI-in-the-loop: AI used as a supporting layer within human oversight, such as AI-generated alerts that humans monitor and act on;
• human-on-the-loop: intervention periodically, or only where necessary;
• human-in-command: high-level oversight that sets the extent of autonomy and the guardrails, aimed at highly autonomous AI such as agents;
• kill switch: mechanisms to halt or constrain AI operations, from complete shutdown to graduated degradation back to human operation;
• contestability: mechanisms for human appeal and redress of AI outputs.

Responsibility for monitoring a use case after deployment goes to staff who were not part of its design and development, and responsible staff at each lifecycle stage are documented, for example in responsibility matrices. For agents, the report pairs human oversight with deterministic controls implemented as code in the control plane: prohibited actions, risk-based triggers for human approval such as financial transactions above a certain value or actions that may cause irreversible harm, and tested kill-switch mechanisms. These controls constrain behaviour but do not by themselves resolve who is accountable for an agent’s actions, so institutions assign and document accountable individuals for each agentic use case and seek contractual clarity from third parties, including on legal liability.

Cyber, ICT and third-party AI: Sound Practices 11 and 12

Sound Practice 11 asks institutions to adapt existing cyber and ICT risk management to AI. The listed measures include monitoring, preventing and remedying “shadow AI” (tools adopted by staff without authorisation or for unapproved uses), secure-by-design practices, identity and access management with phishing-resistant multi-factor authentication, defence in depth, and prompt but secure patching, with compensating controls such as virtual patching where patches are not yet available. The report names the OWASP Machine Learning Security Top 10, MITRE ATLAS and NIST AI 100-2 E2025 as specialist sources on AI-specific threats, and for agents it applies least privilege as “least agency” alongside zero-trust principles.

On testing, the report expects AI cyber and ICT risks to be included in scenario testing and exercises, especially for high-materiality or high-risk use cases, and cites the UK Cross-Market Operational Resilience Group, whose 2026 Dynamic Scenario Library introduced AI and cyber ICT scenarios. On threat-led penetration testing (TLPT), the language is tentative: there might be potential to incorporate AI scenarios and tools in future, but further work is needed on the ethical, legal and practical implications. That is a statement about possible future work and does not amount to an expectation that current TLPT programmes include AI.

Building on existing third-party risk publications, including the FSB’s own December 2023 toolkit and the Basel Committee principles covered in our BCBS third-party risk principles explainer, the FSB expects contracts with third-party AI providers to enable monitoring rights; access, audit and information rights; provisions on data access, quality and security, including responsibility for updating data and disclosure of processing jurisdictions; business continuity obligations; and termination rights. Contractual arrangements are also expected to address disclosure and notification of data usage, sharing and retention, material changes affecting AI behaviour, permitted and prohibited use, training approaches, service availability, underlying technology dependencies, and changes to services, including non-AI services with embedded AI elements, that may alter risk profiles after deployment. Where relevant, contracts clarify accountability for model performance, model drift, service degradation, version updates and service discontinuity, including liability for actions taken by highly autonomous agents.

Two qualifications in Sound Practice 12 change how assurance files are read. Certifications such as ISO/IEC 42001, which requires a third-party audit, can provide partial or supporting evidence, but the report says they may not be sufficient by themselves to meet an institution’s due diligence and monitoring responsibilities. And embedded AI is in scope: institutions are expected to identify material AI components in third-party tools and services that are not explicitly marketed or sold as AI-enabled, and to reflect material dependencies in concentration risk management and contingency planning, even where the AI functionality arrives after the contract was signed. If sufficient assurance cannot be obtained, the listed compensating controls include extra pre-deployment testing, limiting initial use to low-materiality and low-risk use cases, more intense human oversight, and warranties and indemnities; where no satisfactory compensating control brings the risk within appetite, the institution may decide not to use the provider’s model.

Concentration monitoring is expected at institution and group level across cloud and compute providers, data providers, energy providers supporting AI infrastructure, foundation-model developers, specialised AI service providers and hardware suppliers. For third-party AI used in high-materiality or high-risk use cases, the report expects concentration considerations in business continuity planning and exit strategies, and contingency planning more generally considers AI-related incidents, cloud disruption, foundation-model degradation, vendor discontinuation and infrastructure failure.

In the EU, much of that third-party record already has a regulatory home. DORA requires financial entities to maintain a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers, using templates set by Implementing Regulation (EU) 2024/2956; our DORA register of information guide covers the templates. My working reading is that a third-party AI service delivered under such an arrangement already falls within the register as an ICT service. The FSB’s embedded-AI point asks something a contract-level register may not show by itself: which registered ICT services now carry material AI functionality, including functionality added after contracting.

Mapping the FSB AI sound practices to local rules and supervisory guidance

Because the FSB practices are non-binding, the gap analysis must distinguish applicable legal requirements from supervisory guidance in each jurisdiction. The dates below include legally binding application dates for EU regulations and supervisory expectation dates for the MAS Guidelines.

The EU AI Act overlaps with the FSB practices most closely in its deployer obligations for high-risk systems. Annex III point 5(b) covers AI systems used to evaluate the creditworthiness of natural persons or establish their credit score, with an exception for systems used to detect financial fraud, and point 5(c) covers risk assessment and pricing in relation to natural persons for life and health insurance. Article 26(2) requires deployers to assign human oversight to natural persons with the necessary competence, training and authority, which sits close to Sound Practice 10’s “ability, authority and incentive”. Article 26(11) requires deployers of Annex III systems that make or assist decisions about natural persons to inform those persons, which is firmer than the FSB’s flexible transparency language.

For high-risk AI systems under Annex III points 5(b) and 5(c), Article 27 requires a fundamental rights impact assessment before first deployment. Under Article 27(3), the deployer must also notify the market surveillance authority of the assessment results using the template referred to in Article 27(5), subject to the notification exception in Article 46(1). The assessment must be updated where relevant circumstances change. Our EU AI Act compliance guide for financial institutions sets out those duties in full.

Two AI Act provisions follow the same logic as the FSB’s message about integrating AI into existing frameworks. Under Article 26(5), for deployers that are financial institutions subject to internal governance requirements under Union financial services law, the monitoring obligation is deemed fulfilled by complying with those governance rules. Under Article 26(6), deployers must retain automatically generated logs under their control for a period appropriate to the system’s intended purpose and of at least six months, unless applicable Union or national law provides otherwise. Financial institutions subject to qualifying Union financial-services governance requirements maintain those logs within the documentation kept under the relevant financial-services law. For an EU bank, the FSB’s documentation record and the AI Act’s log retention can therefore sit in the same governance documentation set.

In Singapore, MAS has finalised its AI Risk Management Guidelines, which establish supervisory expectations rather than a new binding regulation. The FSB’s reference list cites the MAS consultation paper of November 2025, while MAS issued its final Guidelines on 7 October 2026, applying to all financial institutions and all forms of AI technologies; our MAS AI risk management guidelines explainer covers the phasing.

For other jurisdictions, the FSB’s own footnotes are a useful map of where it expects existing rules to carry AI risk. The report cites these documents against specific practices:

The table records what the FSB cites. It does not say that any of these documents was written for AI or that each applies to every institution type: PRA SS1/23 applies to specified UK-incorporated banks, building societies and PRA-designated investment firms with regulatory-capital internal model approval; it does not apply to every UK bank merely because of its title. Insurers, asset managers and other institutions must assess the rules and supervisory guidance applicable to their own activities.

Frequently Asked Questions

We use AI only through a vendor chatbot and an embedded feature in our core banking software. Does the FSB expect the full twelve-practice framework?

The report allows smaller and less complex institutions, and lower-risk use cases, to apply only the relevant practices or to modify them. It also notes that smaller institutions might be primarily deployers of third-party AI, whose ability to manage AI risk may need to rely on assurance and information from providers. In my reading, that position puts most of the weight on Sound Practice 12 and the documentation record in Sound Practice 3, and the embedded feature counts: the report expects material AI components in tools not marketed as AI-enabled to be identified.

Can an EU lender rely on the FSB’s statement that transparency does not always require disclosing AI use?

Not for a credit-scoring system within Annex III point 5(b) of the EU AI Act once the high-risk rules apply. Article 26(11) requires deployers of Annex III systems that make or assist decisions about natural persons to inform those persons, and the FSB states that applying its practices does not absolve an institution of local legal requirements. The FSB flexibility is relevant where no binding disclosure rule applies.

Our AI provider holds ISO/IEC 42001 certification. Does that close the third-party file?

The report treats certification as partial or supporting evidence that may not be sufficient by itself, and says that depending on the circumstances further due diligence or ongoing monitoring may be appropriate. The certificate is one document in the file; contract terms, notification rights and the institution’s own testing still need to be evidenced.

Do the agentic AI considerations carry the same weight as the rest of the report?

They appear in the final report, whose introduction describes sound practices specific to agentic AI and multi-agent systems as nascent and potentially warranting fuller treatment in future. Recording that status in policy documents that rely on those passages avoids presenting them as settled.

Will the FSB assess or peer-review institutions’ adoption of the practices?

The final report and the press release state that the FSB will monitor AI developments and update the practices as necessary; neither announces any monitoring of how institutions implement them. The FSB’s 12 October 2026 release on its Chair’s letter says safe AI adoption will remain an important feature of its agenda next year. Anything beyond that would be speculation.

Does a model that monitors another model need to come from a different vendor?

The report’s requirement is independence of the monitoring AI from the system under review, without specifying vendor separation as the only way to achieve it. How independence is shown, whether through a different provider, a different model family or separate ownership and configuration, is an interpretation the institution would need to document.

Related Articles

• FSB AI Sound Practices: Consultation Closes, Final Report Next: the June 2026 consultation, the 22 July close and the public responses published before the final report.
• MAS AI Risk Management Guidelines: Inventory First, Controls by 2028: the Singapore guidelines issued on 7 October 2026 and their phased 2027 and 2028 dates.
• BCBS Third-Party Risk Principles: DORA and Outsourcing Rules: the Basel Committee’s December 2025 third-party principles that the FSB cites for third-party AI risk.
• SS2/21 Outsourcing: The PRA Register and Notification Guide: the UK outsourcing and third-party expectations listed in the FSB’s references.

Key Takeaways

• Gap analysis owner: assign one function to hold the practice-by-practice map of local rules, supervisory guidance and evidence for every jurisdiction in the group.
• Inventory perimeter: give embedded vendor AI and each agent its own entry, owner and lifecycle status.
• Tiering method: assess materiality and risk as distinct concepts, documenting inherent and residual risk and considering agent autonomy and access when determining appropriate controls.
• Agent access changes: approve against the combined permission set and name the accountable individual in the approval.
• Oversight file: override logs, reviews of overseer effectiveness, and a post-deployment monitor independent of the build team.
• Vendor renewals: test contracts against the FSB notification list, covering behaviour changes, training approaches, data retention and embedded AI.

Sources and References

• Financial Stability Board, Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final report, 15 October 2026: publication page and PDF
• Financial Stability Board, Sound practices for financial institutions’ responsible AI adoption: Overview of consultation responses, 15 October 2026: publication page and PDF
• Financial Stability Board, FSB finalises sound practices for the responsible adoption of artificial intelligence (AI), press release, 15 October 2026: fsb.org
• Financial Stability Board, Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Consultation report, 10 June 2026: fsb.org
• Financial Stability Board, Public responses to the consultation, 6 August 2026: fsb.org
• Financial Stability Board, FSB Chair sets out FSB work on AI and stablecoins (release on the Chair’s letter to G20 Finance Ministers and Central Bank Governors), 12 October 2026: fsb.org
• Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 6, 26, 27, 46, 111 and 113 and Annex III (as amended by Regulation (EU) 2026/1744): EUR-Lex
• Regulation (EU) 2026/1744 (Digital Omnibus on AI): EUR-Lex
• European Commission, AI Act FAQ on the Digital Omnibus timeline: digital-strategy.ec.europa.eu
• Regulation (EU) 2022/2554 (DORA), Article 28(3): EUR-Lex
• Commission Implementing Regulation (EU) 2024/2956 on the register of information templates: EUR-Lex
• European Banking Authority, Preparation for DORA application (DORA applicable from 17 January 2025): eba.europa.eu
• Monetary Authority of Singapore, MAS Sets Out Supervisory Expectations on Responsible AI Adoption by Financial Institutions, 7 October 2026: mas.gov.sg
• Monetary Authority of Singapore, Guidelines on Artificial Intelligence Risk Management for Financial Institutions: mas.gov.sg
• Bank of England, Prudential Regulation Authority, SS1/23 Model risk management principles for banks (version history and scope): bankofengland.co.uk
• Bank of England, Prudential Regulation Authority, SS2/21 Outsourcing and third party risk management (version history): bankofengland.co.uk

Putting the twelve practices to work before the local dates arrive

For EU deployers of AI systems classified as high-risk under Annex III points 5(b) and 5(c), the relevant Chapter III high-risk obligations generally apply from 2 December 2027, subject to Article 111’s transitional arrangements. Under Article 111(2), systems placed on the market or put into service before that date generally become subject to those obligations only if they undergo significant design changes from that date. A separate compliance deadline of 2 August 2030 applies to high-risk systems intended to be used by public authorities. Other provisions of the AI Act have earlier application dates, and classification also requires consideration of Article 6.

For Singapore financial institutions, the MAS Guidelines set supervisory expectations from 7 October 2027, with Sections 5 and 6 expected by 7 October 2028, and DORA’s ICT and third-party obligations already apply. The artifact to produce now is a mapping document that takes each of the twelve practices, distinguishes applicable binding requirements from supervisory expectations and non-binding guidance in each jurisdiction where the group operates, and lists the evidence held for each, starting with the AI inventory and the documentation fields in Sound Practice 3.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.