Updated 19 Oct 2026: MAS issued the final Guidelines on AI Risk Management on 7 October 2026. They take effect on 7 October 2027, with Sections 5 and 6 due by 7 October 2028. See "What changed in the final guidelines (7 Oct 2026)" below.

What changed in the final guidelines (7 Oct 2026)

On 7 October 2026, MAS issued the final Guidelines on Artificial Intelligence Risk Management, together with a response to feedback on the November 2025 consultation, which closed on 31 January 2026. MAS says it kept the key expectations of the consulted version and refined them to address the feedback (MAS media release, 7 Oct 2026).

Status and dates, as MAS states them

• Issued: 7 October 2026.

• Takes effect: 7 October 2027.

• Phased: FIs should meet Sections 3 and 4 (AI oversight; AI identification, inventory and risk materiality assessment) from 7 October 2027, and Sections 5 and 6 (AI life cycle controls; AI capability and capacity) by 7 October 2028.

• High-risk use cases: MAS expects appropriate life cycle controls as soon as possible, not at the end of the transition period.

• The consultation had proposed a single 12-month transition period.

What changed from the consultation

• AI agents are explicitly in scope. The Guidelines apply to all FIs and all forms of AI, including Generative AI and AI agents (including multi-agent systems). Hybrid systems and AI in pilot or proof-of-concept are covered. Rule-based systems, and robotic process automation that follows fixed instructions without learning, would not ordinarily count as AI.

• A lighter path for low-impact AI. The proposed "integrated use" test is replaced by an impact test. If poor performance or unavailability of an FI's AI tools is unlikely to have a material adverse impact on the FI, its customers or other stakeholders, it may apply basic AI governance policies and procedures instead of the full Sections 3 to 6. MAS's examples include drafting or proofreading emails, summarising documents or meeting notes, and chatbots that help staff find internal policies.

• No mandatory AI committee. FIs may use existing governance structures where they provide adequate oversight and cross-functional coordination.

• AI inventory, "to the extent possible or practicable". FIs should keep an accurate inventory of AI use cases, systems or models, at a level of detail that fits the use case. For AI agents, MAS lists attributes such as agent-specific identifiers, the tools and systems the agent can access, its components and the guardrails imposed on it.

• Embedded and shadow AI. Identification should at minimum cover AI embedded in services from material third-party providers. Where some AI use can't be identified, FIs should assess the gap and put mitigating measures in place.

• Third-party AI. FIs remain accountable for AI provided by third parties. They should obtain sufficient assurance from providers, test third-party AI in the context of their own use cases (including with their own data), apply compensating controls where there are assurance gaps, and consider limiting, suspending or replacing the service if the risk can't be brought within risk appetite. Contract terms MAS lists include performance guarantees, data protection, the right to audit and notification when AI is introduced or updated.

• Monitoring for agentic workflows. Where relevant, monitoring should cover information flows and decision-making paths, such as reasoning processes, actions taken and tools used. For high-risk AI, MAS suggests "kill switches" or override mechanisms.

• More agentic AI guidance to come. MAS intends to consult the financial sector in 2027 on what additional guidance on agentic AI would be useful. In the meantime it points FIs to IMDA's Model AI Governance Framework for Agentic AI.

For the vendor-contract argument in the rest of this guide, the final text makes it stronger: it names the right to audit, notification of AI changes and testing on your own data as things an FI should consider before relying on third-party AI.

Background: the November 2025 consultation and the March 2026 toolkit

On 13 November 2025, the Monetary Authority of Singapore released a consultation paper proposing new Guidelines on Artificial Intelligence Risk Management, the first document of its kind aimed squarely at how financial institutions govern AI rather than just how they disclose using it. Four months later, on 20 March 2026, MAS announced it was partnering with industry to build an AI Risk Management Toolkit for the financial sector. Read those two dates together and the signal is clear: this isn't a one-off consultation that gets filed and forgotten. It's the start of an active supervisory program, with MAS expecting institutions to operationalize the Guidelines, not just acknowledge them.

The original consultation paper and its full text lay out five areas of supervisory expectation: oversight of AI risk management, governance, policies and procedures, AI lifecycle controls, and third-party AI risk management. The March 2026 toolkit announcement confirms MAS wants a shared, practical set of assessment tools institutions can actually apply, not another PDF that sits in a compliance folder. If you run technology, operations, or risk at a Singapore-regulated bank, insurer, or fintech, the practical question isn't "what does the paper say." It's "what do we need to change about how we buy, build, and deploy AI before this becomes enforceable."

How this relates to FEAT and why it isn't starting from zero

