Build the AI inventory around materiality decisions

MAS turns proportionality into an evidence problem

On October 7, 2026, the Monetary Authority of Singapore issued final Guidelines on Artificial Intelligence Risk Management for Financial Institutions. They apply to all financial institutions and all forms of AI, while allowing implementation to reflect the institution's size, risk profile, and the scale and nature of its AI use. The Guidelines take effect on October 7, 2027; the lifecycle and third-party sections may be met by October 7, 2028.

The phased dates should not be read as permission to wait. Population discovery, ownership, data lineage, vendor rights, baseline tests, and monitoring history take time. An institution cannot apply proportionality if it does not know which AI systems exist, what decisions they influence, which providers and data they depend on, and which controls actually operate.

MAS also gives smaller or lower-risk populations a practical path: a basic policy can name an accountable senior person, define permitted and prohibited uses, require human oversight and approved tools, educate users, check compliance, and review periodically or on trigger. That is not an exemption. It is a proportionate baseline whose adequacy depends on the use case and evidence.

The core operating decision is materiality. A drafting assistant used by two analysts should not automatically receive the same validation burden as a model that ranks customers, approves limits, executes transactions, or communicates binding outcomes. Conversely, calling a system “assistive” does not make it low-risk if staff routinely follow its output or cannot detect errors.

This guide is an implementation pattern, not legal advice. Qualified legal and compliance owners must decide scope, interpretation, and how MAS expectations interact with sector rules, technology-risk, outsourcing, privacy, conduct, and internal model-risk frameworks.

Freeze the AI population before scoring it

An AI register built only from model-risk submissions will miss embedded SaaS features, employee-built agents, vendor models inside business platforms, and deterministic tools marketed as AI. Reconcile multiple sources: procurement and accounts payable, SSO applications, API and model gateways, cloud logs, code repositories, data connectors, security discovery, vendor registers, and declarations from business owners.

Do not use “model” as the only record. One business use case may move between model versions and providers; one foundation model may support several use cases with different impact. Keep a stable use-case ID and link it to changing technical dependencies.

useCaseId: FIN-CR-042
purpose: assist analysts reviewing small-business credit files
decisionMode: recommend-and-explain
lifecycle: controlled-pilot
owners:
  business: credit-operations-director
  accountableSeniorPerson: chief-risk-officer-delegate
system:
  application: credit-review-workbench
  models: [{provider: vendor-a, model: model-x, version: 2026-09-18}]
  data: [application, bureau, statements, analyst-notes]
  actions: [retrieve-file, draft-risk-factors, propose-questions]
  prohibitedActions: [approve-credit, change-limit, contact-customer]
dependencies: [cloud-region, identity, vector-index, logging, vendor-api]
materiality:
  methodVersion: FI-AI-MAT-3.2
  inherentTier: high
  residualTier: pending-independent-review
evidenceAsOf: 2026-10-11

Inventory attributes should cover purpose and scope, model type, data, dependencies, lifecycle state, materiality, last review, owners, and supporting documentation. Link the record to data, vendor, incident, change, and assurance registers instead of duplicating stale summaries. Unknown should be a valid visible state, never an empty cell treated as low risk.

Score inherent materiality before giving controls credit

Start with the consequence if the AI behaves as badly as a credible scenario allows, before assuming monitoring, oversight, or provider safeguards work. Evaluate impact, complexity, and reliance, the three themes highlighted by MAS, then express them in the institution's approved taxonomy.

Then map required controls by the provisional inherent tier. Test design and operating effectiveness. Only after relevant evidence passes should the panel assess residual materiality. A signed policy proves that a rule exists; it does not prove that a user followed it, a monitoring alert fired, or an override was meaningful.

inherent materiality
  = consequence x exposure x reliance x complexity
  + data / autonomy / dependency modifiers

control credit
  = relevant design x tested operating effectiveness x evidence freshness

residual materiality
  = inherent materiality after verified controls and visible open gaps

This is a decision model, not a universal mathematical formula. Avoid false precision. If two dimensions point to a high tier, do not average them down because four low-severity checks passed. Record disagreements, assumptions, and the authority that resolved them.

Route lifecycle evidence according to the risk, not the technology label

MAS expects controls across the lifecycle: data, transparency and explainability, fairness, third-party risk, model selection, evaluation and testing, security, reproducibility and auditability, independent review, and ongoing monitoring. The required depth should respond to materiality.

Independent pre-deployment review is especially important for high-materiality systems. Independence means the reviewer can challenge the owner and has sufficient access, competence, and authority; it does not necessarily require a particular organizational label. Record the policy trigger, reviewer, scope, limitations, findings, and closure evidence.

Human oversight must be designed, not declared. Reviewers need time, information, authority, skill, and a usable way to disagree. Measure overrides, reasons, downstream outcomes, and automation bias. If staff approve nearly every recommendation in seconds, a nominal human checkpoint may not reduce reliance.

