No. SAFR is an industry reference that "does not constitute regulatory guidance or supervisory expectations," and adopting it is each institution's own decision. For an implementer the consequence is that the alignment burden sits with you: each institution remains responsible for determining how its deployment aligns with applicable supervisory expectations and internal governance requirements. The operating requirements table on this page is a working checklist for that determination, and the SAFR Readiness Checklist scores your current estate against the same ground.

MAS's BuildFin.ai program, with industry members Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa — white paper version 1.0, July 2026. For an implementer the working form of that answer is the citation line to carry in internal governance papers that reference a SAFR-aligned build: "Safeguards for Agentic Finance at Runtime, white paper v1.0, MAS BuildFin.ai, July 2026" — the same attribution this page carries in its footer. Program background and authorship detail are in SAFR, explained.

What are the four SAFR dispositions?

In a KLA implementation they land as the four decisions a published policy resolves to: Deny maps to block (the action is stopped in the execution path, reason codes mandatory), Escalate to require_approval (the action pauses while a Decision Request routes to a named reviewer on the Decision Desk), Auto-Execute to allow (the action proceeds with the decision and its policy basis recorded in full), and Observe to warn (the action proceeds flagged, with sampled runs routed to scheduled human spot checks). SAFR's Disposition Engine defines the four outcomes and the five calibration factors that drive them; SAFR, explained covers the definitions. The implementation work is calibration: the thresholds you author in Policy Builder decide where each action class lands, and week two of the pilot plan above is dedicated to tuning that split.

Does KLA replace our compliance platform?

No. SAFR scopes the runtime governance layer to generate the structured governance record that existing compliance platforms can draw on; it does not replicate their assessments. KLA follows that scoping: transaction monitoring, screening, and case management keep running where they run today, and KLA supplies the per-action decision and evidence record beneath them.

How long does a SAFR pilot take?

Four weeks on the plan above: week one to scope and author policies, week two to calibrate dispositions in Simulation, week three to run live escalations on the Decision Desk, week four to export Sealed Evidence Bundles for independent offline verification and hold the go/no-go readout. A live walkthrough of one governed run takes thirty minutes.

Can existing agents be brought under SAFR governance?

Yes. On KLA the path depends on where the agent runs: agents on KLA Runtime are governed natively by construction, and agents outside KLA take the standalone enforcement gateway, which is in staged rollout with approval-resume on that path in development. The gateway is KLA's implementation of SAFR's Gateway Integration pattern — interception of outbound calls at the infrastructure layer, each wrapped in a Governance Envelope, with no changes to agent code. For an estate with many existing agents, sequence it the way the paper recommends: establish gateway coverage first, instrument new builds natively. While approval-resume is in development, scope escalation-heavy workflows onto KLA Runtime.

MAS BuildFin.ai reference

Implement SAFR — Safeguards for Agentic Finance at Runtime

Implement SAFR, the MAS BuildFin.ai runtime governance reference for agentic AI in finance. Component map, dispositions, and a 4-week pilot plan.

Book a 30-minute SAFR gap review SAFR Readiness Checklist

The framework

What SAFR is

SAFR — Safeguards for Agentic Finance at Runtime — is a white paper published in July 2026 under MAS's BuildFin.ai program, written with Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa. It describes a reference approach for a runtime governance layer that "sits between the agent and the systems it acts on, evaluating proposed actions before execution." Its central requirement: "no agentic action reaches execution without having been declared, authorised, and assessed." SAFR is an industry reference for institutions to implement within their own infrastructure; the paper states it "does not constitute regulatory guidance or supervisory expectations."

KLA Control Plane implements the SAFR pattern, shipping today. This page maps SAFR's four components, four dispositions, and operating requirements onto what KLA ships, marks what is still in development, and lays out a four-week pilot. For a full walkthrough of the framework itself, read SAFR, explained.

Components

The SAFR component map

SAFR defines four runtime components that interact through a Governance Envelope. Each answers one question about a proposed action before it executes. The table maps each component to the KLA capability that implements it.

