AI Governance 14 August 2026

MAS SAFR for Financial Institutions: What to Evidence for Agentic AI

SAFR is a white paper, not a rule. MAS published it with financial institutions and FinTechs on 3 July 2026, and the paper proposes an industry-developed framework rather than an instrument of supervision. Nothing in it obliges a firm to do anything. That is exactly why it repays a close reading: it is the clearest public statement of what the people building these systems expect to be asked to show, and every safeguard it names implies a record that has to exist before anybody asks for it.

MAS SAFR

SAFR stands for Safeguards for Agentic Finance at Runtime. It is an industry white paper published by MAS together with financial institutions and FinTechs on 3 July 2026, developed under MAS's BuildFin.ai initiative. It proposes a set of governance checkpoints that verify and record an AI agent's proposed action before the agent executes it. The release's own words are "an industry white paper" that "proposes an industry-developed framework".

The distinction between those words and the word "guideline" is the whole story. A rule tells you what you must be able to show, and a supervisor tests you against it. A white paper tells you what a group of practitioners currently believe good practice looks like. SAFR is the second kind of document — industry partners are invited to join the work group that will help shape subsequent iterations of it, which is not how a binding instrument behaves. Read as consensus, it is useful. Read as a mandate, it is the one thing a compliance officer cannot afford to get wrong.

MAS SAFR requirements

SAFR does not impose requirements. It proposes a framework, and among the safeguards it names are policy bound execution, real time validation, auditability and interoperability. Each of those, read by an engineer rather than by a policy team, resolves into a specific record that either exists in your systems or does not.

"The SAFR white paper sets out the direction for how these safeguards, including policy bound execution, real time validation, auditability and interoperability, can be embedded into system operations so that financial institutions can deploy AI agents with trust and consistency."

— MAS media release, July 2026

Translated into records, those four are four different artefacts, and only one of them is a log in the ordinary sense.

Policy bound execution. The mandate that was in force at the moment of the action, in the version that was in force, and the identity of whoever set it. Not the current policy document. The one that applied then.
Real time validation. The check that ran, what it returned, and evidence of its position relative to the action. A timestamp is not that evidence when the log is written by the same system that acted, after it acted.
Auditability. The proposed action as proposed, retained so that later alteration cannot happen without detection. Tamper-evident, not unalterable: the claim worth making is that a change shows, not that a change is impossible.
Interoperability. The same record, legible to somebody who does not run your platform — second line, external audit, or a supervisor who has never seen your stack.

Notice that three of the four are about the state of the world at the instant of the action, and one is about who else can read it. None of them is satisfied by better application logging.

MAS SAFR white paper summary

The short version: agents in financial services now act faster than a person can practically intervene, so the safeguard has to sit at the point of action rather than in a pre-deployment review. The media release states the premise directly.

"As AI agents in financial services increasingly carry out tasks autonomously and at speed beyond practical human intervention, financial institutions need real-time safeguards to ensure that the behaviour of AI agents remain within predefined mandates, policies and risk boundaries set by financial institutions."

— MAS media release, July 2026

Two words in that sentence carry the weight. The first is "predefined": the mandate has to exist before the action, which means it has to be written somewhere a system can read at the moment of execution, not somewhere a person can find during an investigation. The second is "set by financial institutions": the boundary belongs to the institution, not to the model vendor and not to the agent's own judgement. If you cannot name the person who set a mandate and show which version was live, you do not have a mandate. You have a default.

The applied examples in the release show what "bounded" means in practice. Payments and treasury, where agents execute routine transactions within predefined mandates. Wealth advisory, where agents review documents and produce structured assessments inside narrowly scoped task boundaries. In both, the action itself is unremarkable. What makes it defensible afterwards is that somebody can produce the fence that was around it at the time.

One more thing belongs in an honest summary: who wrote it. The paper came from MAS together with leading financial institutions and FinTechs — co-authored with the industry, not drafted by a supervisor and handed to it. That authorship is also why it will move. Interested industry partners are invited into the work group that shapes subsequent iterations of SAFR, so what you build against today is a first pass rather than a settled standard. Build for the parts that will survive revision — the records — and not for the vocabulary, which will not.

MAS agentic AI guidelines Singapore

This is where most write-ups go wrong, so it is worth stating flatly: there is no Singapore rulebook for agentic AI sitting behind SAFR. What sits alongside it is a second voluntary document from a different agency. IMDA launched its Model AI Governance Framework for Agentic AI in January 2026, and its own description of the document is guidance, not obligation.

"It provides guidance to organisations on how to deploy agents responsibly, recommending technical and non-technical measures to mitigate risks, while emphasising that humans are ultimately accountable."

— IMDA press release

Read the end of that sentence twice, because it is the load-bearing clause: humans are ultimately accountable. The framework's four dimensions follow from it. Bound the risk upfront by limiting an agent's autonomy and its access to tools and data. Define the significant checkpoints at which a human has to approve. Put technical controls across the agent's lifecycle, including control over which services the agent may reach. Enable end-user responsibility through transparency and training.

