AI Model Risk Management for Singapore Banks: What MRM Means Here

What does AI model risk management mean for a Singapore bank? It means the AI system is not just a technology asset; it is something that must be identified, governed, controlled, monitored and evidenced across use. MAS describes good practices for AI and Generative AI model risk management as covering governance and oversight, key risk management systems and processes, and development and deployment of AI. That is narrower than “AI governance” as a slogan, and broader than model validation as a one-off review.

AI model risk management MAS expectations

The MAS starting point is not a single magic control. It is a set of practices around governance, oversight, risk systems, processes, development and deployment. That matters because “model risk management” is often compressed into validation, documentation, or approval paperwork. Those are parts of the job. They are not the whole job.

This information paper sets out good practices for AI and Generative AI model risk management that were observed during the review, focusing on those relating to governance and oversight, key risk management systems and processes, and development and deployment of AI.

— MAS, Artificial Intelligence (AI) Model Risk Management

The important word is “practices”. MAS encourages all financial institutions to reference these good practices when developing and deploying AI. That sentence does not say every practice is mandatory in the same way for every system. It also does not give a bank permission to ignore the control problem because a model is experimental, internal, or supplied by a third party.

The later MAS formulation is more explicit about supervisory expectations. MAS says the proposed Guidelines will apply to all financial institutions and will set out expectations on oversight of AI risk management, key systems, policies and procedures, lifecycle controls, and capabilities and capacity needed for AI use. Read plainly, that is a management-system claim. It is not only a data-science claim.

2 The proposed Guidelines will apply to all financial institutions (FIs) and set out MAS' supervisory expectations on oversight of AI risk management in FIs, key AI risk management systems, policies and procedures, key AI life cycle controls, as well as capabilities and capacity needed for the use of AI.

— MAS, MAS Guidelines for Artificial Intelligence (AI) Risk Management

There is a limit here. A MAS information paper on good practices is not the same thing as a finished internal control standard for your bank. It gives you direction. It does not write your control library, define your approval thresholds, or decide which credit-limit change needs human review.

That is why the useful reading of MAS guidance is operational rather than ceremonial. A bank needs to show where AI is used, who owns it, what risks attach to it, what controls apply, and what evidence remains after the system acts. The financial services context matters because a model output is rarely just a prediction; it may lead to a payment release, an account restriction, a customer communication, or a changed limit.

What is AI model risk management in practice

AI model risk management is the discipline of keeping AI use inside a governed operating model. In MAS language, that operating model includes oversight, risk management systems and processes, and the development and deployment of AI. In practical language, it asks whether the organisation knows what the AI is doing, why it is allowed to do it, how it was tested, how it is monitored, and what happens when it changes.

That definition is deliberately unromantic. It does not begin with a model card. It does not end with a dashboard. It begins with inventory, because an organisation cannot govern a model it has not identified.

MAS says financial institutions need clear identification processes for AI usage across the firm, accurate and up-to-date AI inventories, and risk materiality assessments that factor impact, complexity and reliance dimensions. That one sentence is the spine of a credible programme. If a payment-operations team is using an AI assistant to draft exception-handling decisions, the relevant question is not only whether the model is good. The first question is whether the use exists in the inventory at all.

Materiality then does the sorting work. MAS says AI risks may vary based on scale, scope and business models. MAS also says expectations may be applied in a proportionate manner, commensurate with the size and nature of activities, AI use, and risk profiles. Proportionality is not a loophole. It is a demand for a reasoned difference between a low-impact drafting aid and a system that can affect a customer record.

The control areas are also named. MAS says financial institutions should plan for and implement controls across areas including data management, fairness, transparency and explainability, human oversight, third-party risks, evaluation and testing, monitoring and change management. That list is useful because it blocks a common evasion: treating “AI risk” as if it were only about model accuracy.

A wrong answer is one risk. An unexplained answer is another. A third-party model dependency is another. A model that behaved acceptably during testing but drifts after deployment is another. A human approval step that cannot be shown later is another. The categories are connected, but they are not interchangeable.

This is where engineers and risk owners often talk past each other. The engineer may think the model is controlled because it passed evaluation. The risk owner may think the model is controlled because it was approved. The compliance officer may ask for the record that ties the use case, the risk assessment, the approval, the monitoring and the later action together. All three can be right about their slice and still leave a gap.

AI model risk management framework for agents

An AI model risk management framework for agents has to preserve the ordinary model-risk questions while adding a runtime question. The ordinary questions cover identification, inventory, materiality, lifecycle controls, monitoring and change management. The runtime question is whether this agent may take this action now, and what record is created when the answer is given.

MAS makes that agent-specific concern visible in its description of SAFR. MAS says SAFR proposes a framework for governance of AI agents in financial services, defining how agent actions are authorised, how human oversight is activated, and what is recorded at the point of every decision. That is not just another model-development artefact. It is a decision-time control problem.

Safeguards for Agentic Finance at Runtime (SAFR) proposes a framework for the governance of AI agents in financial services, defining how agent actions are authorised, how human oversight is activated, and what is recorded at the point of every decision.

— MAS, Artificial Intelligence (AI) Model Risk Management

This is the point at which ordinary model-risk assumptions start to strain. A conventional AI use may produce a score, a recommendation, or a classification that a downstream process consumes. An agent may try to act. It may initiate a refund, amend a customer record, send an instruction, or ask another system to do work. The model output and the business action are closer together.

