SAFR, Explained: Inside MAS's Runtime Framework for AI Agents in Finance

Why SAFR exists¶

Financial institutions are deploying AI agents that act. They initiate payments, submit trading orders, approve credit applications, file regulatory reports, and settle insurance claims — often at high frequency, with no human reviewing each individual action. The paper names five application areas where governance concerns are heightened: payments, liquidity management, compliance triage, credit assessment, and post-transaction processing.

There is a systemic dimension as well. When many institutions rely on a small number of common AI service providers, their agents can behave in correlated ways. The Financial Stability Board has identified this correlation as a potential systemic vulnerability.

Against that backdrop, SAFR identifies three gaps in the governance infrastructure institutions already run.

Gap 1: pre-execution assurance. Model risk management validates a system before deployment. Audit examines what happened after the fact. Neither discipline catches a problematic agent decision in the moment before it executes.

Gap 2: the human-agent governance interface. Escalation to a human today is ad hoc — a notification, an email alert, a dashboard flag — with no deadline, no standard decision format, and no audit record. The paper calls this "the appearance of human oversight without the substance of it."

Gap 3: fragmentation. Each deployment builds its own guardrails. The results are non-interoperable and cannot be audited in a consistent format across the institution.

SAFR is a proposed answer to all three: a standing checkpoint in the execution path, a structured escalation contract with deadlines and decision records, and one consistent governance format across every agent.

What is SAFR?¶

In the paper's own words, SAFR "defines data structures, evaluation logic, and escalation contracts for agentic AI deployment. It sits between the agent and the systems it acts on, evaluating proposed actions before execution, while working alongside existing payment rails, settlement protocols, compliance engines, and core banking systems."

Three boundaries matter for anyone reading it with a compliance mandate.

First, SAFR carries no supervisory force. The paper is explicit: "It does not constitute regulatory guidance or supervisory expectations." Each institution remains responsible for determining how its own deployment aligns with applicable supervisory expectations and internal governance requirements.

Second, SAFR is a specification for institutions to build against. "It serves as an industry reference for institutions to implement within their own infrastructure, using their own rule configurations and governance arrangements." There is no MAS-operated SAFR service to subscribe to.

Third, SAFR is scoped to the runtime decision. It defines how a proposed action is identified, authorized, evaluated, and recorded at the moment of action. Model validation, lifecycle management, and broader AI risk frameworks sit around it (more on that ecosystem below).

The four SAFR runtime components¶

SAFR's architecture is four components interacting through a shared data structure, the Governance Envelope. Each component answers one question about a proposed action.

Agent Identity binds each proposed action to a recognized, registered agent, verified against that agent's registry entry before any other evaluation proceeds. In a closed-loop environment, the institution's own registry answers with a direct lookup. On open networks, an agent may be registered in multiple identity databases — the institution's internal registry, a payment network's agent registry, an inter-institutional directory — and the component determines which registry is authoritative for the action at hand. A failed identity check produces an immediate rejection, recorded in the Audit Log.

The Controls Repository is where the institution encodes its rules. Controls are drawn from organizational policies, regulatory requirements, product rules, and mandates or authority granted by users. Generic controls such as authorization checks and exposure limits are deterministic. AI-specific controls, such as evidence quality and envelope integrity, may involve probabilistic or semantic assessment. Every control encodes five things: the permitted action types, the decision logic, the escalation conditions, a validity period, and the principal authority behind it.

The Disposition Engine evaluates each in-scope action deterministically against the retrieved controls, producing "a defined, binding outcome for every proposed action calibrated to the specific risk it presents." The four possible outcomes are covered in depth below.

The Audit Log records every governance decision in an append-only, tamper-evident form. Each entry captures six elements: the Governance Envelope as submitted, the mandate against which the action was checked, the outcome the Disposition Engine produced, the specific rules applied, the basis for that outcome, and the time elapsed at each stage. Per the paper: "The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact."