The new Guidelines are explicitly built to complement, not replace, MAS's 2018 FEAT principles (Fairness, Ethics, Accountability, Transparency), the framework MAS first introduced for AI and data analytics in financial services, as Protiviti's analysis confirms. If your institution has any existing FEAT-aligned governance from the Veritas initiative or your model risk management policy, you have a head start. The new Guidelines take the principle-level commitments of FEAT (be fair, be transparent, be accountable) and turn them into something closer to a control checklist: who owns AI risk, how it's assessed across the model lifecycle, and what happens when the model in question isn't yours. That last part is where most institutions' existing governance quietly stops working.

Who's actually in scope: banks, insurers, fintechs, or just the big players

The Guidelines apply to all financial institutions regulated by MAS, not just systemically important banks. Allen & Gledhill's legal analysis confirms the scope is broad by design: banks, insurers, capital markets intermediaries, and payment institutions are all covered, and the third-party AI risk provisions apply regardless of institution size. The final Guidelines apply to all FIs "in a proportionate manner, according to their size and risk profile". There is still no size-based carve-out, but there is now a lighter route based on impact (see below). That matters for a $10M revenue payments fintech or a mid-sized insurer running a lean compliance function differently than it matters for DBS or Prudential. A large bank has a model risk team that can absorb a new framework into an existing process. A 40-person fintech usually doesn't have a model risk team at all, it has a head of compliance wearing three hats and a CTO who picked the AI vendor six months ago because it shipped fast. The final text gives that fintech one real option. If poor performance or unavailability of its AI tools is unlikely to have a material adverse impact on the FI, its customers or other stakeholders, it may apply basic AI governance policies and procedures instead of the full Sections 3 to 6. But the test is impact, not headcount, and "we're small" still isn't a defense against "we didn't know what our vendor's model was doing with our customer data." US insurers face a similar vendor-accountability rule under the NAIC AI Model Bulletin.

The third-party AI risk management provision is the one that will actually bite

Most of the law-firm and consultancy summaries treat third-party AI risk as one bullet among five. It's the one that changes how you buy software. If your institution uses an AI vendor, an AI feature bolted onto a SaaS platform, or a foundation model API for anything customer-facing or credit-decisioning, the Guidelines expect you to demonstrate oversight of that AI's risk management, not just the vendor's uptime SLA or data processing agreement. Simmons & Simmons' framing makes the same point: the obligation to manage AI risk sits with the financial institution, and outsourcing the model doesn't outsource the accountability. EU-regulated firms face a parallel requirement under DORA's Article 28 rules for AI vendor contracts.

Here's the practical problem nobody selling you SaaS wants to say out loud: most commercial AI vendors cannot tell you, in supervisory-grade detail, what their model does with your data, how it was fine-tuned, what its failure modes are, or where inference happens. That's not a knock on the vendors, it's how most SaaS AI products are architected. You get an API, a dashboard, and a promise. Under FEAT-style principles that was a soft governance gap. Under lifecycle-control-based Guidelines with explicit third-party provisions, it's an audit finding waiting to happen.

The industry pushback on this is worth noting. ASIFMA's formal consultation response argued that firms should be allowed to assess AI risk materiality using their existing risk management frameworks rather than a wholly new regime layered on top. MAS did refine the final text in that direction: it replaced the proposed "integrated use" test with an impact-based one, and FIs may use existing governance structures instead of setting up a dedicated AI committee. But "materiality assessed under existing frameworks" still requires you to actually know what the vendor's model does. You can't assess materiality on a black box.

Build, buy, or self-host: which path actually satisfies the lifecycle controls

Self-hosting an open-source model on your own infrastructure, with zero data retention outside your environment, sidesteps most of the hardest third-party risk questions the Guidelines raise, because there is no third party in the loop for that specific system. This isn't the only answer, and it isn't free. But it's the honest answer to a question most vendor sales calls avoid.

Think through the lifecycle controls MAS is asking about: data lineage, model behavior under edge cases, versioning and change management, incident response when the model does something wrong. With a third-party SaaS AI tool, you're dependent on the vendor's documentation, their willingness to disclose model changes, and their contractual terms around data use, which you often can't verify independently. With a self-hosted open model running on infrastructure you control, you own the answer to every one of those questions because you built the pipeline that produces it.