SAFR component	The question it answers	KLA capability	Status
Agent Identity	Is the actor a recognized, registered agent acting under a verified identity?	Agent Registry	Shipped
Controls Repository	What is this agent permitted to do, within what limits, under what conditions?	Policy Builder	Shipped
Disposition Engine	Does this specific action proceed, proceed flagged, pause for review, or stop?	KLA Policy Engine	Shipped
Audit Log	What was decided, on what basis, and can a third party verify it later?	Audit Trail	Shipped

Agent Identity → Agent Registry. SAFR requires each proposed action to be bound to a recognized, registered agent, verified against a registry entry before any other evaluation proceeds; a failed check is rejected and recorded. In KLA, every agent is a registered, versioned entity with a named human owner and a release state. The runtime is authenticated and tenant-isolated, and each proposed action arrives bound to a verified agent identity.

Controls Repository → Policy Builder. SAFR's controls repository is the institution's configurable rulebook, drawn from organizational policies, regulatory requirements, product rules, and user-provided mandates. In KLA, policies are versioned and machine-readable, covering permitted tools and action types, decision logic, and escalation conditions. Publishing is a governed release: policies are linted fail-closed, and publication requires two-person approval on the Decision Desk.

Disposition Engine → KLA Policy Engine. SAFR requires deterministic evaluation producing "a defined, binding outcome for every proposed action calibrated to the specific risk it presents." In KLA, every proposed action is evaluated against the published policy version before execution and resolves to one of four decisions. Machine-readable reason codes are required on every decision, and the engine fails closed if the decision service is unreachable.

Audit Log → Audit Trail. SAFR requires an immutable, tamper-evident, append-only record of every governance decision, capturing the envelope as submitted, the mandate checked, the outcome, the rules applied, the basis for the outcome, and the time elapsed at each stage. KLA's Audit Trail is append-only and tamper-evident, recording the action and its parameters, the policy version, the rules fired, the decision with reason codes, and any human approval. It exports as Sealed Evidence Bundles that verify offline, independent of KLA.

Dispositions

The four SAFR dispositions

SAFR's Disposition Engine resolves every in-scope action to one of four outcomes. KLA's decision vocabulary maps to them one to one.

SAFR disposition	KLA decision	Behavior
Deny	`block`	The action is stopped in the execution path. Reason codes are mandatory.
Escalate	`require_approval`	The action pauses. A Decision Request routes to a named, authorized reviewer on the Decision Desk.
Auto-Execute	`allow`	The action proceeds. The decision, its context, and its policy basis are recorded in full.
Observe	`warn`	The action proceeds flagged. A sampling review queue routes sampled runs to a scheduled human spot check.

All four outcomes are recorded in the Audit Trail. SAFR names five calibration factors that drive outcome assignment — action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty or anomaly relative to established patterns within the mandate. Higher-risk profiles shift outcomes toward Deny or Escalate. Calibration is set at design time through the governance parameters of the controls; in KLA that means the thresholds you author in Policy Builder.

Operating requirements

SAFR operating requirements A–H

These are the requirements a SAFR implementation has to meet in operation, and how KLA meets each one. Status flags are strict: Shipped means the capability is in the product today; In development means it is being built and you should plan around its absence.

