Resources · Framework Explainer

SAFR: Safeguards for Agentic Finance at Runtime.

SAFR is an industry reference framework for governing agentic AI in financial services — at the point of every action, before execution. Introduced in July 2026 through collaboration among financial industry members. This explainer covers what SAFR is, why it exists, the four components, the four dispositions, and how Aureon Runtime implements it as a shipping product.

Why SAFR exists

Existing governance was designed for a different kind of AI.

For most of the past decade, AI in financial services was decision support. Models produced recommendations and humans reviewed them before action. Institutions are now deploying agents that act autonomously — initiating payments, submitting trading orders, approving credit, filing reports — without per-decision human review.

The governance infrastructure hasn't kept pace. Three gaps in particular:

GAP 01

Pre-execution assurance is missing

Model risk management assesses the model before it goes live. Audit reviews sampled transactions hours later. Neither catches a problematic agent decision before it executes.

GAP 02

Human-in-the-loop is ad hoc

No standard for when a human decides. Notifications, dashboard flags, email alerts — no deadline, no audit record, no defined reviewer. The appearance of oversight without the substance.

GAP 03

Guardrails aren't interoperable

Where institutions build agentic controls, they build them independently for each deployment. Not interoperable, not auditable in a consistent format. Every bank rebuilding the same wheel.

The framework

Four components. One Governance Envelope. Four dispositions.

SAFR introduces a governance checkpoint between every agent decision and its execution. The four components interact through a structured record of what the agent intends to do, why, and with what supporting evidence.

The Governance Envelope

Before any agentic action can execute, it is packaged in an envelope with three classes of information:

ACTION

Type. Scope. Parameters of the proposed action.

ACTION TRACE

Steps the agent executed. Tool calls made. Data retrieved. Checks performed.

CONTEXT METADATA

Agent identity. Applicable mandate. Account or system state. Operative policy constraints.

The envelope is treated as a document to be authenticated against its origin — not merely a record of what the agent reported.

The four components.

1 · Agent Identity

Binds each proposed action to a registered, verified agent — before any other evaluation proceeds. Closed-loop registries or open-network directories, depending on the deployment.

2 · Controls Repository

The institution's configurable rulebook. Regulatory constraints, product rules, exposure limits, evidence-quality thresholds, and user-granted mandates.

3 · Disposition Engine

Evaluates each in-scope action deterministically against the retrieved controls. Returns one of four outcomes calibrated to risk.

4 · Audit Log

Tamper-evident, append-only. Every envelope, every disposition, every reason, every timing — preserved as the authoritative record.

The four dispositions

One outcome per action. Calibrated to risk.

The Disposition Engine resolves every in-scope action to one of four outcomes. Higher-risk actions shift toward Deny or Escalate. Lower-risk actions receive Auto-Execute or Observe. Calibration factors: reversibility, financial materiality, customer impact, regulatory sensitivity, novelty.

Deny

The action violates a hard regulatory or policy constraint, or exceeds a defined risk threshold. Rejected before execution. Reason recorded.

Escalate

In scope, below hard constraints, but above the threshold for autonomous execution. Held pending human review, with a defined deadline, reviewer, and audit record.

Auto-Execute

Within scope, below hard constraints, within defined risk thresholds. Proceeds without human intervention. Fully logged for after-the-fact review.

Observe

Permitted to proceed but flagged. Executes while a structured observation is logged. For signals worth monitoring without blocking.

All four outcomes feed into the Audit Log regardless of which was reached. In multi-step workflows, the control flow applies to each action independently — prior authorisation does not carry forward.

Where SAFR sits

Not a replacement. A layer.

SAFR is not the same as content filtering, not the same as observability, not the same as settlement compliance. It sits between them.

LAYER 1 · AGENT-SIDE CONTROLS

Content filtering, prompt defences, output guardrails. Screen out harmful, malformed or policy-violating outputs before they leave the model. Important — but not sufficient.

LAYER 2 · SAFR / RUNTIME GOVERNANCE

Pre-execution governance. Envelope, identity, controls, disposition, audit. Determines whether the agent is permitted to do what it proposes to do.

LAYER 3 · EXECUTION & SETTLEMENT

Payment rails, SWIFT, card networks, ACH, core banking. Governs how value actually moves once the action is submitted. Card network rules, message standards, programmable settlement conditions.

Each layer is essential. None substitutes for another. SAFR is the layer that's been missing.

Integration

Two implementation patterns.

