Why a non-binding FSB consultation is worth building a program around anyway
The Financial Stability Board's 2026 consultation on sound practices for AI adoption is, by FSB's own design, non-binding — the FSB isn't a supervisor and can't issue enforceable rules. What it can do, and reliably has done with past guidance, is set the template that FSB member-jurisdiction supervisors then fold into their own frameworks. Treat "non-binding" as a timing advantage, not an excuse to wait: institutions that build to this structure now are building to what RBI, MAS, and other regulators are likely to converge on regardless of exactly when each jurisdiction formalises it.
So what: don't wait for your home regulator to mandate FSB alignment. By the time they do, the institutions that started early will have a two-year head start on evidence.
Domain 1 — the board has to own AI risk, not just receive a report on it
The first four practices put accountability at board level: approved risk appetite, documented accountability chains down to a named owner for every significant AI system, AI risk folded into existing enterprise risk management rather than siloed separately, and governance frameworks built to evolve as fast as the technology does.
So what: if your board's AI oversight consists of an annual update slide, that's not oversight under this framework — it's notification. Build a recurring board cadence specifically for AI risk, with reporting on incidents and near-misses, not just a project status update.
Domain 2 — the lifecycle practices are where most institutions are furthest behind
Practices 5 through 10 cover materiality classification, model selection documentation, data governance, explainability, performance management, and human oversight — the operational core of AI governance. The explainability practice is the one we see institutions underinvest in most: it requires actual comprehension testing for consumer-facing systems, not a technical explainability report that nobody outside the model team can read. A credit-denial explanation that satisfies a model validator and confuses the customer it's meant to serve fails this practice even if the documentation looks complete.
So what: test your customer-facing explanations on actual customers, or a representative proxy sample, before you call the explainability requirement satisfied. Internal sign-off by your own model team isn't evidence of comprehension.
Domain 3 — third-party and concentration risk is the practice most banks haven't built controls for at all
The last two practices cover AI-specific cyber risk — prompt injection, model poisoning, agent persistence attacks acquiring unauthorised capabilities — and third-party AI governance, including an explicit requirement to assess concentration risk from hyperscaler and foundation-model dependency. Vendor accountability cannot transfer regulatory responsibility: if your core banking AI runs on a single foundation-model provider and that provider has an outage, the FSB's framework holds you accountable for having assessed that dependency in advance, not just for having a vendor contract.
So what: map which of your critical AI systems depend on a single foundation-model or cloud provider, and build a documented fallback plan for each one. If you can't answer "what happens to this system if this vendor is unavailable for 48 hours," you haven't satisfied this practice.
Where India's regulators are heading, and why it matters even before any single framework is final
RBI's Draft Model Risk Management guidance already parallels the FSB's lifecycle practices — board-approved policy, model inventory, independent validation, explainability, human oversight, and third-party vendor accountability map onto FSB Practices 5 through 12 reasonably directly. IRDAI's AI working group has explicitly referenced global approaches including the FSB's emerging guidance in its own scoping work, and SEBI's public signalling points toward alignment with both IOSCO's AI principles and the FSB's direction. None of this is coincidence — India's regulators have consistently built sectoral AI guidance within the G20 AI Principles framework that India's own 2023 presidency helped shape, and FSB alignment is the natural next layer on top of that foundation.
So what: if you're already building toward RBI's draft MRMF requirements, you're most of the way to FSB alignment as well. Map the overlap explicitly in your governance documentation rather than treating each framework as a separate compliance project — that mapping is itself evidence of governance maturity an examiner will recognise.
A four-point action checklist
- Establish a recurring board-level AI risk reporting cadence, including incidents and near-misses, not an annual summary slide.
- Run actual comprehension testing on customer-facing AI explanations before marking the explainability practice as satisfied.
- Map every critical AI system's dependency on a single foundation-model or cloud vendor, and document a fallback plan for each.
- Build one governance evidence base mapped simultaneously to RBI's draft MRMF and the FSB's 12 practices, rather than running parallel compliance tracks.
Related Articles
All 12 FSB Sound Practices. Mapped. Evidenced. Board-ready.
Zytra maps your AI model inventory, lifecycle controls, explainability documentation, and concentration risk assessment to all 12 FSB Sound Practices — and simultaneously to RBI MRMF, MAS 2026, SR 26-2, and 10 other regulatory frameworks.
Talk to sales