The lifecycle ties the four together. A proposed action is packaged in a Governance Envelope and validated for completeness and coherence. Agent Identity is verified against the relevant registry; failure means immediate, logged rejection. The Controls Repository identifies which controls to check. The Disposition Engine determines the applicable thresholds and returns one of four outcomes. The Audit Log records the full governance trace for every outcome, including actions that proceeded without intervention.

The Governance Envelope¶

Before any agentic action executes, it is packaged with the context needed to assess it. The envelope carries three classes of information.

The envelope has an integrity problem the paper confronts directly. The action trace and the action details are both agent-declared, which means a sophisticated adversarial injection could fabricate them together — a plausible-looking trace wrapped around an unauthorized action. The paper's response: "The envelope is therefore treated as a document to be authenticated against its origin, not merely as a record of what the agent reported." Implementations need a way to verify that the envelope reflects what actually happened, at its source.

Mandates and capability-based authority¶

"A mandate is the mechanism through which a user defines the bounds of the authority delegated to an agent." It is explicit and machine-readable: what the agent may do, within what limits, under what conditions.

The design draws on capability-based security, a lineage the paper traces to Dennis and Van Horn's 1966 work — the same tradition that underlies OAuth 2.0. The load-bearing property: "An agent cannot extend the scope of a mandate through its own reasoning or inference. Authority is explicit, structured, and defined by the mandate, not inferred by the agent." However fluent an agent's justification for exceeding its bounds, the mandate is the boundary.

The paper cites the Agent Payments Protocol (AP2) as a prominent industry example, with cryptographically signed mandates.

The four SAFR dispositions: Deny, Escalate, Auto-Execute, Observe¶

The Disposition Engine resolves every in-scope action to one of four outcomes. All four feed the Audit Log.

Observe lets an institution keep low-risk automation flowing while building a reviewable record of the cases it wants eyes on later.

Which disposition an action receives is a calibration question, settled at design time through the governance parameters of the controls. The paper names five calibration factors: action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty or anomaly — meaning departure from established patterns within the mandate. Higher-risk profiles shift outcomes toward Deny or Escalate.

No authority carries forward between steps¶

Agentic workflows are rarely a single action. An agent enriches data, calls tools, adapts to intermediate results, and proposes its next step based on what it just learned. SAFR's answer is per-action governance: the control flow applies to each agent action independently.

The paper is precise on the consequence: "An Auto-Execute or Observe outcome at one step carries no authority into the next." Prior authorization does not carry forward as the agent adapts to intermediate results and changing conditions. Step three of a workflow gets the same identity check, control retrieval, and disposition as step one. For institutions, this closes the scenario where an agent earns one approval early and then drifts, fully "authorized," into territory nobody reviewed.

The two SAFR deployment patterns¶

SAFR describes two ways to put the checkpoint into an institution's stack.

The paper offers sequencing guidance for institutions that already run agents: "For institutions with many existing agents, the gateway pattern serves as a practical starting point by establishing coverage first and native instrumentation can follow for new builds." Coverage first, depth second.

What institutions configure: the four control categories¶

SAFR leaves the rulebook to the institution. Its Table 1 defines four categories of control an implementation should support.

Two design notes from the paper stand out. Exposure limits should mirror the delegated authority frameworks the institution already runs for humans, so agent authority slots into an existing governance vocabulary. And evidence quality operates independently of value: a low-confidence action routes to a human even when the amount at stake is trivial.

Operating the escalation path¶

An Escalate disposition is only as good as the human review process behind it. SAFR names three operational dimensions institutions have to engineer deliberately.

Escalation volume. An escalation function that generates more reviews than the institution can meaningfully process defeats its own purpose. Thresholds have to be calibrated against real reviewer capacity.

Review turnaround. Escalations should include a timeout window. If no decision arrives within it, the default is to block the action or escalate to a senior reviewer. The window should reflect realistic reviewer availability, including overnight and weekend coverage.

Reviewer authority. Reviewers must have clear authority to approve, modify, or decline the action, and their decisions "carry the same institutional weight as the original agent decision." A reviewer who can only rubber-stamp reproduces the gap SAFR set out to close.

Where SAFR sits in the stack¶

