TL;DR: On 1 July 2026, the Monetary Authority of Singapore published SAFR — Safeguards for Agentic Finance at Runtime (v1.0), written with Ant International, Circle, HSBC, J.P. Morgan, Manulife, Mastercard, OCBC, and Visa. SAFR is not model-safety guidance and not a compliance platform. It is a runtime governance layer that sits between an AI agent and the systems it acts on, evaluating every proposed action before execution. Its mechanics are four components — Agent Identity, Controls Repository, Disposition Engine, Audit Log — coordinated through a Governance Envelope that packages the action, the agent's action trace, and its context metadata. The Disposition Engine resolves each action to one of four outcomes: Auto-Execute, Observe, Escalate, Deny. For APAC financial institutions, SAFR is the missing architectural layer between "we deployed an agent" and "our regulator will accept how it behaves." This article breaks down the framework, corrects two common misreadings of it, and maps it to the data architecture you actually have to build.
The boundary between AI as decision support and AI as an autonomous actor has already dissolved in production. For most of the past decade, models in financial services produced scores, flags, and recommendations that a human reviewed before anything happened. That review step is now optional in a growing number of workflows: agents initiate payments, submit trading orders, approve credit lines, file regulatory reports, and settle claims — in some cases at high frequency, with no human looking at each individual action.
The governance frameworks most institutions run were built for the world that just ended. Model risk management validates a model before it goes live. Audit samples transactions hours or days after they clear. Neither catches a bad agent decision in the window that matters: the moment between proposal and execution. MAS's answer, developed through its BuildFin.ai work stream, is to standardise a control that operates in exactly that window. That is SAFR.
At DataMy we read SAFR less as a compliance document and more as an architecture specification — the one that finally tells FSI teams where the governance seam belongs in an agentic stack. This walks through the three gaps SAFR is designed to close, the framework's four components and the Governance Envelope that carries them, how the eight contributing institutions are already piloting it, and the two integration paths open to APAC banks and insurers — including the legacy-heavy mid-market.
A Polite Agent Can Still Wire the Wrong Million: Why Model Safety ≠ Authority
The industry has spent two years buying "guardrails" — prompt-injection defences, content filters, output moderation — and treating them as if they were governance. They are not, and SAFR is blunt about why.
Guardrails operate at the model's input/output layer and are, by construction, probabilistic. They shape what a model tends to say. They do not enforce the precise structural, numerical, and policy constraints that financial actions require. An agent can be perfectly polite, pass every content filter, and still propose a payment above its authority, a trade outside its permitted instruments, or a filing it was never delegated to make. In SAFR's own framing: an output that is plausible but incorrect still carries material consequence when the action is a covenant check or a transaction threshold.
This is the thread that runs through the whole framework. Governance for agentic finance is not about making the model behave — it is about authenticating authority at the point of action. Everything below follows from that distinction.
Where Today's AI Governance Breaks: Three Gaps at Machine Speed
MAS names three structural gaps in the governance infrastructure most institutions currently have:
| Gap | What's missing today | Consequence at machine speed |
|---|---|---|
| No pre-execution assurance | MRM validates pre-deployment; audit is retrospective, sampling hours later | By the time an issue shows in the audit log, the money has already moved |
| No human–agent governance interface | Human-in-the-loop is ad hoc — an email, a dashboard flag, no deadline, no standard decision format, no record | The appearance of oversight without the substance of it |
| Fragmentation | Each institution builds guardrails independently; controls are not interoperable or auditable in a consistent format | A corrupted feed or injected instruction can cascade across agents, detected only after harm |
The systemic angle matters for regulators specifically. Where many institutions run similar models or depend on a small number of common AI providers, behaviour can become correlated under stress — a vulnerability the Financial Stability Board has flagged (FSB 2024; FSB 2026). SAFR's per-action controls are explicitly designed to limit the scope of harmful actions that could correlate and propagate across the system.
The Architecture: Four Runtime Components and One Envelope
SAFR introduces a governance checkpoint between every agent decision and its execution. Four runtime components do the work, and they communicate through a single structured record — the Governance Envelope.
Figure 1 — SAFR control flow. Each agent action is governed independently; an Auto-Execute at one step carries no authority into the next.
The Governance Envelope: An Agent's Intent, Packaged for Interrogation
Before any action can be assessed, it is packaged with the context needed to judge it. The envelope captures three classes of information:
- Action — the action type, scope, and parameters of what is proposed.
- Action trace — the actual steps the agent executed to arrive at the proposal: tool calls made, data retrieved, checks performed.
- Context metadata — the agent identity, the applicable mandate, the current account or system state, and the operative policy constraints.
Capturing the action trace is what turns the envelope into a governance artefact: the basis for the decision is preserved at the point of proposal, ready for validation without reconstruction after the fact.
SAFR is unusually honest about the integrity risk here, and this is worth dwelling on because most vendor "agent audit" features quietly ignore it. The action trace and the action details are both agent-declared — both sit inside the same envelope, and a sufficiently sophisticated adversarial injection can fabricate them together while keeping them internally consistent. So the envelope must be treated as a document to be authenticated against its origin, not merely as a faithful record of what the agent says it did. Any implementation that trusts the agent's self-report has not implemented SAFR; it has implemented a nicely formatted log.
The Four Components: Identity → Rulebook → Verdict → Ledger
1. Agent Identity. For governance to mean anything, the agent proposing an action must be who it claims to be. This component resolves the claimed agent against a registry, retrieves the registry entry, and verifies the match before anything else runs. Fail this check and the action is rejected at the door. The nuance SAFR adds is network context: in a closed-loop, single-institution deployment the registry is the institution's own and resolution is a direct lookup; in open networks — where the agent touches counterparties, payment systems, or other institutions — the component must also decide which registry is authoritative (the institution's, a payment network's, an inter-institutional directory) and resolve the right identifier.
2. Controls Repository. The institution's configurable rulebook — controls drawn from organisational policy, regulatory requirements, product rules, and user-delegated authority. SAFR distinguishes generic controls (authorisation checks, exposure limits — deterministic, evaluated against fixed thresholds) from AI-specific controls (evidence quality, envelope-integrity checks — which may be probabilistic or semantic). The centre of gravity here is the mandate: a machine-readable record of what a principal has delegated to an agent — what it may do, within what limits, under what conditions. This is capability-based security (Dennis & Van Horn, 1966; the same lineage as OAuth 2.0): authority lives in a bounded, unforgeable token. Critically, an agent cannot extend its own mandate by reasoning or inference. Authority is explicit and structured, never inferred.
3. Disposition Engine. The engine evaluates each in-scope action deterministically against the retrieved controls and produces one of four binding outcomes:
| Outcome | Condition | Effect |
|---|---|---|
| Auto-Execute | In scope, below hard constraints, within risk thresholds | Proceeds without human intervention |
| Observe | Permitted, but matches a pattern the institution wants watched | Executes and logs a structured observation for review |
| Escalate | In scope, below hard constraints, but above the autonomous-execution threshold | Held pending human review before proceeding |
| Deny | Violates a hard regulatory/policy constraint or exceeds risk thresholds | Rejected before execution, with a specific reason recorded |
Outcome assignment is calibrated at design time to the action's risk profile across five factors: reversibility, financial materiality, customer-impact severity, regulatory sensitivity, and novelty/anomaly. Higher-risk profiles shift toward Escalate or Deny; lower-risk toward Auto-Execute or Observe. Because the thresholds are set in the controls, threshold-setting is itself subject to governance review before deployment — not something an engineer tunes in production.
4. Audit Log. An append-only, tamper-evident record. Once an entry is written at the point of decision, neither the agent nor any downstream system can alter it. Each entry captures the envelope as submitted, the mandate checked against, the outcome, the specific rules applied, the basis for the outcome, and the elapsed time at each stage. It serves two masters: operationally, it feeds existing AML/KYC, transaction-monitoring, and sanctions-screening platforms; for accountability, it lets every allow/deny/escalate/observe decision be fully reconstructed without relying on the agent's own account — the authoritative record, independent of any party with an interest in how events are later characterised.
One design rule deserves emphasis for anyone building multi-step agent workflows: the control flow applies to each action independently. An Auto-Execute or Observe at one step confers no authority on the next. As the agent adapts to intermediate results, prior authorisation does not carry forward. This is the opposite of how most orchestration frameworks are wired by default, and it is where naive implementations will fail an audit.
Where This Layer Sits in Your AI Stack — and What It Refuses to Be
A recurring source of confusion is treating SAFR as a competitor to systems it is designed to sit between. It isn't. SAFR operates after model-level content filtering and before execution and settlement.
| Layer | Governs | Example systems | Relationship to SAFR |
|---|---|---|---|
| Model guardrails | What the model says | Content filters, prompt-injection defences | Upstream — screen output; do not authorise action |
| SAFR (runtime governance) | Whether the action may execute | The four components above | The pre-execution decision point |
| Settlement / rails | How value moves | SWIFT, card networks, ACH, MPP, Purpose Bound Money, stablecoin rails | Downstream — act only after SAFR clears the action |
| Compliance platforms | Assessing the action | AML/KYC, sanctions screening, transaction monitoring | SAFR may invoke these; it does not replace them |
Explicitly, SAFR is not a payment scheme, not a replacement for compliance engines, not an LLM safety tool, and not a managed service. It is an industry reference approach — institutions implement it inside their own infrastructure with their own rule configurations. That last point is the one APAC buyers should internalise: there is no "SAFR product" to procure. There is an architecture to build, and a set of conditions each proposed agent action must satisfy.
Why This Lands in Singapore First: The APAC Governance Stack
SAFR does not arrive in a vacuum. It is the runtime layer on top of a governance stack that Singapore has been assembling since Project MindForge was announced at the Point Zero Forum in June 2023 — three years of continuous build-out — and that regional context is exactly what makes it enforceable here before anywhere else.
- Project MindForge (MAS + a consortium across banking, insurance, and capital markets). Phase 2 launched November 2024 and published at the Singapore FinTech Festival in November 2025. Its Executive Handbook sets out 17 Considerations across four sections; its Operationalisation Handbook already prescribes agentic-specific practices SAFR now operationalises at runtime — principle of least privilege for agent tool/data access, agent certification for reusable components, design-time accountability, kill switches and timeouts, and traceability through searchable logging.
- MAS Guidelines on AI Risk Management (2025) — the supervisory backdrop against which each institution must still map its own deployment.
- IMDA Model AI Governance Framework for Agentic AI (v1.5, 2026) — four agentic components (models, memory, tools, actions) and a four-part governance model (use-case bounding, access limitation, human oversight, principal-hierarchy accountability). SAFR is the runtime enforcement of precisely this.
- NIST AI RMF 1.0 (Map/Measure/Manage/Govern) and FSB systemic-risk work provide the international alignment.
That first-mover position isn't only regional. Scoped precisely — a runtime, per-action governance standard for agentic AI in finance — SAFR appears to be the first of its kind globally, and the comparison sharpens rather than softens under scrutiny. The EU AI Act's high-risk obligations were slated for full enforcement on 2 August 2026; under the Digital Omnibus agreement reached in May 2026 (pending formal adoption), that deadline has since been pushed to December 2027 — and even once in force, the Act governs at the model/risk-management level, not per-action execution. In the US, the Federal Reserve, OCC, and FDIC issued SR 26-2 in April 2026 — the first refresh of model risk management guidance in fifteen years, superseding SR 11-7 — and it explicitly places generative and agentic AI models outside its scope, calling them "novel and rapidly evolving." Even Singapore's own IMDA Model AI Governance Framework for Agentic AI operates one level up: identity, audit trails, and access controls for agentic AI broadly, without SAFR's finance-specific, per-action Disposition Engine. Put plainly: while the EU is deferring its rules and US federal banking regulators are declining to cover agentic AI at all, MAS has already published a working runtime standard for it. That is not incremental regulatory activity — it is a jurisdiction choosing to lead.
Layer PDPA over this for any workflow touching client documents — source-of-wealth memos, KYC files, credit assessments — and the picture for an APAC FSI is specific rather than aspirational. Generic global governance content cannot reproduce this stack because it does not sit inside the regulatory geography that produced it. For DataMy's clients across Singapore and Greater China FSI, that is the difference between a whitepaper and a build plan.
Eight Institutions, One Pattern: The Agent Pilots Already Live
The white paper maps live pilots onto the four components. Note these are SAFR contributors' own systems, read through the SAFR lens — not products MAS endorses. The pattern that repeats across all of them is the same: identity first, mandate-bound authority, pre-execution disposition, tamper-evident record.
| Domain / Institution | Programme | Identity mechanism | Control mechanism |
|---|---|---|---|
| Treasury — Ant International | Agentic Treasury Protocol | Digital Agent Passport linking each agent to a named human principal; verification scales with transaction size/risk | Agents execute treasury functions only within human-set policy limits |
| Consumer payments — Mastercard | Agent Pay | Agentic Token — a KYC-analogous registration binding agent identity to operator and end-user, cryptographically tied to the payment token | Mandate encoded as signed, machine-readable policy; circuit breakers at agent/principal/counterparty level; ambiguity → default to inaction; aligned to Mastercard's Verifiable Intent framework |
| Consumer payments — Visa | Visa Intelligent Commerce (VIC) | Token Requester Identifiers at the network level; consumer instruction confirmed via Passkey (FIDO biometric) | Instruction converted to a network-stored digital rule (amount, merchant scope, validity); over-limit attempts declined at the network before processing |
| Agentic commerce — Circle | Agent Wallet | Portable on-chain identity under ERC-8004, resolvable via the institution's registry or the Circle Payments Network | Per-transaction and aggregate caps + permitted recipients set at build time; per-call signed authorisation; Circle Compliance Engine screens sanctions; Legal Context Protocol captures recourse |
| Wealth — OCBC (with Bank of Singapore) | Source of Wealth Assistant (SOWA) | Narrowly scoped, identified agents bound to permitted document-analysis tasks | Agents extract/draft/check only — no end-to-end decisions; human review at critical points; outputs advisory, subject to human validation |
| Insurance — Manulife | GenAI sales enablement | Every request records the adviser identity | Only approved enterprise content retrievable; LLM-as-a-Judge evaluation against SME-curated answers; no autonomous execution pathway into financial systems |
Two things worth pulling out. First, the payment-network pilots (Mastercard, Visa, Circle) converge on the same primitive from different directions: a mandate the agent physically cannot exceed, checked at the network layer before value moves — the "principle of least privilege" made mechanical. Second, the two most conservative deployments (OCBC SOWA and Manulife) share a deliberate design choice: the agent drafts and the human decides. In regulated wealth and insurance advisory, SAFR's Escalate and human-review pathway is not a fallback — it is the default posture. That is the correct reading for most APAC advisory use cases today.
Wiring It In Without Rewriting Your Core: Native vs. Gateway
SAFR supports two deployment patterns, and the right one depends on whether you are governing new agent capability or bringing existing deployments under control.
| Native Integration | Gateway Integration | |
|---|---|---|
| How | The agent is instrumented to emit a Governance Envelope before each action; the SAFR validator returns a disposition before the agent acts | A gateway intercepts outbound API calls at the infrastructure layer, wraps each in an envelope, and evaluates it — no change to agent code |
| Best for | New, in-house or modern-API agents | Legacy systems, third-party agents, deployments where code changes aren't feasible |
| Strength | Tightest integration, most granular record, cleanest audit trail | Coverage without re-engineering; unblocks development teams |
| APAC fit | Greenfield agent builds at Tier-1 banks | The realistic starting point for mid-market FSIs and insurers on legacy cores |
For the ASEAN mid-market specifically — where core systems are older and engineering bench-strength is thinner — the gateway pattern is the pragmatic entry point: establish coverage across your existing agent estate first, then move new builds to native instrumentation as they come online. You do not have to rewrite your core to start governing agent actions.
On the controls side, SAFR names four independently configurable categories, owned by risk and compliance leadership — not engineering:
- Authorisation — which agents may act for which principals, delegation depth, permitted action types.
- Exposure Limits — per-action and aggregate value thresholds (should mirror your existing delegated-authority framework, not invent a new one).
- Rate Limits — maximum action rate per window; the primary defence against runaway agents, data-feed errors, and injection attacks that make agents act at abnormal volume.
- Evidence Quality — minimum confidence and required evidence for autonomous execution; below-threshold actions route to human review regardless of value.
And a warning SAFR makes explicit, which we underline for every client: escalation must be substantive, not nominal. Three operational tests — (1) escalation volume you can actually process, (2) review turnaround with a hard timeout that defaults to block or senior escalation, including overnight/weekend coverage, and (3) reviewer authority to genuinely approve, modify, or decline. An escalation queue no one can clear in time is not oversight; it is theatre with an audit trail.
Read the Fine Print: This Is a Data Architecture Mandate in Disguise
Strip away the compliance vocabulary and SAFR is a set of demands on your data platform. Every one of the four components is a data problem before it is a governance problem:
Figure 2 — The four SAFR components are four data-platform capabilities. No agent governance is possible without the data foundation underneath.
- Agent Identity requires an authoritative, queryable agent registry — and, in open networks, resolution logic across multiple registries. If you cannot answer "which agent, bound to which principal, under which mandate" as a lookup, you cannot run SAFR.
- Controls Repository requires mandates and policies as machine-readable, versioned records, not PDFs and wiki pages. This is a governed-metadata problem your catalog and policy store should own.
- Disposition Engine requires low-latency access to current account/system state and risk parameters at the moment of proposal — a real-time context layer, not a nightly batch.
- Audit Log requires an append-only, tamper-evident store that your existing AML/KYC and monitoring systems can consume — and that survives an auditor asking to reconstruct an event without trusting the agent.
This is the same architectural muscle we argue for in Agentic Data Engineering in 2026 (multi-agent orchestration and human-in-the-loop gates) and MCP and Enterprise Data Integration for AI Agents (MCP as the governed tool-access layer). It's also the same distinction we draw in The Ontology Renaissance — SAFR's mandate is authenticated authority, never inferred, which is exactly the "meaning, not proximity" argument applied to financial actions instead of business definitions. And it's the same governance question we raise in Why AI Agent Memory Is a Data Architecture Problem: SAFR's Disposition Engine and Audit Log are, in effect, deciding and recording what an agent is allowed to act on — the execution-layer counterpart to governing what an agent is allowed to remember. SAFR is the FSI-specific, regulator-facing expression of the same principle we keep returning to: agents are only as trustworthy as the governed data foundation underneath them. The semantic layer, the catalog, the policy store, and the audit substrate are not adjacent to agentic finance — they are agentic finance governance.
FAQ
What is MAS SAFR? SAFR (Safeguards for Agentic Finance at Runtime) is a runtime governance framework published by the Monetary Authority of Singapore in July 2026, developed with Ant International, Circle, HSBC, J.P. Morgan, Manulife, Mastercard, OCBC, and Visa. It defines how an institution evaluates an AI agent's proposed action — before execution — using four components (Agent Identity, Controls Repository, Disposition Engine, Audit Log) coordinated through a Governance Envelope. It is an industry reference approach, not regulatory guidance and not a product.
How is SAFR different from AI guardrails? Guardrails operate at the model's input/output layer and are probabilistic — they shape what a model says. SAFR operates at the execution layer and is deterministic about authority — it decides whether a proposed financial action is permitted before it runs. A model can pass every guardrail and still propose a payment beyond its mandate; SAFR is the layer that blocks it.
What are the four Disposition Engine outcomes? Auto-Execute (proceed autonomously), Observe (proceed but log for monitoring), Escalate (hold for human review), and Deny (reject before execution, with a recorded reason). Outcomes are calibrated at design time to action reversibility, financial materiality, customer impact, regulatory sensitivity, and novelty.
Do we need to rewrite our systems to adopt SAFR? No. SAFR supports Gateway Integration — a gateway intercepts outbound API calls at the infrastructure layer and wraps each in a Governance Envelope without touching agent code. This is the practical starting point for legacy cores and third-party agents common in the APAC mid-market. New builds can use Native Integration, where the agent emits envelopes directly.
How does SAFR relate to Singapore's other AI frameworks? SAFR is the runtime enforcement layer on top of MAS's Project MindForge (Executive and Operationalisation Handbooks), the MAS Guidelines on AI Risk Management (2025), and IMDA's Model AI Governance Framework for Agentic AI (v1.5, 2026). It also aligns with NIST AI RMF and FSB systemic-risk guidance. For workflows touching client data, PDPA obligations apply on top.
Is SAFR mandatory for financial institutions in Singapore? No. SAFR is explicitly a reference approach, not a regulatory requirement or supervisory expectation. Each institution remains responsible for aligning its deployment with applicable supervisory expectations and internal governance. In practice, it is likely to become the shared vocabulary APAC regulators and FSIs use to discuss agentic AI governance.
Work with DataMy: Building the Data Layer Under Agentic Finance
DataMy works with APAC financial institutions on the data and governance architecture SAFR assumes but does not build for you:
- SAFR readiness assessment — mapping your current agent estate against the four components and the two integration patterns; identifying where a gateway gets you coverage fastest.
- Agent registry & mandate store — designing the machine-readable identity and mandate layer the Controls Repository depends on.
- Runtime context & audit substrate — the low-latency state layer for the Disposition Engine and the append-only, tamper-evident log your AML/KYC and monitoring systems can consume.
- Human-in-the-loop design — escalation volume, timeout, and reviewer-authority design so oversight is substantive, not nominal.
Lead magnet: we maintain a one-page SAFR Readiness Checklist — the four components, the four control categories, and the three escalation tests, as a scorecard you can run against your own deployment. Email [email protected] with "SAFR checklist" and we'll send it.
Read next: Agentic Data Engineering in 2026 · MCP and Enterprise Data Integration for AI Agents · The Ontology Renaissance · Why AI Agent Memory Is a Data Architecture Problem
Primary Source & References
Primary source — read the white paper:
- Monetary Authority of Singapore. (2026). Safeguards for Agentic Finance at Runtime (SAFR), White Paper v1.0, July 2026. → SAFR white paper (PDF) · publication page · MAS media release Contributing institutions: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, Visa.
Governance frameworks referenced:
- Monetary Authority of Singapore. (2023). MAS Partners Industry to Develop Generative AI Risk Framework for the Financial Sector (media release, 15 Nov 2023; Project MindForge announced by DPM Heng Swee Keat at the Point Zero Forum, 26 June 2023).
- MindForge Consortium (MAS). (2025–26). AI Risk Management — Executive Handbook & Operationalisation Handbook. See also Project MindForge.
- Monetary Authority of Singapore. (2025). Guidelines on Artificial Intelligence Risk Management.
- Infocomm Media Development Authority. (2026). Model AI Governance Framework for Agentic AI (updated v1.x, May 2026).
- National Institute of Standards and Technology. (2023). AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1.
- Financial Stability Board. (2024). The Financial Stability Implications of Artificial Intelligence; FSB. (2026). Sound Practices for Responsible Adoption of AI (Consultation Report).
- European Union. (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act) — high-risk system obligations, originally due 2 August 2026, deferred to 2 December 2027 under the Digital Omnibus agreement (7 May 2026, pending formal adoption).
- Board of Governors of the Federal Reserve System, OCC, FDIC. (2026). SR 26-2: Revised Guidance on Model Risk Management (17 April 2026) — supersedes SR 11-7 and SR 21-8; explicitly excludes generative and agentic AI models from scope.
Technical / academic references cited in SAFR:
- Davidovic, S., & Tourpe, H. (2026). How Agentic AI Will Reshape Payments (IMF Note 2026/004).
- Aldasoro, I., & Desai, A. (2025). AI Agents for Cash Management in Payment Systems (BIS Working Paper No. 1310).
- See, K., & Tan, X. W. (2026). Compliance-Aware Agentic Payments on Stablecoin Rails (arXiv:2605.00071).
- Dennis, J. B., & Van Horn, E. C. (1966). Programming Semantics for Multiprogrammed Computations. Communications of the ACM, 9(3) — origin of capability-based security.
- Hardt, D. (Ed.). (2012). The OAuth 2.0 Authorization Framework (RFC 6749).
Source: Monetary Authority of Singapore, "Safeguards for Agentic Finance at Runtime" (SAFR), White Paper v1.0, July 2026 — mas.gov.sg. Analysis by DataMy.