What MAS's AI guidelines ask of a markets business

Markets & riskAbout 7 min read · Materiality explorer

The question moves from “do we use AI?” to “which uses matter?”

On 7 October 2026, the Monetary Authority of Singapore published its final Guidelines on Artificial Intelligence Risk Management. They apply to all financial institutions and all forms of AI. They take effect on 7 October 2027, with lifecycle controls and capability expectations due by 7 October 2028.

The central shift is one of granularity. MAS expects firms to manage AI risk at the enterprise level and at the level of each use case. A firm cannot answer with one AI policy. It has to know where AI is used, judge how much each use matters, and apply controls in proportion.

Markets businesses are an interesting test. AI already appears in research, pricing support, surveillance, operations and client service, often embedded inside vendor tools. Some of those uses are trivial. Some touch risk numbers, client outcomes or regulatory reporting. This post walks through what the guidelines ask, then scores five synthetic markets use cases the way the guidelines suggest.

What the guidelines ask

The guidelines group their expectations into four areas, phased over two years. The first two are about knowing your AI use; the last two are about controlling it.

Four areas of expectation and when they apply
Area	What MAS expects	Expected from
Oversight	Board and senior management set roles, risk appetite and frameworks. Existing governance structures can be used; a dedicated AI committee is not required.	7 Oct 2027
Identification, inventory, materiality	Identify AI use across the firm, keep an inventory at a sensible granularity, and assess each use case's risk materiality.	7 Oct 2027
Lifecycle controls, including third-party AI	Data governance, testing, human oversight, cybersecurity, monitoring and change management, scaled to materiality. Fallback plans for high-risk uses.	7 Oct 2028
Capability and capacity	Competent staff and technology infrastructure adequate for the AI in use.	7 Oct 2028

Timeline from publication on 7 October 2026 to oversight, inventory and materiality expectations on 7 October 2027, then lifecycle controls, third-party AI and capability by 7 October 2028, with an agentic AI consultation planned in 2027. — Figure 1. Know and score AI use first; control and staff it second. Open full-size SVG · Scroll the diagram horizontally on smaller screens.

Three points stand out for a markets reader.

Proportionality is explicit. Where poor performance or unavailability of an AI tool is unlikely to have a material impact on the firm, its customers or other institutions, basic policies and procedures may be enough. That is a licence to spend control effort where it counts, but only after the assessment says so.

Third-party AI stays your problem. Firms remain accountable for AI developed, operated or provided by vendors. Allen & Gledhill's summary notes the expectation to test vendor AI in the firm's own use cases, using its own data, and to document why it was judged suitable. If residual risk cannot be brought within appetite, the firm should limit, suspend or replace the service.

Agents are acknowledged, not yet settled. MAS names agentic systems that act autonomously and use tools as a reason to keep reviewing controls. It intends to consult in 2027 on what further guidance on agentic AI would help.

Five markets use cases, scored

The same model can land in very different risk tiers depending on what it is used for. The consultation draft asked firms to assess materiality across, at minimum, impact, complexity and reliance. Reliance reflects how much an outcome depends on the AI rather than on a person checking it. Inherent risk is assessed before controls; residual risk after them.

Illustrative scoring. The use cases are synthetic and the ratings are my judgment, not MAS's. A real assessment would use the firm's own methodology and evidence.

Inherent and residual tiers for five synthetic use cases
Use case	Impact	Complexity	Reliance	Inherent tier	What lowers residual risk	Residual tier
Term-sheet extraction feeding trade booking	High: wrong barrier or coupon mis-books a client trade	Medium: GenAI reading varied documents	High if fields auto-populate	High	Field-level checks against the source document; a second person approves before booking	Medium
Surveillance alert triage that auto-closes low scores	High: a missed abuse case is a regulatory failure	Medium	High: closed alerts are never seen	High	Sample closed alerts for human review; measure misses, not just volume saved	Medium
Client chat answering product questions	Medium–high: wrong answers can mislead clients	Medium	Medium: answers reach clients directly	Medium–high	Restrict answers to approved product documents; route suitability questions to people	Medium
Code assistant for risk-library developers	Medium: a bug can distort risk numbers	Medium	Low: a developer reviews every change before merge	Medium	Existing code review and regression tests on risk outputs	Low
Summaries of public research for internal notes	Low: an internal draft a person edits	Medium	Low: a person writes the final note	Low	Basic policy on acceptable use and source checking	Low

