The FSB's Final Report on 12 Sound Practices: A Materiality and Risk Perspective

The final report published by the Financial Stability Board (FSB) on October 15, 2026 lists twelve “sound practices.” The FSB states that the order of the practices does not indicate priority. It describes a proportionate approach to implementation, with the methods and level of detail tailored to the institution’s size and each use case’s materiality and risk.

This article focuses on Sound Practice 5, “Materiality and risk assessment,” and its relationship to the other practices, drawing on the original text of the final report (PDF). We examine who decides how detailed documentation should be, the scope and frequency of validation, and the form of human oversight—and what those decisions are based on.

We look at how Sound Practice 5 connects to documentation (Sound Practice 3), selection (Sound Practice 6), explainability (Sound Practice 8), performance management (Sound Practice 9) and human oversight (Sound Practice 10). Cyber and ICT risk (Sound Practice 11), third-party AI (Sound Practice 12), and the board and the allocation of roles (Sound Practices 1, 2 and 4) are touched on only insofar as they relate to materiality.

The Final Report: Scope and Status

According to the FSB’s published materials, the final report, “Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final report,” was published on October 15, 2026. The consultation report published on June 10, 2026 received around 160 responses. The “Overview of consultation responses,” published alongside the final report on October 15, summarizes the comments received and the main changes made in the final version.

The twelve practices fall into two groups. The first four concern organization-wide AI governance: the role of the board and senior management, the governance framework and allocation of roles, incorporation into the risk management framework and documentation, and organizational adaptability. The remaining eight concern lifecycle management, from the development of AI through to its retirement: materiality and risk assessment, selection of the technology, data, explainability, performance management, human oversight, cyber and ICT risk, and third-party AI.

The report does not establish an international standard or prescribe a uniform way of adopting AI. It also explains that it is not intended to influence business decisions on whether to adopt a particular AI technology. Nor does it relieve institutions of their obligations under local laws and regulations. The case studies, too, are described as illustrative only, and not as representing expected outcomes or benchmarks.

According to the overview document, the main changes in the final version are as follows.

• Documentation (Sound Practice 3): clarifies that documentation should support accountability, traceability and the reconstruction of actions (particularly for agentic AI)
• Explainability and transparency (Sound Practice 8): places greater emphasis on transparency in higher-risk and higher-materiality use cases
• Performance management (Sound Practice 9): expands the discussion of independent validation
• Human oversight (Sound Practice 10): adds considerations for addressing the challenges posed by GenAI and agentic AI
• Third-party AI (Sound Practice 12): broadens the description to cover embedded AI and sub-outsourcing
• Agentic AI: introduces additional considerations. The overview document notes, however, that these were not fully consulted on, are distilled from the responses received, and may evolve.

The changes are presented here on the basis of the FSB’s overview document. We have not compared the full texts of the consultation draft and the final version.

Connecting Materiality and Risk Assessment to Each Control

The wording of the twelve practices listed in the annex refers to materiality or risk in several places.

• Sound Practice 3: include processes for materiality and risk assessment in the risk management framework
• Sound Practice 5: assess materiality and risk at the inception stage and thereafter
• Sound Practice 6: consider materiality and risk when selecting AI models or systems
• Sound Practice 9: evaluate performance proportionately to materiality and risk
• Sound Practice 10: make human oversight relevant to materiality, risk, autonomy, complexity and explainability

MIF recommends using the materiality and risk assessment as an input to decisions on how detailed documentation should be, the scope and frequency of validation, and the form of human oversight. Applicable laws and regulations, existing internal policies and the organization’s defined risk tolerance should be checked alongside it. Revisit the assessment as you refine the model selection and controls, and incorporate findings from post-deployment monitoring and review.

Materiality and Risk Are Distinct but Related

The key point in Sound Practice 5 is that the report distinguishes materiality from risk as related but different concepts. The report explains that, in practice, the two may be assessed within a single process. It then states that both assessments are relevant in deciding the controls appropriate to a use case (including guardrails) and the form and level of human oversight.

What Materiality Measures

According to the report, the materiality of a use case refers to how important that use of AI is to the financial institution’s viability, the continuity of its critical operations, and its ability to meet key legal and regulatory obligations, including obligations to customers.

The report lists the following four aspects to consider in the assessment.

• Importance: the financial, operational or strategic importance of the use case to the institution (including any critical operations or core business lines that rely on it)
• Tolerance for disruption: the tolerance that applies to disruption of the operations supported by the use case (whether set by the institution, by financial authorities or by standard-setting bodies)
• Data: the nature of the data used for training, or that the AI may access to produce its outputs (including data shared with a service provider)
• Substitutability: whether the underlying models or systems (and their providers) can be replaced, and the availability and cost of alternatives with equivalent capabilities

The report also says that AI can support critical operations in a range of ways, from narrow administrative tasks such as automated document sorting to being essential to how those operations function.

What Risk Measures

Risk refers to the potential harm to the financial institution or its customers. The report identifies the following factors that can create or amplify risk:

• The AI’s autonomy, capabilities and complexity, the extent of its access to systems and sensitive data, and its scope of action
• Cyber and ICT vulnerabilities, data dependencies, explainability, reliability, substitutability, susceptibility to performance degradation, and third-party and supply chain dependencies
• The feasibility of human oversight and the level of reliance on the AI’s outputs
• Relevant legal and regulatory requirements

The report describes assessing both inherent risk, before mitigation, and residual risk, after mitigation.

Low Materiality Does Not Mean Low Risk

The report states explicitly that a use case can pose high risk even if it is not material. The example it gives is a highly autonomous AI agent performing a low-materiality task: if such an agent acts outside its defined boundaries, or escapes a contained training environment, it could cause significant harm.

In our view, this distinction can be overlooked in practice. If only materiality is considered, and the conclusion is that “this is a supporting internal task, so light controls will do,” an agent with broad permissions can end up with controls that do not match those permissions.

MIF recommends recording not only the results of the materiality and risk assessments but also the rationale for each. Keeping separate fields for each in a use case inventory is one way to do this. Where an overall rating is used, the original assessments and their rationale should remain traceable.

Both Assessments Can Change

The report also says that materiality may change over time. It explains that financial institutions often start using AI in non-critical operations and, as they gain experience, extend its use to critical operations. For that reason, it describes reassessing materiality not only at inception but also at regular reviews and when deciding to scale up use.

According to the report, risk is also reassessed periodically, because technology and its use change quickly. Assessments are repeated upon events such as the detection of incidents or performance degradation, and as a result a use case’s risk tier can change.

There is one more point for agentic AI. The report notes that as an agent’s permissions expand, the risks associated with its access may compound in ways that go beyond simple addition. When adding a new permission, the overall risk is assessed in combination with the existing permissions, not for the new permission alone.

Which Controls Does the Assessment Inform?

The table below summarizes how the report connects materiality and risk assessments to other practices.

Practice	What varies with materiality and risk	What the report says (summary)
Sound Practice 3: Documentation	Rigor of processes, level of detail in records	Gives as an example streamlined processes for low-materiality, low-risk use cases and rigorous processes for higher-materiality or higher-risk ones. Records are made more detailed where needed. A note says that not every use case needs to be documented to the same extent, especially those that are much less material
Sound Practice 6: Selection	Whether to develop AI in-house or procure it; the type of AI selected	Materiality and risk are among the factors considered in selection. The most complex model is not always the most appropriate; a simpler, more explainable one may be sufficient
Sound Practice 8: Explainability	The importance of compensating controls	Controls that make up for limited explainability (what the report calls compensating controls) are particularly important in high-materiality or high-risk use cases. If the risk still cannot be brought within tolerance, a more explainable AI or a non-AI model is considered, even if its performance is inferior
Sound Practice 9: Performance management	Frequency, scope and type of assessment; tolerance for errors	Material or high-risk use cases may justify higher performance requirements and a lower tolerance for errors. Particularly for high-materiality or high-risk use cases, assessment is carried out by independent staff, such as dedicated validation staff
Sound Practice 10: Human oversight	Form of oversight	Chosen in light of materiality, risk, technical feasibility, proportionality, resource effectiveness, and legal and supervisory considerations. Several forms can be combined, and different forms can be used at different stages

There is one more passage in Sound Practice 10 worth noting. The report states that effective oversight means humans having sufficient ability, authority and incentive to intervene, as opposed to oversight that is nominal or driven by “tick-the-box” compliance. Even if the form of oversight is chosen to match materiality and risk, it means little unless that oversight can actually function.

Sound Practice 12 also gives an example involving third-party AI. When sufficient information and assurance are unavailable, one possible compensating control is to limit initial use to cases with both low materiality and low risk.

The relationship between assessment and controls does not run in one direction only. Suppose residual risk is assessed as low because human approval requirements and limits on what the AI can access or do in connected systems are in place. Reducing those controls on the grounds that risk is low would change the basis of that assessment.

MIF recommends documenting the controls that each residual-risk assessment relies on and reassessing risk whenever those controls are changed or scaled back.

An Insurer’s Agent Case Study: The Materiality of Delegated Tasks and the Level of Autonomy

The report describes an insurer taking a cautious approach to delegating more material tasks to agents and increasing their autonomy. What follows summarizes the report’s description; the case study is illustrative only and is not a benchmark or an expected outcome.

A large life insurance company has begun using AI agents in its consumer claims processing. The agents handle manual tasks such as receiving and storing claims information, making initial assessments and responding to customers. Because this is the company’s first use of agents in the consumer space, it is described as proceeding with particular caution.

The insurer originally planned to use agents provided by a third party, but decided to build its own to achieve greater transparency and control. It developed standards and procedures covering levels of autonomy (minimal, constrained, full), permissioning and access, prohibited activity, triggering conditions and other topics.

The report describes how, during initial testing in a protected environment, agents could be induced to attempt unauthorized access to databases and systems. One case involved an attempt to delete certain data files. The insurer responded by adding controls over permissions and access.

In production, the agents operate with constrained autonomy. Each is registered and tracked individually, granted only the minimum permissions needed, and monitored continuously. The logs include intermediate decisions and steps.

