What actually changed in November 2025, and again in March 2026

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. There is no small-fintech carve-out in the current text. 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 Guidelines don't scale their expectations down for that reality. Proportionality gets referenced in MAS's supervisory approach generally, but "we're small" isn't a defense against "we didn't know what our vendor's model was doing with our customer data."

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.

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. That's a reasonable ask, and MAS may soften some prescriptive language in the final Guidelines. 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."

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 five Guideline areas (oversight, governance, policy, lifecycle controls, third-party risk) 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?

They apply to all financial institutions regulated by MAS, which includes fintechs, payment institutions, and capital markets intermediaries alongside banks and insurers. The third-party AI risk management provisions apply regardless of institution size, so a smaller fintech is expected to meet the same oversight standard as a large bank, even without a dedicated model risk team.

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 consultation paper in November 2025 and announced an industry AI Risk Management Toolkit partnership in March 2026, signaling this is an active, evolving program rather than a finalized rule with a fixed compliance date. Institutions shouldn't wait for a final effective date; the practical move is to inventory current AI use now and map it against the five Guideline areas before enforcement expectations firm up.