Provider assurance supports the record; it does not transfer accountability

MAS's response to consultation is direct about third-party AI: institutions retain primary accountability. They should seek visibility and notification of material changes, test the system in context with their own data where possible, use compensating tests where access is constrained, manage supply-chain and concentration risk, and maintain contingencies.

Do not turn opacity into control credit. A provider certification, benchmark, model card, or general red-team report may be relevant, but it may not cover the institution's prompts, retrieval data, tools, customer population, threshold, or failure consequence. Label it provider-asserted until the institution verifies what it needs.

If residual risk is outside appetite, the disposition is not “document the limitation.” It may be to limit the use case, suspend it, or replace the provider or design. Connect this review to the AI provider concentration and exit test workflow.

Worked example: a credit-review assistant is high-materiality even without approval authority

A bank pilots an assistant that summarizes small-business applications, identifies risk factors, retrieves policy, and proposes questions for an analyst. The vendor and project team describe it as low-risk because it cannot approve credit. The materiality review reaches a different provisional conclusion.

The assistant sees financial statements, bureau data, and analyst notes. Its summary controls which issues receive attention. Analysts handle high volume and usually review the AI output first. Poor retrieval can omit a policy exception; inconsistent summaries may affect similarly situated applicants; a prompt or model update can alter behavior across thousands of files. Errors are reversible before approval, but only if the analyst notices them.

The team keeps the inherent tier high. It adds source-level citations, policy-version display, calibrated uncertainty, random second review, subgroup testing, prompt/model canaries, an override-reason field, and a tested daily volume limit. Independent validation challenges the evaluation data and thresholds. Residual materiality remains high but within the approved pilot appetite for a small, monitored population. The human panel authorizes a constrained pilot, not general deployment.

This result is more useful than “approved AI.” It tells operations which boundary applies, risk which evidence expires, technology which changes trigger reassessment, Finance which capacity is funded, and management what residual exposure it accepted.

Monitor the decision assumptions, not just model accuracy

Materiality can change without a new model. Volume may grow; staff may rely more heavily on outputs; a workflow may add an action tool; customer impact may expand; a provider may change hosting or a subprocessor; a manual fallback may lose capacity. Monitoring should cover the assumptions supporting the tier.

Keep version and change records replayable. Store model/API identifiers, prompts and system instructions, retrieval sources, rule versions, tool permissions, thresholds, evaluation data, and approvals. For stochastic systems, reproducibility may mean reconstructing the configuration and distribution of outcomes rather than producing the same words every time.

Common failure modes

Run a 30-day readiness sprint

Days 1-5: approve definitions, scope roles, stable IDs, materiality dimensions, tiers, non-compensable criteria, independent-review triggers, risk appetite, and record retention. Choose one meaningful business process rather than the easiest chatbot.

Days 6-10: reconcile population sources and freeze the use cases. Assign owners. Map each process from input and data through model, retrieval, tools, human checkpoints, outputs, downstream decisions, monitoring, vendors, and fallback.

Days 11-15: assess inherent materiality without control credit. Capture evidence, disagreements, unknowns, and provisional tier. Route the lifecycle control plan and third-party evidence requirements.

Days 16-22: run contextual evaluations, security and failure tests, workflow observation, human-oversight checks, provider-change canaries, and fallback exercises. Arrange independent review for high-materiality use cases.

Days 23-27: determine which controls earned credit, calculate residual materiality, map gaps to owners and funding, define monitoring and suspension triggers, and connect vendor gaps to procurement and exit plans.

Days 28-30: hold the human risk decision. Approve only the exact version, population, volume, permissions, controls, and evidence reviewed. Record conditions, expiry, monitoring, exceptions, and reassessment triggers. Feed rollout evidence into the enterprise AI rollout workflow.

FAQ

Do the MAS Guidelines apply only to generative AI?

No. MAS says they apply to all financial institutions and all forms of AI, including systems with greater autonomy. Controls may be tailored proportionately to risk and use.

What is the difference between inherent and residual materiality?

Inherent materiality assesses the significance of the use case before relying on controls. Residual materiality reflects the exposure left after relevant controls are shown to work. A policy or vendor promise alone should not reduce the tier.

Can an AI tool perform its own assessment?

It can reconcile supplied records, draft matrices, identify missing fields, and expose contradictions. It should not determine scope, invent evidence, validate itself, set appetite, or approve residual risk.

Who remains accountable for third-party AI?

The financial institution. Provider assurance can support the file, but the institution must understand the use, perform proportionate contextual tests, monitor change, manage concentration and exit, and act when residual risk exceeds appetite.

When should a use case be reassessed?

At the policy cadence and when purpose, users, scale, data, model/version, autonomy, tools, provider, dependency, impact, incident history, performance, or controls materially change.