MAS AI Governance Banking Singapore 2026: AI Risk Management Guidelines, FEAT Principles Upgraded to Supervisory Expectations, AI Operationalisation Handbook

Singapore's AI governance trajectory is the one worth watching even where the exact dates are unconfirmed

MAS has moved faster on financial-services AI governance than almost any regulator we track, and the trajectory matters more here than any single publication date. The FEAT principles — Fairness, Ethics, Accountability, Transparency — arrived in 2018 as one of the first AI governance frameworks for financial services anywhere. Project MindForge, MAS's industry collaboration specifically on generative AI risk, launched in November 2022 with DBS, OCBC, UOB, and other major Singapore banks as participants — among the earliest regulator-industry efforts anywhere focused specifically on GenAI risk in finance, well ahead of most peer jurisdictions. Reporting indicates MAS has since moved to convert FEAT from aspirational guidance into supervisory-ready expectations with defined assessment criteria, a shift other regulators across Asia-Pacific are reportedly studying as a template.

So what: if you operate in Singapore, or benchmark against MAS as a regional reference point, don't wait for a specific document date to start treating FEAT as examinable rather than aspirational. The direction of travel has been clear since Project MindForge launched.

Fairness: a documented threshold, not a general intention

The 2018 version of Fairness was a general instruction not to discriminate unfairly. The direction MAS has been moving is toward firms testing for demographic bias across protected characteristics using named metrics — demographic parity, equalised odds — with pre-defined acceptable thresholds set before deployment, not assessed retroactively once a complaint surfaces.

So what: if your fairness testing doesn't produce a number against a threshold you set in advance, you don't have a fairness control. You have a fairness intention, and those don't survive an examination.

Accountability: a named person, traceable through the entire lifecycle

The accountability principle is moving toward requiring a named senior person for every significant AI system, with that accountability following the system through deployment, monitoring, and remediation — not transferring or lapsing once the system goes live. An AI system with no named accountable owner is, under this framing, itself an examination finding regardless of how well the system performs technically.

So what: audit your AI inventory for systems with no named accountable owner today. That's the fastest, cheapest fix on this entire list, and it's the first thing an examiner checks.

Transparency: the explainability bar depends entirely on who's asking

MAS's emerging approach draws a clear line between consumer-facing high-stakes decisions — credit, insurance, investment suitability — which need explanations an actual customer can understand on request, and internal or regulatory AI decisions, which need technical documentation sufficient for model validation and examination. These aren't the same deliverable, and treating them as interchangeable is where most institutions fall short: a technically rigorous model card satisfies the second standard and does nothing for the first.

So what: build two separate explainability outputs for every consequential AI system — one tested for actual customer comprehension, one built for technical/regulatory review — rather than assuming one document can serve both audiences.

Third-party AI governance: the vendor contract never transfers your regulatory accountability

MAS's long-standing Technology Risk Management framework already covers third-party technology risk, and its extension to AI-specific vendor governance follows the same principle that's held for years: the institution remains fully accountable for AI outcomes whether the system is built internally or bought from a vendor. Practical requirements include documentation access to a vendor's architecture and training-data description, audit rights or independent assessment reports for high-materiality vendor AI, contractual commitments on model-version-change notification with regression testing before any vendor update deploys, and exit provisions ensuring the institution can transition away from a vendor that becomes unavailable.

So what: if your vendor contract doesn't include a model-update notification clause and a regression-testing window before that update goes live in your environment, renegotiate it. A silent model update that changes your AI's behaviour without notice is a control failure on your side, not the vendor's, under this framework.

India-Singapore operations need one governance core, not two parallel programs

SBI Singapore operates under a full Qualifying Full Bank licence, which means its trade-finance and retail AI — supporting a substantial India-ASEAN trade corridor — has to satisfy MAS's governance expectations for its Singapore-facing operations while maintaining separate RBI-compliant documentation for equivalent systems used across its India operations. DBS Bank's India digital banking operation, digibank, creates the mirror image: an MAS-governed parent operating an RBI-governed India business, with AI systems that may be shared across both but need jurisdiction-specific validation and documentation records for each.

So what: if you run AI across both India and Singapore operations, build one governance core — ideally NIST-aligned, since that's the structure both RBI's FREE-AI and MAS's framework reference — and treat each jurisdiction's specific documentation requirements as an overlay on that core. Running two entirely separate governance teams for the same underlying models is the duplicate overhead that actually costs institutions the most, and it's avoidable.

A four-point action checklist

1. Audit your AI inventory today for any system without a named, traceable accountable owner — this is the cheapest fix with the highest examination visibility.
2. Set fairness metric thresholds (demographic parity, equalised odds, or equivalent) in writing before deployment, not after a complaint.
3. Produce two separate explainability artifacts for every consequential AI system: one tested for customer comprehension, one built for technical/regulatory review.
4. Add model-update notification and pre-deployment regression-testing clauses to every AI vendor contract that doesn't already have them.