A useful way to read SAFR is as a layer with defined neighbors. The flow: the AI agent produces a proposed action (its guardrails may shape the output); SAFR verifies agent identity and authority and evaluates the action against controls deterministically, returning Auto-Execute, Observe, Escalate, or Deny; the financial rails execute if and only if the action was approved.

Relative to AI guardrails. Content filtering, prompt-injection defenses, and output filtering are typically probabilistic, and they govern what the model produces. Whether a proposed financial action is authorized and executable is a separate determination, and it is the one SAFR makes. SAFR operates after content filtering and before execution.

Relative to compliance platforms. SAFR generates the structured governance record that existing compliance platforms can draw on. It does not replicate their assessments.

Relative to settlement rails. Payment schemes and settlement rails move money. SAFR governs the decision to move it. Settlement-layer enforcement — card network rules, SWIFT standards, ACH rules, the Machine Payments Protocol (MPP), Purpose Bound Money (PBM), stablecoin controls — operates after SAFR has determined whether the agent may act at all.

Relative to a product. SAFR is a specification. There is no managed service to buy from MAS; every institution implements the pattern within its own infrastructure or adopts tooling that does.

Who wrote SAFR, and the ecosystem around it¶

SAFR came out of a dedicated work stream MAS established under its BuildFin.ai program to develop implementation resources for agentic AI risks. It was written with eight industry members: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa. The paper grounds the specification in member case studies: Ant International's Agentic Treasury Protocol, Mastercard's Agent Pay and Agentic Tokens, Visa Intelligent Commerce, Circle's Agent Wallet, ERC-8004, Circle Payments Network and Compliance Engine, OCBC with Bank of Singapore's Source of Wealth Assistant (SOWA) alongside an internal corporate-banking market and client-intelligence brief agent, and Manulife's GenAI sales enablement work. HSBC and J.P. Morgan Chase contributed to the paper without named case studies.

SAFR also has defined neighbors in the governance literature. Project MindForge — MAS with a consortium of financial institutions across banking, insurance, and capital markets — launched its Phase 2 in November 2024 and published at the Singapore FinTech Festival in November 2025: an Executive Handbook with 17 Considerations across four sections (Scope and Oversight, AI Risk Management, AI Lifecycle Management, Enablers) and an Operationalisation Handbook covering least privilege for agent tool and data access, agent certification, accountability division at design time, kill switches and timeouts, and traceability through searchable logging. IMDA's Model AI Governance Framework for Agentic AI (2026) frames agentic systems around four core components (models, memory, tools, actions) and a four-part governance model (use-case bounding, access limitation, human oversight, principal hierarchy accountability). NIST's AI RMF (2023) contributes the Map, Measure, Manage, Govern cycle. SAFR is the runtime-specific layer of that stack: the data structures, evaluation logic, and escalation contracts for the moment of action.

The paper closes with an open invitation: "FinTechs and financial institutions are invited to contribute to SAFR and the BuildFin.ai working group by sharing pilot findings, identifying gaps in the specification, and raising domain requirements not yet addressed."

What to do next¶

For a team assessing where it stands against SAFR, the productive first step is a structured gap assessment across the paper's own dimensions: agent inventory and identity, mandates, controls, dispositions, envelope and lineage, escalation operations, audit and evidence, and deployment pattern. The SAFR Readiness Checklist walks through roughly 35 assessor-style questions across those eight sections and scores readiness per section, with an editable spreadsheet version for working sessions.

Teams past assessment and into build planning should read the companion piece, How to Implement SAFR: Architecture, Patterns, and Build vs Buy, which covers the reference architecture, worked control examples, and a build-versus-buy analysis.

How KLA maps to SAFR¶

KLA Control Plane implements the SAFR pattern, shipping today: Agent Registry for Agent Identity, Policy Builder for the Controls Repository, KLA Policy Engine for the Disposition Engine, and Audit Trail for the Audit Log, with the four dispositions mapped one-to-one: Deny to block, Escalate to require_approval, Auto-Execute to allow, and Observe to warn. The full component-by-component mapping, including operating requirements and current status flags, is on the SAFR implementation page.