That does not mean AI model risk management is obsolete. It means AI model risk management cannot stop at model approval. Inventory still matters. Testing still matters. Monitoring still matters. Human oversight still matters. But the agent creates an additional evidence question at the instant of action: who or what authorised the action, under which policy, with which human intervention if any, and with what record left behind.

That is why SAFR belongs in the same conversation as AI model risk management but should not be treated as a synonym for it. The MAS AI Model Risk Management paper addresses good practices across governance, oversight, systems, processes, development and deployment. The SAFR description focuses on agent actions, human oversight activation and decision-point recording. Those two frames overlap. They are not identical.

A bank can have a respectable AI model risk management process and still be weak at runtime evidence. A model can be inventoried, approved, tested and monitored, while the actual agent action leaves only an operational trace that does not answer the authorisation question. That is not a theoretical nicety. It is the difference between saying “the model was approved for this class of work” and showing “this action was permitted at this moment”.

For the SAFR evidence question, see a separate article on agent-runtime evidence. The narrower engineering question of a single tool invocation is separated in Who Authorizes an MCP Tool Call?. The broader governance architecture is discussed in AI Risk Management Platform: Verifiable Oversight, but an architecture page does not replace a control owner’s duty to define scope, thresholds and evidence requirements.

What this means if you have to produce evidence

Evidence is where vague AI governance fails. It is easy to say that a model was governed. It is harder to show, after a disputed action, the specific chain from use-case identification to risk assessment to control to runtime decision.

MAS expects financial institutions to maintain accurate and up-to-date AI inventories and to implement risk materiality assessments using impact, complexity and reliance dimensions. That expectation gives evidence work a starting point. The inventory is not a spreadsheet for auditors. It is the map that tells the organisation which AI uses need which controls.

For an ordinary AI model, the evidence pack might centre on the approved use case, the model development record, the test results, monitoring, change management and human review arrangements. That sentence is a practical inference from the control areas MAS names: development and deployment, evaluation and testing, monitoring and change management, and human oversight. For an agent, that pack is not enough if the agent can touch a system that matters.

The missing artefact is the decision-point record. MAS’s SAFR description says agent governance includes what is recorded at the point of every decision. That phrase is precise. It is not satisfied by proving that the model existed. It is not satisfied by proving that the agent had an account. It is not satisfied by proving that the application logged something somewhere.

Consider a changed credit limit. If the change is challenged, the useful record is not a generic statement that the AI programme was approved. It is the record that connects the agent, the customer context, the permitted action, any required human oversight, and the final decision. Without that, the organisation is left reconstructing intent from fragments.

There is also a boundary to be honest about. MAS’s cited language does not prescribe the exact data fields your bank must store for every agent action. It does not name your retention period. It does not tell you whether a given approval must sit with operations, risk, compliance or a business owner. Those are internal design choices, and they should be made before the first disputed record arrives.

The MindForge material points in the same operational direction. MAS says the MindForge AI Risk Management Toolkit features an AI Risk Management Operationalisation Handbook that provides detailed, practical guidance on implementing AI risk management frameworks. MAS also says examples in that toolkit offer insights into challenges, approaches and risk management practices when using AI in different organisational contexts. That is helpful, but examples do not absolve a bank from deciding its own evidence standard.

For a compliance officer, the test is simple. Pick one AI use case. Ask whether it is in the inventory. Ask whether materiality has been assessed. Ask which controls apply. Ask what happens when the model or the use changes. Then ask what evidence would survive a dispute about one action. If the last answer is a dashboard screenshot, the evidence posture is weaker than the governance language suggests.

Practical steps for a bank

1. Define AI use before debating AI risk. MAS expects clear identification processes for AI usage across the firm, so start by deciding what counts as AI use in your organisation and how it enters the inventory. Do not let business teams classify a tool as “just assistance” if its output changes a customer, a payment, a record or a limit.
2. Build the inventory as a control object. MAS expects accurate and up-to-date AI inventories, not a one-time discovery exercise. The inventory should be useful enough that a reviewer can locate the owner, the use, the risk assessment and the applicable controls without interviewing half the organisation.
3. Use materiality to separate control depth. MAS says risk materiality assessments should factor impact, complexity and reliance dimensions. A drafting assistant, a fraud alert and an agent that can trigger an operational action may all be AI uses, but they do not deserve identical treatment.
4. Map controls to the lifecycle. MAS names controls in areas such as data management, fairness, transparency and explainability, human oversight, third-party risks, evaluation and testing, monitoring and change management. If a control cannot be mapped to a named risk area, it may be decoration.
5. Separate approval from runtime permission. MAS describes SAFR as defining how agent actions are authorised and how human oversight is activated. A committee approval for a use case does not answer whether an agent may release this payment, delete this record, or change this limit now.
6. Record the decision when the action happens. MAS’s SAFR description includes what is recorded at the point of every decision. If the record is assembled later from operational logs, the organisation should be honest that it is reconstruction, not a decision-point record.
7. Test the evidence path before a dispute. MAS expects monitoring and change management as part of lifecycle controls. Treat evidence retrieval as part of that discipline: select a completed action and prove that the inventory, risk assessment, control and decision record can be found.

The position here is narrow: runtime authorization for agents should be treated as a control and evidence problem, not only as an identity or model-quality problem. GREENLIGHT is the permission step Crelis describes for sensitive agent actions, and the product demonstration asks where AI agents touch money, customers, records or infrastructure.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• SAFR evidence for agent actions — agent-runtime evidence separated from general AI governance.
• MAS Guidelines — every article on this site about MAS guidance and AI risk.
• Financial Services — articles for banks, payment firms and regulated finance teams.