Two things show up. The technology is similar in every row, yet the tiers differ, which is why the guidelines assess use cases rather than products. And impact sets the starting tier, but reliance is the lever controls move. A second approver, a sampled review or a narrower scope lowers the residual tier without changing the model. The code assistant and research summaries start with low reliance because a person owns the output by design.

Five use cases with impact, reliance, inherent tier, the control that reduces reliance, and the resulting residual tier. — Figure 2. Impact sets the inherent tier; controls lower the residual tier by reducing reliance. Ratings are illustrative, not MAS's. Open full-size SVG · Scroll the diagram horizontally on smaller screens.

Explore one use case at a time

Illustrative ratings. Five synthetic use cases from the table above. Choose one to see what drives its inherent tier, the control that reduces reliance, and the residual tier that results. Nothing here calls a model.

Term-sheet extraction feeding trade booking

Inherent: HighResidual: Medium

Impact if wrong and unnoticed

High. A wrong barrier or coupon mis-books a client trade.

Complexity

Medium. GenAI reading varied documents.

Reliance before controls

High. Extracted fields populate booking directly unless gated.

Control that reduces reliance

Field-level checks against the source document; a second person approves before booking.

What to notice: The model is the same in every case. Impact sets where a use case starts; the control changes how much an outcome depends on the model, and that is what moves the residual tier.

What changes for GenAI and vendor models

Traditional model risk management assumed the firm built the model, knew its training data and controlled its releases. A hosted language model breaks all three assumptions. The guidelines respond in ways a markets technology team will feel.

Updates become a change-management event. Contracts should give the firm visibility over the introduction of AI and later updates or changes. A provider's silent model upgrade can change how a term-sheet extractor reads a barrier clause. If you cannot see the change, you cannot re-test before it reaches production.

Testing means your data, your task. A vendor's benchmark score says little about your documents. The expectation to test third-party AI in the firm's own use cases is, in practice, a requirement to keep a domain evaluation set. For extraction, that means labelled source documents and field-level checks. I covered the claim-to-evidence approach in Evaluating AI assistants beyond an accuracy score.

Concentration is worth measuring. Keeping accountability for vendor AI makes provider dependence a risk-appetite question. If every high-tier use case in the table above ran on one model API, one outage or one bad update would hit all of them at once. Counting material use cases per provider is a simple place to start.

High-risk uses need a way back. The guidelines expect contingency plans for high-risk use cases, such as alternative systems or manual processes. For surveillance triage, that means the team can still work the alert queue if the model is switched off. That capacity has to exist before it is needed.

What the guidelines leave to the firm

The guidelines are principles-based, and MAS says respondents strongly supported that. The consequence is that several hard design choices stay with each firm.

The scoring method. The guidelines name what to consider, not a formula. Two firms could rate the same use case differently and both be defensible, so documenting the reasoning matters as much as the rating.
The fit with existing model risk. Markets firms already validate pricing and risk models. Whether AI use cases join that process or run alongside it is a firm decision, and a messy one where an AI component sits inside a traditional model.
Embedded AI. MAS refined its text on AI embedded in vendor products, but finding it is still work. A feature switched on in a familiar tool may never reach the inventory unless procurement and change processes ask.
Agents. Guidance on agentic AI is still to come. Until then, the action boundaries from Prompt is not permission are a reasonable baseline: authority comes from the session and policy, not from the model's request.

When reviewing a markets AI use case, I would ask one question first: if this output is wrong and nobody notices, what happens? The answer sets the tier. Everything else in the guidelines follows from taking that answer seriously.

This post summarises public material for discussion. It is not legal or compliance advice, and the views are my own.