#	Requirement	How KLA meets it	Status
A	Governance Envelope, authenticated by construction — the envelope is "a document to be authenticated against its origin"	The checkpoint sits inside the execution path; the record is assembled from the intercepted call itself. The full action trace is preserved as a Lineage Record, reconstructable in the Lineage Explorer.	Shipped
B	Per-action authorization in multi-step work — prior authorization "should not carry forward" between steps	Every tool call is re-authorized. `allow` at one step confers no authority at the next. Multi-step Processes permit declared transitions only, require the actor class to match, and keep human-reserved steps architecturally closed to agents.	Shipped
C	Authorization and mandates — explicit, machine-readable delegated authority	Policies bind agents to permitted tools and action types via the Tool Catalog. Connector credentials live per-connection in the Secrets Vault, scoped server-side. Published policies are content-addressed and signed; the runtime verifies signature and published status before evaluating.	Shipped
D	Exposure limits and rate limits — per-action and aggregate value thresholds, maximum action rates	Per-action thresholds are policy decision logic today. Execution budgets cap steps, spend, and wall clock per run, with an enforced kill switch and incident levers. Aggregate exposure windows and per-window rate limits are being built as policy primitives.	Run containment: shipped. Windowed limits: in development
E	Evidence quality — minimum evidence and confidence for autonomous execution	Policy can require an AI-judge match between agent output and the expected evidence contract; a mismatch resolves to escalation or block. Content rails for injection, jailbreak, and sensitive-data patterns run in the same path. Confidence thresholds as a first-class routing primitive are being built.	Semantic checks: shipped. Confidence thresholds: in development
F	Substantive human escalation — routing, reviewer authority, turnaround	Structured Decision Requests carry full action context to role-gated, named reviewers. Maker-checker separation is enforced server-side. Every approval and decline is recorded with rationale, with queue and turnaround analytics. Timeout defaults per decision class are being built.	Shipped. Timeout defaults: in development
G	The audit record — tamper-evident, independently verifiable	The decision is returned only once evidence has persisted, and the path fails closed on write failure. The ledger is hash-chained. Sealed Evidence Bundles carry a signed manifest, per-artifact inclusion proofs, and an external timestamp commitment; the offline verifier needs no access to KLA.	Shipped
H	Deployment patterns — native instrumentation and gateway interception	Agents on KLA Runtime are governed natively by construction. A standalone enforcement gateway for agents outside KLA is in staged rollout; approval-resume on that path is in development.	Native: shipped. Gateway: in development (staged rollout)

For architecture detail, deployment-pattern selection, and a SAFR vendor build-vs-buy analysis, see How to implement SAFR.

Evidence

The four SAFR evidence artifacts

A SAFR implementation is judged by the records it produces. The white paper puts it directly: "The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact." A working implementation produces four kinds of artifact, on demand.

Decision record with reason codes. Every evaluated action resolves to `allow`, `warn`, `require_approval`, or `block`, with machine-readable reason codes, the policy version applied, and the specific rules that fired.
Lineage Record of the action trace. The steps the agent actually executed in arriving at the proposed action — tool calls made, data retrieved, checks performed — preserved as tamper-evident lineage and reconstructable in the Lineage Explorer.
Decision Desk approval record. For every escalated action: the named reviewer, their role-gated authority, the approve-or-decline outcome, and the recorded rationale, with maker-checker separation enforced server-side.
Sealed Evidence Bundle, verifiable offline. An export carrying a signed manifest, per-artifact inclusion proofs, and an external timestamp commitment. An auditor, assessor, or counterparty can verify it with no access to KLA.

If a SAFR software vendor or an in-house build cannot produce all four, the audit record has gaps an inspector will find.

Pilot plan

A four-week SAFR-aligned pilot

KLA has demonstrated this end to end on financial-crime and client-onboarding workloads. A live walkthrough of one governed run — policy, decision, escalation, sealed evidence — takes thirty minutes. A pilot that produces a defensible go/no-go takes four weeks.

Week	Work	Output
1	Scope one agent workflow. Register the agent in the Agent Registry with a named owner. Author policies in Policy Builder: permitted tools and action types, thresholds, escalation conditions. Publish through the governed release path (lint fail-closed, two-person approval).	A published, signed policy governing one real workflow
2	Run governed traffic in Simulation. Calibrate dispositions against SAFR's five factors: reversibility, materiality, customer impact, regulatory sensitivity, novelty. Review the split across `allow` / `warn` / `require_approval` / `block`.	A calibrated disposition profile with evidence of the tuning
3	Go live with escalations on the Decision Desk. Named reviewers work real Decision Requests. Tune thresholds using queue and turnaround analytics; keep escalation volume within what reviewers can meaningfully process.	An operating escalation loop with recorded approvals and rationale
4	Export Sealed Evidence Bundles for the pilot period. Hand them to an independent party — internal audit or an external assessor — for offline verification. Run the go/no-go readout against the operating requirements table above.	Independently verified evidence and a go/no-go decision

