Insights · FSB sound practices for AI
What do the FSB’s sound practices for AI mean for a bank deploying AI agents?
Claude Certified Services Partner(Anthropic)Direct answer. On 15 October 2026 the Financial Stability Board published its final report “Sound Practices for Responsible Adoption of Artificial Intelligence (AI)”: 12 practices that financial institutions are encouraged to consider, split into organisation-wide AI governance (practices 1 to 4) and risk management across the AI lifecycle (practices 5 to 12). The FSB says it “strongly encourages the board and senior management of financial institutions to reference the sound practices”. For a bank deploying AI agents, the practical consequence is a shared checklist: for each agent, be able to show its materiality and risk assessment, explainability, performance monitoring, human oversight and third-party dependencies in writing. The report describes the practices as non-prescriptive and not a binding international standard, and says that applying them does not absolve an institution from local legal and regulatory requirements; it does not replace FINMA, EU or US rules. S-PRO is a Zurich-based engineering partner; we are not a law firm and do not give legal advice.
01
What did the FSB publish on 15 October 2026?
The final report follows a public consultation on an earlier version published in June 2026, and an overview of consultation responses published the same day as the final report (FSB press release 14/2026). The FSB describes the result as “a practical toolkit that financial institutions can tailor to their specific context and risk profile”, and says it “will monitor developments and update the sound practices as necessary”.
The report notes that financial institutions have long used AI, and that rapid advances, particularly in generative and agentic AI, have drawn significant interest. It states that all 12 practices are generally applicable to all types of AI, while some are more relevant to specific technologies, for example those addressing risks from the autonomy of AI agents. It also says that practices specific to agentic AI and multi-agent systems remain nascent and may warrant more comprehensive treatment in future, and that the final report adds considerations for managing advanced risks of agentic AI. Those considerations sit inside the relevant practices (for example human oversight combined with technical controls, and agent-level record-keeping) rather than forming a 13th practice. The report also contains illustrative case studies; they are not prescriptive and we do not rely on them here.
02
What are the 12 practices?
Practice names are as shown on the FSB publication page and in the report’s Annex; the one-line descriptions are our short paraphrase of the Annex wording.
Swipe to compare →
| # | Practice (FSB name) | In plain terms |
|---|---|---|
| Group A: organisation-wide governance | ||
| 1 | Strategic direction and oversight | Board and senior management align AI use with business model, risk appetite and strategy |
| 2 | Governance and accountability | Clear roles and responsibilities and an appropriate governance framework |
| 3 | Incorporation of AI risks into risk management framework and effective documentation of AI use | Risk frameworks address AI risk; AI use is documented, including materiality and risk assessment |
| 4 | Organisational adaptability | Oversight, governance, risk practices and capabilities adjust as AI evolves |
| Group B: lifecycle risk management | ||
| 5 | Materiality and risk assessment | Assess each use case at inception and afterwards |
| 6 | Selection process | Choose models and systems against business objectives, operational and technical needs, and use-case materiality and risk |
| 7 | Data governance | Data fit for purpose for training, testing and using AI |
| 8 | Explainability and transparency | Know how explainability differs by AI type; where appropriate and feasible, use more explainable AI or compensating controls; give transparency suited to different stakeholders |
| 9 | Performance management | Proportionate assessment, testing and ongoing monitoring |
| 10 | Human oversight | Oversight scaled to the use case’s materiality, risk, autonomy, complexity and explainability |
| 11 | Cyber and ICT risk management | AI-related cyber and ICT risk, including, where appropriate, AI scenarios in tests and exercises |
| 12 | Third-party AI risk management | Dependency on third-party AI: performance, transparency, data quality, supply chain, concentration, business continuity |
03
Why does this matter more for AI agents than for a chatbot?
The FSB itself flags the point: it says highly autonomous agentic AI systems may act unpredictably or outside intended boundaries, with possible unauthorised or erroneous actions, data security incidents and disruption to connected systems. In the human-oversight practice (10) it describes combining human oversight with deterministic technical controls for agents, and in the documentation work (practice 3) it describes record-keeping that lets an institution attribute an agent’s actions and steps to that agent and check whether it stayed within its permissions.
The rest of this section is our reading, not an FSB statement: practices 8 and 10 are the ones an agent stresses hardest. An agent that calls tools and prepares or takes steps in a workflow has more autonomy than a model that answers a question, and practice 10 ties the level of human oversight to autonomy, materiality and explainability. Practice 12 matters because most agents rely on a third-party model provider, so model change, outage and concentration become business-continuity questions. Practice 5 matters because an agent’s materiality is set by what it is allowed to do, not by the model underneath.
04
How does a pilot map to the 12 practices?
A proof of concept usually produces evidence for some practices and leaves others open. The table below is S-PRO’s own working framework for a production gate, not an FSB list and not a compliance standard.
Swipe to compare →
| Practice | A pilot typically shows | What a production decision usually also needs |
|---|---|---|
| 5 Materiality and risk | A use-case description | Written materiality rating with owner, reviewed at defined points |
| 6 Selection | Why this model was tried | Documented comparison against objectives, risk and exit options |
| 7 Data governance | Sample data worked | Data sources, quality checks and access rules for live data |
| 8 Explainability | Outputs look sensible | Per-decision rationale linked to sources; reviewer can trace it |
| 9 Performance | A test-set result | Ongoing monitoring, sampled review, a change-control process |
| 10 Human oversight | A person reads the output | A defined approver the agent cannot bypass, with escalation rules |
| 11 Cyber / ICT | Sandbox security | Security review, access control, scenario testing of the live setup |
| 12 Third party | A vendor API key | Provider terms, concentration and continuity plan, fallback path |
Practices 1 to 4 (board oversight, accountability, risk-framework integration, adaptability) are institutional; a single pilot cannot evidence them, but it can feed them with a documented use-case record.
05
How does this sit next to FINMA, the EU and the US?
The FSB text is not national law and creates no obligation by itself; local rules stay decisive. Their relationship, as we read it:
Swipe to compare →
| Jurisdiction | Primary anchor | Relationship to the FSB practices |
|---|---|---|
| Switzerland | FINMA Guidance 08/2024 “Governance and risk management when using artificial intelligence” (18 December 2024) names model, data, IT/cyber, third-party, legal and reputational risks | Same risk families as practices 3, 5, 7, 8, 11 and 12 (our interpretation). The FSB does not make FINMA’s guidance binding or the reverse |
| EU (incl. Germany) | EU AI Act (legal obligations by risk class); DORA, Regulation (EU) 2022/2554, for ICT risk, including ICT third-party risk | Practices 5, 8, 9 and 10 echo the Act’s logic of risk classification, transparency and human oversight; practices 11 and 12 are the natural bridge to DORA. The FSB practices complement, and do not replace, the Act’s obligations. No application dates given here |
| United States | SR 26-2 “Revised Guidance on Model Risk Management” (17 April 2026), issued by the Federal Reserve with the OCC and FDIC; it supersedes SR 11-7 and SR 21-8 | Model-risk guidance is the nearest confirmed US anchor; the letter page does not mention AI, and we do not claim it covers generative or agentic AI. We found no single US AI rulebook confirmed from primary sources, so treat the FSB practices as a cross-border reference. We make no claim about SEC expectations |
Practical use for a cross-border bank: one internal control map organised by the 12 practices, with a column for each local rule that applies. For the EU legal side see EU AI Act compliant AI agents for banks.
06
What should a bank evidence per AI agent before production?
A short, agent-level record, built from the table above:
- Use case and materiality.Use-case description, owner and materiality rating, with date of last review (practices 3, 5).
- Permissions.What the agent may and may not do: tools, permissions, systems it writes to (practices 5, 10).
- Explainability.How its output can be explained and traced to sources (practice 8).
- Performance.Evaluation results and the ongoing monitoring plan (practice 9).
- Human oversight.Named human approver, escalation rules and override evidence (practice 10).
- Dependencies.Model and provider dependency, fallback and exit (practices 6, 12).
- Security.Security review and test of the live configuration (practice 11).
For an AML example of explainability and a human decision gate, see AI agents for AML and transaction monitoring in banks.
07
What should you ask a delivery partner?
- Which of the 12 practices will the pilot produce evidence for, and which remain with us?
- Who is the named approver for each decision type, and can the agent be technically prevented from bypassing them?
- Which model providers are involved, and what is the fallback if one is withdrawn?
- What do you hand over: logs, evaluation sets, documentation our risk function can read?
- Where does your own security management stand (certifications, scope)?
For a fuller treatment of the pilot-to-production step see Who can turn our AI proof of concept into a production system for a bank?
08
How does S-PRO help?
What S-PRO publishes today (s-pro.io): Zurich-based, founded 2014, 250+ engineers, R&D centers in Zurich and Łódź, ISO 27001 and ISO 27701 certified. S-PRO is a Certified partner in the Claude Partner Network. Our team includes Claude-certified engineers and architects.
S-PRO builds AI agents for banks and financial institutions with human approval steps and an audit trail; see AI agent development for banks and financial institutions. S-PRO does not claim to be “aligned with” or “certified against” the FSB practices; ISO 27001 and ISO 27701 are information-security and privacy management certifications, not AI-governance certifications.
Check which of the 12 practices your next pilot can evidence. Walk one agent use case through the production-gate table with an engineer. Book a discovery call (45 min)
09
How S-PRO helps with this
If you are a CIO, COO or Chief Compliance Officer planning to move an AI agent from pilot to production, S-PRO runs a 45-minute discovery call on one use case: we map it against the production-gate table above with your risk and compliance colleagues and scope the next step. Contact S-PRO, Löwenstrasse 45, 8001 Zürich.
10
Sources
- FSB, Sound Practices for Responsible Adoption of Artificial Intelligence (AI), final report, 15 Oct 2026: fsb.org (publication page); fsb.org (PDF)
- FSB press release 14/2026: fsb.org
- FINMA, Guidance 08/2024 release, 18 Dec 2024: finma.ch
- Federal Reserve, SR 26-2, Revised Guidance on Model Risk Management, 17 Apr 2026: federalreserve.gov
- Regulation (EU) 2022/2554 (DORA): eur-lex.europa.eu
All sources opened on 21 October 2026.
FAQ
Questions buyers ask us
What are the FSB's sound practices for responsible AI adoption?
Twelve practices published by the Financial Stability Board on 15 October 2026 for financial institutions: four on organisation-wide AI governance and eight on managing AI risk across the lifecycle, from materiality assessment to human oversight and third-party risk.
Are the FSB sound practices binding on banks?
The FSB frames them as a toolkit that it strongly encourages boards and senior management to reference. The report calls them non-prescriptive and not a binding international standard, and says applying them does not absolve an institution from local legal and regulatory requirements, which come from FINMA, EU, US or other rules.
Do the practices cover AI agents?
Yes, as part of the same 12 practices. The FSB says they apply to all types of AI, and its text adds considerations specific to agentic AI, such as combining human oversight with technical controls and keeping records that attribute an agent's actions. It also says practices specific to agentic AI remain nascent and may be treated more fully in future.
How do the FSB practices relate to FINMA Guidance 08/2024?
They address the same families of risk: model, data, cyber and ICT, and third-party. Neither makes the other binding. A Swiss bank still works to FINMA's guidance and uses the FSB practices as an international reference.
Does the FSB report replace the EU AI Act?
No. The AI Act sets legal obligations by risk class; the FSB practices are a non-statutory reference that echo similar themes such as risk assessment, transparency and human oversight.
What should a bank have ready before taking an AI agent into production?
A written materiality assessment, a defined human approver, explainable and traceable output, performance monitoring, a security review and a documented plan for dependence on its model provider. These are our recommendations, built on the FSB practices.
What are you building?
Contact
You will talk to engineers who build for banks, not to a sales script. Fill out the form and get an answer within one business day.
- Security and privacy firstISO 27001 and ISO 27701 certified.
- Claude Partner NetworkS-PRO is a Certified partner in the Claude Partner Network. Our team includes Claude-certified engineers and architects.
- Proven in regulated financeBanks, wealth managers and fintechs in Switzerland, the EU and the US.
Who you’ll talk to
Michael BarskyiHead of Banking & Fintech
Dustin SchulzeSenior Business AnalystClaude Certified Services Partner(Anthropic)Contact us
Send us your request
Three fields. Takes about a minute.