According to the report, the insurer does not plan to delegate more material tasks or give agents greater autonomy until it has spent more time reviewing and analyzing their activity, including near-misses and unexpected problems.

MIF highlights two dimensions of expansion in this case: the materiality of delegated tasks and the level of agent autonomy. The insurer is holding off on increasing either while further review continues.

What to Record for Each Use Case

The table below lists the information MIF recommends recording for each use case, drawing on Sound Practice 5. Adapt it to your institution’s size, applicable regulations and risk tolerance.

Item	What to record	Relevant settings, records and processes (examples)
Materiality	Operations supported, tolerance for disruption, data handled, substitutability, rationale for the assessment	Use case inventory; records of discussions between the business unit and the risk management function
Risk	Risk before mitigation (autonomy, systems and data the AI can access, explainability, feasibility of oversight), controls adopted, residual risk after mitigation, and the rationale for each	Risk assessment; permission settings (check the product’s own settings and the limits set in connected systems separately)
Triggers for reassessment	Expansion into critical operations, added permissions or tools, changes to or scaling back of controls, incidents, performance degradation	Change management procedures; internal operating rules
Controls adopted in light of the assessment	Level of detail in documentation, scope, frequency and independence of validation, form of human oversight, compensating controls where explainability is insufficient	Internal risk management policies; the validation function’s work plan
Roles and responsible staff	Owner of the use case / staff responsible for post-deployment oversight and review (people not involved in design and development) / staff responsible for independent validation	Responsibility matrix; role definitions

For “Roles and responsible staff,” confirm who is responsible, and what independence is needed, for each of three roles: ownership of the use case, post-deployment oversight, and independent validation. Assigning post-deployment monitoring to staff who were not involved in design and development reflects the report’s description.

For each item, identify who makes the decision, where it is implemented or recorded, and how the system’s behavior is checked in practice. The same control often involves both product or system settings and internal operating practice.

Hypothetical Examples: Assessing Under Stated Conditions of Use

The following are MIF’s hypothetical examples of assessing materiality and risk under stated conditions of use. They are not a general classification standard, nor are they real cases from any particular institution.

Assumed conditions of use	Assessment in this example	What to check
Summarizing meeting notes that contain no confidential or personal information, in an approved environment, as drafts for staff. Not used for significant decisions, and work can be switched back to normal procedures	Low materiality; low risk	Reassess if the data, the scope of sharing or the way the output is used in decisions changes
Decisions on whether to lend to a customer and on what terms depend heavily on the model’s results	High materiality; high risk	Work out the impact on customers, how decisions are explained and reviewed, and the validation arrangements. Check whether the applicable rules permit fully automated decisions affecting customers
A routine task on which business operations do not heavily depend, performed by an agent with broad permissions to read confidential information, send data externally and modify records	Low materiality; high risk because of its permissions	Narrow the permissions to those needed, and check the effect of combining permissions

Each institution should determine its assessment criteria and controls in light of its risk tolerance and applicable regulations.

Practical Considerations

When applying this in actual operations, the following points should also be checked.

First, go beyond assigning a rating: check whether the controls underpinning it work in practice. The report, too, says that human oversight should be meaningful rather than nominal.

Second, check which definitions apply. The report notes that the terms corresponding to “critical operations” differ by jurisdiction (such as “important business services” or “critical or important functions”). Check which operations fall within scope under the laws and regulations that apply to your institution.

Third, consider how smaller institutions can implement the practices. According to the overview document, the final version explains how small financial institutions can adapt governance and risk management frameworks to their own circumstances by leveraging existing roles and external expertise. Smaller institutions can draw on existing arrangements to implement the controls their activities and risks require. Proportionate implementation does not mean institutions can disregard applicable obligations.

Fourth, as the overview document states, the additional considerations for agentic AI were not fully consulted on and may change.

Closing Thoughts

The FSB’s final report describes a proportionate approach to the twelve sound practices, taking account of each institution’s size and each use case’s materiality and risk. Sound Practice 5 treats materiality and risk as distinct but related concepts: a use case can have low materiality and still pose high risk.

MIF recommends treating materiality and risk as distinct but related dimensions, recording the rationale for each assessment and linking both assessments to the controls adopted. Even internal support tasks can pose different risks depending on the information handled and the permissions granted.

Use these assessments alongside applicable laws, regulations and internal policies to determine the appropriate documentation, validation and human oversight. Record which controls underpin each residual-risk assessment.

When the scope of an AI system’s work or its permissions changes, review both the change itself and how it interacts with existing permissions and controls.

Sources and Scope

This article draws primarily on the documents listed below, reviewed as of October 19, 2026. They may change, so please check the official materials from the issuing body for the latest content. The case study summary focuses on the points relevant to this discussion. Refer to the original report for details.

Key References

• Financial Stability Board, Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final report, 15 October 2026.
• Financial Stability Board, Sound practices for financial institutions’ responsible AI adoption: Overview of consultation responses, 15 October 2026.
• Financial Stability Board, press release, “FSB finalises sound practices for the responsible adoption of artificial intelligence (AI),” 15 October 2026.