For a worked example on a compliance-triage workload — the application class the SAFR paper names among those where governance concerns are heightened — see SAFR for AML.

Next steps

Downloads and next steps

SAFR Implementation Map (PDF)

Two pages: the component map, the disposition grammar, and operating requirements A–H with statuses.

SAFR Readiness Checklist

Score your current estate across eight sections — agent identity, mandates, controls, dispositions, envelope and lineage, escalation operations, audit and evidence, deployment pattern. Ungated on the page; the editable sheet downloads via email.

Open the checklist

Book a 30-minute SAFR gap review

Bring one agent workflow. We map it against the operating requirements table and tell you where you stand.

Book a 30-minute SAFR gap review

FAQ

Frequently asked questions

Is SAFR mandatory?: No. SAFR is an industry reference that "does not constitute regulatory guidance or supervisory expectations," and adopting it is each institution's own decision. For an implementer the consequence is that the alignment burden sits with you: each institution remains responsible for determining how its deployment aligns with applicable supervisory expectations and internal governance requirements. The operating requirements table on this page is a working checklist for that determination, and the SAFR Readiness Checklist scores your current estate against the same ground.
Who published SAFR?: MAS's BuildFin.ai program, with industry members Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa — white paper version 1.0, July 2026. For an implementer the working form of that answer is the citation line to carry in internal governance papers that reference a SAFR-aligned build: "Safeguards for Agentic Finance at Runtime, white paper v1.0, MAS BuildFin.ai, July 2026" — the same attribution this page carries in its footer. Program background and authorship detail are in SAFR, explained.
What are the four SAFR dispositions?: In a KLA implementation they land as the four decisions a published policy resolves to: Deny maps to `block` (the action is stopped in the execution path, reason codes mandatory), Escalate to `require_approval` (the action pauses while a Decision Request routes to a named reviewer on the Decision Desk), Auto-Execute to `allow` (the action proceeds with the decision and its policy basis recorded in full), and Observe to `warn` (the action proceeds flagged, with sampled runs routed to scheduled human spot checks). SAFR's Disposition Engine defines the four outcomes and the five calibration factors that drive them; SAFR, explained covers the definitions. The implementation work is calibration: the thresholds you author in Policy Builder decide where each action class lands, and week two of the pilot plan above is dedicated to tuning that split.
Does KLA replace our compliance platform?: No. SAFR scopes the runtime governance layer to generate the structured governance record that existing compliance platforms can draw on; it does not replicate their assessments. KLA follows that scoping: transaction monitoring, screening, and case management keep running where they run today, and KLA supplies the per-action decision and evidence record beneath them.
How long does a SAFR pilot take?: Four weeks on the plan above: week one to scope and author policies, week two to calibrate dispositions in Simulation, week three to run live escalations on the Decision Desk, week four to export Sealed Evidence Bundles for independent offline verification and hold the go/no-go readout. A live walkthrough of one governed run takes thirty minutes.
Can existing agents be brought under SAFR governance?: Yes. On KLA the path depends on where the agent runs: agents on KLA Runtime are governed natively by construction, and agents outside KLA take the standalone enforcement gateway, which is in staged rollout with approval-resume on that path in development. The gateway is KLA's implementation of SAFR's Gateway Integration pattern — interception of outbound calls at the infrastructure layer, each wrapped in a Governance Envelope, with no changes to agent code. For an estate with many existing agents, sequence it the way the paper recommends: establish gateway coverage first, instrument new builds natively. While approval-resume is in development, scope escalation-heavy workflows onto KLA Runtime.

Source: Safeguards for Agentic Finance at Runtime, white paper v1.0, MAS BuildFin.ai, July 2026. Quoted passages © Monetary Authority of Singapore. SAFR is an industry reference and does not constitute regulatory guidance or supervisory expectations. KLA is independent of and not affiliated with, endorsed by, or certified by MAS or BuildFin.ai.