Which pattern to use depends on whether the agent is being newly built or already deployed.

Pattern 1 · Native

Native Integration.

The agent is instrumented to emit a Governance Envelope before each proposed action. The SAFR validator evaluates the envelopes against the controls repository and returns an outcome decision before the agent acts. Tightest integration, most granular governance record, cleanest audit trail. Recommended for new deployments.

Pattern 2 · Gateway

Gateway Integration.

A SAFR gateway intercepts outbound API calls at the infrastructure layer, wraps each call in a Governance Envelope, and evaluates it — without any changes to the agent code. Bring legacy or third-party agents under governance without re-engineering. For institutions with many existing agents, gateway is a practical starting point.

SAFR in production

Documented case studies across financial services.

Six representative implementations from the SAFR white paper — spanning treasury, payments, wealth management, corporate banking and insurance. Different mechanics, same four-component pattern.

Ant International · Agentic Treasury

Identity: Digital Agent Passport. Controls: Machine-readable mandates. Disposition: Circuit breakers at agent, principal or counterparty level.

Mastercard · Agent Pay

Identity: Agentic Token bound to operator + user. Controls: Consumer-scoped authority (merchant, amount, timeframe). Audit: Verifiable Intent framework.

Visa · Intelligent Commerce

Identity: Token Requester Identifiers. Controls: Consumer Passkey confirmation → digital rule on Visa network. Disposition: Real-time check at network level.

Circle · Agent Wallet

Identity: ERC-8004 on-chain identity. Controls: Per-transaction caps + Compliance Engine. Audit: Append-only, reconciled with on-chain settlement.

OCBC · SOWA (with Bank of Singapore)

Identity: Agent bound to workflow triggers. Controls: Narrowly-scoped tasks. Disposition: Human review at critical decision points.

Manulife · GenAI Sales Enablement

Identity: Per-request adviser identity. Controls: Retrieval control, LLM-as-a-Judge evaluation. Disposition: No autonomous execution into financial systems.

Source: SAFR white paper, July 2026. Aureon Runtime implements the same four-component pattern, delivered as a shipping product.

How Aureon implements SAFR

Aureon Runtime is SAFR as a shipping product.

You don't have to build SAFR internally. Aureon Runtime maps to it, component-by-component — with the deterministic controls, the Governance Envelope, the four dispositions, and the tamper-evident audit log as the product.

SAFR Component Aureon Module What it does in Aureon
Agent IdentityAureon CoreCryptographic workload identity, short-lived, tied to registered version and environment.
Controls RepositoryAureon PolicyConverts regulation, policy and risk appetite into testable, enforceable controls. Signed control bundles.
Disposition EngineAureon RuntimeDeterministic disposition against retrieved controls. Human-approval pause. Kill switch, tool revocation, graduated intervention.
Audit LogAureon RuntimeTamper-evident, append-only, per-action. OpenTelemetry-compatible traces with redaction policy.
Governance EnvelopeNative + Gateway SDKBoth integration patterns supported. SDK for Python, TypeScript, Java, .NET. Zero-code option for legacy agents.
See Aureon Runtime →
Related frameworks

SAFR sits alongside other governance efforts.

SAFR does not exist in a vacuum. It complements — and is informed by — a growing set of AI governance frameworks in financial services.

MAS Project MindForge

AI Risk Management Handbook covering traditional AI, generative AI and agentic architectures. Practical implementation guidance — kill switches, least-privilege, agent certification.

MAS BuildFin.ai

Ongoing MAS workstream developing implementation resources for agentic AI risks. Complements SAFR.

IMDA MGF for Agentic AI

Model AI Governance Framework — four core components (models, memory, tools, actions) with governance across use-case bounding, access limitation, human oversight, principal hierarchy.

NIST AI Risk Management Framework

Four-part core (Map, Measure, Manage, Govern) for continuous risk evaluation across the AI lifecycle.

RBI MRM 2026 (AI/ML Chapter)

Explicit requirements for kill switches, human-in-the-loop, explainability thresholds, red-teaming, automation-bias monitoring for AI in Indian financial institutions.

Agent Payments Protocol (AP2)

Three-layer model for agentic payments — intent, control and authorisation, settlement. Cryptographically-signed mandates for verifiable machine-to-machine transactions.

Explore Resources →
Free · No commitment

Try Aureon on your own portfolio.

Two ways to start. No sales-cycle overhead. On your premises or in your VPC.

No commitment On-premises or your VPC Results in days, not months