That doesn't mean build everything from scratch. Most institutions don't need a custom model, they need a system where they control the deployment boundary: what data goes in, what leaves, how the model version is pinned, and how outputs are logged and reviewed. This is roughly the position Genta takes with regulated clients: for data-sensitive workloads, we run self-hosted open-source models on the client's own infrastructure with zero data retention, specifically because it removes the third-party attribution problem the Guidelines are pointing at. It's not the right call for every use case (a low-stakes internal drafting tool doesn't need this level of control), but for anything touching credit decisions, claims, KYC, or customer PII, it changes the compliance conversation from "trust our vendor" to "here's our architecture diagram." It's the same architecture we use when we build AI agents for banks, insurers and fintechs.

If you're weighing this decision on the US side of the business too, the compliance calculus is structurally similar to what's playing out under state-level AI rules and federal financial regulators; our guide to AI agents in financial services compliance covers the US equivalent of this exact build-vs-buy tension.

What to ask before you sign with an AI vendor under this framework

Before any AI vendor contract gets signed at a MAS-regulated institution, walk it through five questions the Guidelines effectively force you to answer anyway:

• Where does inference happen, and can you name the physical or cloud region?

• What data does the vendor retain, for how long, and can that be set to zero contractually, not just in a marketing page?

• Can the vendor produce a model change log, and will they notify you before a material model update?

• What happens when the model fails or hallucinates on a customer-facing decision, and who is accountable for the downstream harm?

• Can you actually audit the system, or are you relying entirely on the vendor's own attestations?

If a vendor can't answer these in writing, that's not automatically disqualifying, but it means you're accepting a category of third-party AI risk the Guidelines expect you to have already assessed. We put together a longer version of this exact line of questioning, applicable well beyond Singapore, in our AI vendor risk assessment checklist, which maps directly onto the due-diligence expectations MAS is describing.

A 90-day readiness sequence for a mid-sized FI or fintech

Don't start by rewriting your governance policy. Start by finding out what AI you're actually running, because most institutions underestimate this by a wide margin. Shadow AI, tools individual teams adopted without a formal review, is common enough that it deserves its own diagnosis before you touch the Guidelines at all; we've written about why this is a discovery problem more than an enforcement problem in our shadow AI governance guide.

A realistic sequence looks like this. Weeks 1 through 3: inventory every AI tool, feature, and vendor integration touching customer data, credit decisions, or regulatory reporting, including the ones procurement didn't formally approve. Weeks 4 through 6: map each one against the four sections of the final Guidelines (AI oversight; AI risk management systems, policies and procedures; AI life cycle controls, which include third-party AI; AI capability and capacity) and flag where you can't answer basic questions about vendor data handling or model versioning. Weeks 7 through 10: for the highest-risk gaps, decide per use case whether the fix is a better contract with the existing vendor, a switch to a vendor that can actually answer the audit questions, or a move to self-hosted infrastructure for that specific workload. Weeks 11 through 13: document the decisions and the reasoning, because MAS's supervisory approach rewards institutions that can show a considered process, not a perfect one.

This is the same diagnose-before-you-build sequence that applies to any regulatory shift touching AI, and the same one we'd recommend for a US-based FI tracking state-level AI laws; see our overview of how state AI laws are reshaping business compliance for the parallel pattern playing out stateside.

If you're working through this decision for your own institution, this is exactly what our Discovery phase maps out before any code gets written, and we're happy to compare notes.

Frequently asked questions

Do the MAS AI Risk Management Guidelines apply to fintechs, or only licensed banks and insurers?

Yes. The final Guidelines apply to all financial institutions, including fintechs, payment institutions and capital markets intermediaries alongside banks and insurers, and they apply in a proportionate manner according to size and risk profile. A fintech whose AI use is limited to low-impact assistive tools may apply basic AI governance policies and procedures instead of the full set. Either way, accountability for third-party AI stays with the institution.

What are the FEAT principles and how do they relate to the new MAS AI Guidelines?

FEAT (Fairness, Ethics, Accountability, Transparency) is the principle-level framework MAS introduced in 2018 for AI and data analytics in finance. The new Guidelines are built to complement FEAT, not replace it, translating those broad principles into specific expectations around governance, lifecycle controls, and third-party AI risk that institutions can be assessed against directly.

What does "third-party AI risk management" mean under the MAS Guidelines? Does using an AI vendor or SaaS tool count?

Yes. Any AI capability your institution doesn't build and run entirely in-house, including a vendor's AI feature, a SaaS product with an AI layer, or a third-party model API, falls under this provision. MAS expects the institution, not the vendor, to demonstrate oversight of that AI's risk management, which means you need visibility into the vendor's data handling and model behavior, not just a contract that says they'll take care of it.

Is self-hosted or open-source AI easier to make MAS-compliant than a third-party AI vendor?

For the lifecycle-control and third-party risk provisions specifically, yes, because self-hosting on your own infrastructure with zero data retention removes the third party from the equation for that system. It requires more upfront engineering than buying a SaaS tool, but it gives you direct answers to the audit questions the Guidelines raise, which a vendor's black-box model usually can't.

When do the MAS AI Risk Management Guidelines take effect, and what should a financial institution do before then?

MAS issued the final Guidelines on 7 October 2026 and they take effect on 7 October 2027. FIs should meet Sections 3 and 4 (AI oversight; AI identification, inventory and risk materiality assessment) from 7 October 2027, and Sections 5 and 6 (AI life cycle controls; AI capability and capacity) by 7 October 2028. MAS expects appropriate controls on high-risk use cases as soon as possible. The practical first step hasn't changed: inventory your current AI use, including AI embedded in vendor services, and assess its risk materiality.