Underneath both sits the older layer: the FEAT Principles, released in 2018, which MAS describes as guidance to firms for strengthening internal governance around data management and use. The pattern across all three documents is consistent, and worth saying baldly. Two of them provide guidance. The third proposes a framework. None is binding on its own terms, so none of them obliges you to keep any particular record.

That is the honest headline, and it is more useful than an invented mandate. If you are waiting for a binding Singapore instrument that specifies which records to keep when an agent moves money, these documents are not it. What they give you instead is a public account of what informed practitioners think evidence should look like — which is something you can build against now, whereas a rule that does not yet exist is not.

What does SAFR require banks to log?

Nothing, in the legal sense — it is a white paper. But the question underneath the question has a precise answer, and it sits in a single line of the media release.

"The SAFR framework provides for a set of governance checkpoints that verifies and records an AI agent's proposed actions before the execution of its tasks."

— MAS media release, July 2026

The load-bearing word is "before". A conventional application log records what happened. A checkpoint record of this kind has to come into existence while the action still has not happened, which means it cannot be reconstructed afterwards — not by a better parser, not by a data engineer, not by anybody. That one word is the difference between an audit trail and evidence.

Taken seriously, the record it implies has six parts. A firm that can produce all six can answer almost any question about an agent's action months later.

The proposed action, as proposed. What the agent asked to do, captured before execution, in the agent's own terms rather than in the terms of whatever eventually happened.
The mandate in force. Which policy version applied at that instant, and who set it.
The check and its result. What was evaluated, what came back, and the ordering relative to the action.
The human, where one was required. Who approved, what they were shown at the moment they approved, and how long they had to look at it.
The limits that were in force. Which tools, data and services the agent could reach at that moment, and which it could not.
The outcome. What actually executed, and whether it matched what was proposed.

SAFR compliance checklist

There is no compliance regime to be inside, so this is not a compliance checklist. It is six questions to put to whoever runs your agent platform, in the order that exposes the most, with an honest note on which answers tend to come back thin.

1. Show me a proposed action that was never executed. If every record in the system corresponds to something that happened, the platform is recording outcomes, not decisions. The refusals are the proof that a boundary existed at all — a system that only logs successes cannot demonstrate it ever said no.

2. Show me the policy exactly as it stood at 14:07 last Tuesday. This one is usually answerable, from a document store or a repository history. The harder half is binding that version to the specific action, which is what a predefined mandate actually asks for.

3. Show me that the check ran before the call, not beside it. This is the hardest question in the list. Do not accept a diagram: an architecture drawing shows where a control was meant to sit, not that it sat there during the action in question. If the evidence that a control ran is produced by the component the control was supposed to constrain, you have a design assertion, not evidence.

4. Name the human. The framing is a defined checkpoint at which human approval is required. A screenshot in a chat thread is not a checkpoint. An approval that cannot be tied to a specific proposed action, with what the approver saw at that moment, will not survive a question from anybody who was not in the room.

5. Show me the limits that were in force. IMDA recommends bounding an agent's powers — autonomy, and access to tools and data — and controlling which services it can reach. That configuration usually exists. It usually is not captured as evidence at the time of each action, which means you can describe the fence today but not prove where it stood last quarter.

6. Hand the whole thing to somebody who does not work here. Interoperability is one of the safeguards the paper names, and it is the one that quietly disqualifies most answers. If the record only makes sense inside the tool that produced it, or if its integrity rests on the good behaviour of the team that operates that tool, an external reader cannot rely on it. The record has to be tamper-evident: alteration cannot happen without detection.

Questions one, three and four are the hard ones, and for the same underlying reason — each asks for something that could only have been captured at the moment of the action. Question two is usually answerable but rarely bound to an event. Questions five and six are ordinary engineering work you can schedule.

What this means if you have to produce evidence

Start collecting now, because most of the six parts cannot be created later. This is not a programme of work. It is a decision about what your agent platform writes down at the moment it acts, and it can be made one workflow at a time.

Pick the workflow where an agent commits the firm to something — moves money, sends a client a position, changes a limit — and for that one workflow, capture six things: the proposal before execution, the policy version that applied, the check and its result, the approver and what they saw, the reach the agent had, and what executed. Retain them together, as one record per action rather than six systems you have to join later under time pressure. Make the retention period a decision somebody signed, not a default inherited from a logging tool. Then confirm that a reader outside your team can follow it end to end without you narrating.

Two cautions on scope. First, this applies whether you built the agent or bought it: IMDA's framework is aimed at firms deploying agents developed in-house and at those using third-party agentic solutions alike, and a vendor's assurance that a check ran is not the record that it ran. Second, the failure you are evidencing against is specific. The risk IMDA names is an unauthorised or erroneous action by a system that can change things — update a record, make a payment. So the record has to distinguish an action the firm permitted from an action it merely observed. Those look identical in a conventional log, and they are not remotely the same thing in a dispute.

None of this is required of you today. That is the point. The cheapest moment to build a record is before anybody has the standing to demand it, and the one thing no future instrument can give you is evidence about an action that has already happened.