Safeguards for Agentic Finance at Runtime (SAFR) is a reference approach for a runtime governance layer for agentic AI in financial services, published in July 2026 by MAS's BuildFin.ai programme and written with Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa. Version 1.1, published on 9 October 2026, clarifies scope and implementation approach and adds DBS, Google, and UOB to the acknowledged contributors. SAFR is voluntary: version 1.1 states that it "does not constitute regulatory guidance or supervisory expectations, nor does it prescribe or anticipate future directions for such guidance or expectations," and MAS has made no commitment to make it mandatory. The supervisory baseline in Singapore is the final AI Risk Management Guidelines MAS issued on 7 October 2026. The white paper "defines data structures, evaluation logic, and escalation contracts for agentic AI deployment." It leaves the implementation to each institution: SAFR "serves as an industry reference for institutions to implement within their own infrastructure, using their own rule configurations and governance arrangements."
This guide covers the engineering decisions that implementation requires: the reference architecture, the choice between native and gateway deployment, what to encode in controls, disposition calibration, escalation operations, the evidence layer, a worked mandate and decision record, and a build-vs-buy analysis. For the framework itself (the four components, the Governance Envelope, mandates, and the ecosystem around SAFR) start with SAFR, explained. For the component-by-component KLA mapping, see the SAFR implementation page.
The SAFR reference architecture
SAFR "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." The design goal, in the paper's words: "no agentic action reaches execution without having been declared, authorised, and assessed." An implementation is a pipeline with a fixed order, and an audit log that records every stage of it.
The pipeline runs as follows. The agent proposes an action. Before anything executes, the proposal is packaged in a Governance Envelope carrying three classes of information: the action itself (type, scope, parameters), the action trace (the steps the agent actually executed in arriving at the proposal, including tool calls made, data retrieved, and checks performed), and context metadata (agent identity, applicable mandate, current account or system state, and operative policy constraints). The envelope is validated for completeness and coherence. Agent Identity then verifies the proposing agent against the authoritative registry; a failed verification means immediate rejection, recorded in the Audit Log. The Controls Repository identifies which of the institution's controls apply. The Disposition Engine evaluates the action against those controls and returns one of four binding outcomes: Deny, Escalate, Auto-Execute, or Observe. Financial rails execute if and only if the outcome permits, and the Audit Log records the full governance trace for every outcome, denials included.
Envelope integrity is a first-order design problem. The action trace and the action details are both agent-declared, and a sophisticated adversarial injection can fabricate them together. Version 1.1 is direct about it: "The governance envelope should not be treated as self-verifying." Where feasible, the agent-supplied fields should be checked against records captured independently of the agent, such as the initiating instruction, the actual action payload, and system-generated records of tool calls and data access, and the envelope should be bound to the verified agent, session, and mandate. In practice this pushes implementers toward capturing the envelope at a point the agent cannot forge (inside the execution path, or at the network boundary) and it is the strongest argument for choosing your deployment pattern deliberately.
| Component | Function | Implementation note |
|---|---|---|
| Agent Identity | Binds each proposed action to a recognized, registered agent, verified against that agent's registry entry before any other evaluation proceeds | In closed-loop environments, a direct lookup against the institution's own registry; on open networks the component must determine which of several registries (internal, payment-network, inter-institutional) is authoritative |
| Controls Repository | The institution's configurable rulebook, drawn from organizational policies, regulatory requirements, product rules, and user-provided mandates | Generic controls (authorization checks, exposure limits) are deterministic; AI-specific controls (evidence quality, envelope integrity) may involve probabilistic or semantic assessment |
| Disposition Engine | Evaluates each in-scope action deterministically against the retrieved controls | Produces "a defined, binding outcome for every proposed consequential action calibrated to the specific risk it presents" |
| Audit Log | An immutable, tamper-evident, append-only record of every governance decision | Records all four outcomes; see the evidence layer section below |
Native or gateway: choosing a deployment pattern
The white paper defines two integration patterns, and most institutions will end up running both. SAFR, explained covers the mechanics of each pattern, envelope emission in the agent and gateway interception at the infrastructure layer; the implementation decision is when to choose which.
Version 1.1 adds a point on topology: SAFR "does not require implementation as a single central platform within an institution." Its components may run as a central service, inside individual agent deployments, as shared institutional services, or as a hybrid, provided each in-scope action passes through the required SAFR functions before execution and every implementation follows common standards for envelopes, disposition outcomes, control semantics, and auditability.
The sequencing guidance comes straight from the paper: "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." Concretely: new capabilities get native instrumentation from day one, and the existing estate gets a gateway in front of it. Run both patterns against one controls repository, one disposition engine, and one audit log, so a mixed estate produces a single consistent governance record.
| Pattern | When to choose it |
|---|---|
| Native Integration | New agent deployments, where instrumenting the agent gives the tightest integration, the most granular record, and the cleanest audit trail |
| Gateway Integration | Legacy systems, third-party agents, and existing deployments, where coverage has to arrive without changes to agent code |
What to encode in SAFR controls
A control in SAFR encodes five things: permitted action types, decision logic, escalation conditions, a validity period, and the principal authority under which the agent acts. Controls draw on four sources: organizational policies, regulatory requirements, product rules, and user-provided mandates.
The mandate is the anchor. "A mandate is the mechanism through which delegated authority is scoped and expressed in machine-readable form": what the agent may do, within what limits, under what conditions. "An agent cannot extend the scope of a mandate through its own reasoning or inference." The design lineage is capability-based security, the model that underlies OAuth 2.0; the paper cites the Agent Payments Protocol (AP2), with its cryptographically signed mandates, as a prominent industry example.
The paper groups controls into four categories:
| Category | What to encode | What to test |
|---|---|---|
| Authorization | Agent-to-principal bindings, delegation depth, and an action-type allowlist per agent class, all resolvable at evaluation time | An action type outside the allowlist is denied even from a correctly registered agent; a delegation deeper than the encoded depth is denied |
| Exposure Limits | Per-action thresholds and aggregate windows sourced from your existing delegated authority framework, with the Auto-Execute, Escalate, and Deny bands stated as explicit amounts | An action that would breach an aggregate window's remaining headroom escalates even when its own amount sits inside the per-action band |
| Rate Limits | A maximum action rate per time window for each agent class, with a defined outcome for actions beyond the cap | A burst beyond the cap, whatever its cause (runaway agent, data feed error, adversarial injection), is denied and flagged for investigation |
| Evidence Quality | The required evidence for each action type and the minimum stated-confidence threshold for autonomous execution; the treasury calibration below requires a matched invoice record per payment | An action whose stated confidence falls below the threshold routes to human review whatever its value; test with a deliberately weak evidence match |
Calibrating controls for a treasury payments agent
Here is what that looks like calibrated for a treasury payments agent. The values are illustrative; set yours from your delegated authority framework.
For a compliance-triage agent (alert enrichment, risk disposition proposals, filing preparation) the controls that carry the load are evidence-quality thresholds: auto-closure of an alert requires the evidence contract to be met at or above threshold, proposed high-risk dispositions escalate to a named reviewer, and any action that would suppress an open alert is denied outright. We walk that Process end to end, through all four components, in SAFR for AML and compliance triage.
| Control | Illustrative setting |
|---|---|
| Authorization | Agent class treasury-payments may initiate vendor and intercompany payments for Treasury Operations as principal. Delegation depth 1: the agent may hold delegated authority and may sub-delegate to no other agent |
| Per-action exposure limit | Auto-Execute below US$25,000. Escalate from US$25,000 to US$250,000. Deny above US$250,000, the ceiling of the desk's delegated authority |
| Aggregate exposure window | US$500,000 per rolling 24 hours; a payment that would exceed the window's remaining headroom escalates |
| Rate limit | Maximum 20 payment initiations per hour; actions beyond the cap are denied and flagged for investigation |
| Evidence quality | Every payment must reference a matched invoice record; a match below the confidence threshold escalates to human review regardless of amount |
| Validity period | Mandate valid for the current quarter; actions proposed outside the validity period are denied |
Calibrating the four dispositions
Every in-scope action resolves to one of four outcomes from the Disposition Engine:
All four outcomes feed the Audit Log. Assignment is driven by five calibration factors the paper names: action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty or anomaly: departure from 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, which is why the pilot plan below budgets a full week for tuning against real traffic.
Observe deserves deliberate design attention: it lets a new control run against live traffic and generate structured review material while execution continues, the natural setting for thresholds you intend to tighten after seeing real behavior.
Calibrate against history. When we ran a bank onboarding exercise in our own test tenants in October 2026, with scripted personas for the bank administrator, the compliance officer, and the approver, our conclusion was that hand-built policy test cases with many fields are impractical: a compliance officer will not write unit tests for a policy. What works is replaying recent runs against the draft controls and showing the change against what happened, for example how many more actions would have gone to human review. That number is the reviewer-capacity question, and it belongs in front of the people who will staff the queue.
| Disposition | What to encode | What to test |
|---|---|---|
| Deny | Hard regulatory and policy constraints, and the risk thresholds above which an action is rejected outright; in the treasury calibration, amounts above US$250,000, the ceiling of the desk's delegated authority | A constraint-violating action never reaches the rails, and its Audit Log entry names the rule that fired and the specific reason |
| Escalate | The escalation conditions in each control, marking where the autonomous band ends below the Deny ceiling; US$25,000 to US$250,000 for the treasury agent | Simulated traffic yields an Escalate volume the review team can clear, and every escalation carries a timeout window defaulting to block or to a senior reviewer |
| Auto-Execute | The autonomous band each control leaves open: the action types, amounts, and conditions under which execution proceeds with no reviewer in the path | Sampled auto-executed actions each show a full governance trace: envelope, rules applied, basis, stage timings |
| Observe | Patterns and signals configured as warranting attention below the escalation threshold, each producing a structured observation while the action executes | Observations are retrievable and queryable when the threshold review comes due |
Escalation operations: design them before go-live
The paper describes today's typical escalation as a notification, an email alert, or a dashboard flag, no deadline, no standard decision format, no audit record: "the appearance of human oversight without the substance of it." A SAFR implementation replaces that with a designed operation, along three dimensions.
Volume. "An escalation function that generates more reviews than the institution can meaningfully process defeats its own purpose." Size thresholds against actual reviewer capacity; if simulation produces more Escalate outcomes than the team can clear, fix the controls before launch.
Turnaround. Every escalation should carry a timeout window. If no decision arrives within it, the default is to block the action or escalate to a senior reviewer. Set the window from realistic reviewer availability, including overnight and weekend coverage.
Authority. Reviewers need clear authority to approve, modify, or decline, and their decisions "carry the same institutional weight as the original agent decision." That implies named individual reviewers, recorded rationale on every decision, and role definitions that map onto your existing approval hierarchy.
Re-authorize every step
In multi-step Processes, the control flow applies to each agent action independently. "An Auto-Execute or Observe outcome at one step carries no authority into the next," because the agent adapts to intermediate results and changing conditions as it works.
This single sentence has large implementation consequences. The evaluation path must be fast enough to run on every action, so latency belongs in the engineering budget from the start. Mandates must be resolvable per action. Session-level approval caching is ruled out by design. And a ten-step workflow produces ten governance traces, each with its own envelope, disposition, and basis: exactly what an inspector reconstructing the run will want.
The evidence layer: the SAFR Audit Log
Each Audit Log entry captures six things: the governance envelope as submitted, the mandate against which the action was checked, the outcome produced by the Disposition Engine, the specific rules applied, the basis for that outcome, and the time elapsed at each stage. The log is immutable, tamper-evident, and append-only. The paper's standard: "The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact."
That standard sits above what ordinary application logging provides, and three properties need engineering from the outset: append-only writes, so records accumulate and never mutate; tamper evidence, in practice cryptographic chaining, so any alteration of a past record is detectable; and independent verifiability, meaning an auditor can confirm the integrity of an exported record without access to the platform that produced it. Persist the evidence before returning the disposition. If an action can execute while its record is still in flight, a crash can leave executed actions with no governance trace.
A worked mandate and decision record
The example below is synthetic. Northbridge Bank is fictional, and the names, amounts, and identifiers are illustrative. It uses the treasury calibration above and follows one mandate from delegation to evidence.
The mandate. Northbridge's Head of Treasury Operations delegates vendor and intercompany payments to a registered agent, treasury-payments, release 3.2. The mandate is the written boundary of that delegation. The institution writes it from its existing delegated authority framework, versions it, and approves it through the same review it uses for policy changes.
| Field | Value |
|---|---|
| Mandate | mnd-treasury-ops-2026q4, version 2, approved by the Head of Treasury Operations and Treasury Risk |
| Principal | Treasury Operations, Northbridge Bank |
| Agent | treasury-payments, release 3.2, registered in the agent registry with a named owner |
| Permitted action types | Vendor payment to an existing payee; intercompany transfer between listed group accounts |
| Per-action limits | Autonomous below US$25,000; human approval from US$25,000 to US$250,000; nothing above US$250,000 |
| Aggregate window | US$500,000 per rolling 24 hours; any action that would breach the remaining headroom needs approval |
| Evidence required | A matched invoice or intercompany agreement reference, with match confidence of at least 0.90 for autonomous execution |
| Signals that warrant review | First payment to a payee in 90 days; payee bank details changed in the last 30 days |
| Outside the mandate | Creating payees, changing payee bank details, sub-delegating to another agent, paying from accounts not listed |
| Validity | 1 October to 31 December 2026 |
The delegation boundary and the four outcomes
The last two rows of the mandate draw the delegation boundary. Anything outside it is denied whatever reasoning the agent offers, because "an agent cannot extend the scope of a mandate through its own reasoning or inference." Inside the boundary, the controls sort each proposed action into one of the four SAFR dispositions. KLA Control Plane expresses the same four outcomes as allow, warn, require_approval, and block.
Four actions the agent proposed on one morning show each outcome. Every row was evaluated on its own, with no authority carried over from the row before.
| Proposed action | What the controls found | SAFR disposition | KLA outcome |
|---|---|---|---|
| Pay US$8,400 to an office-supplies vendor | Existing payee, invoice matched at 0.97, within per-action and aggregate limits | Auto-Execute | allow: executes; decision recorded |
| Pay US$19,600 to a logistics vendor | Within limits and matched at 0.94, but the first payment to this payee in 112 days | Observe | warn: executes; observation queued for the weekly treasury review |
| Pay US$118,000 to a software vendor | Invoice matched at 0.96; amount inside the approval band | Escalate | require_approval: held for a named reviewer as a Decision Request in Decision Desk |
| Pay US$310,000 to a construction contractor | Above the US$250,000 ceiling of the delegated authority | Deny | block: rejected before reaching the payment rail; reason recorded |
One approval case, end to end
09:41. The agent proposes the US$118,000 payment. The envelope carries the payment instruction, the action trace (invoice lookup, contract lookup, payee check), and the context: agent identity, mandate version 2, and the 24-hour total so far of US$212,000. Identity verification passes. The per-action control returns Escalate; the aggregate control passes with US$170,000 of headroom remaining after this payment.
09:41. The action is held. A review request goes to the treasury approver group with the proposed action, the invoice, and the controls that fired. Northbridge sets a four-hour timeout on this escalation class, with block as the default.
10:17. A treasury manager opens the request, compares the invoice with the purchase order and the master services agreement, and approves with the rationale "Annual licence renewal; PO 4471 and MSA clause 6.2 match invoice INV-20931." The approval applies to this payment only.
10:17. The payment is released to the rail, which returns a payment reference. The record closes with the execution result.
Two design choices in this case come from a held-payment release Process we built in our own demo tenant for an analyst briefing in October 2026, with synthetic payments. First, each human decision has exactly one approval gate. Our first submission of that Process for review was rejected because two human steps also carried a separate approval flag, which would have created two approval tasks for one decision; we removed the flags and kept one gate per decision. Second, the policy routes any case no rule anticipated to require approval. In our earliest AML test policy the no-match default was block, so unforeseen cases stopped without ever reaching a reviewer.
Had the manager not responded by 13:41, the request would have expired and the action would have been blocked, with the expiry recorded. Had the manager declined, the agent would have received a block with the reviewer's reason, and a fresh proposal for the same payment would be evaluated from the start.
The evidence the case leaves
SAFR lists the elements each audit entry should capture: the envelope as submitted, the mandate the action was checked against, the outcome, the specific rules applied, the basis for the outcome, and the time elapsed at each stage. The approval case adds the human decision and the execution result. The table shows the record for the US$118,000 payment.
Approval and settlement are separate records. In the held-payment showcase, the release approval and the confirmed settlement status are two distinct entries, and a payment is complete only when the settlement reference is recorded. We keep them apart because an approval proves a decision and only the rail can confirm the money moved.
Three limits belong in any honest reading of this record. It shows what the agent proposed, which rules applied, who decided, and what the rail returned. It does not show that the vendor received the funds; that comes from settlement and reconciliation records. It also does not prove the invoice is genuine; the evidence-quality control checks the match, and fraud controls sit elsewhere in the payment process. An auditor should be able to read these limits from the record without asking.
| Record field | Value |
|---|---|
| Decision | dec-2026-10-12-000418 |
| Proposed action | Vendor payment, US$118,000, payee ven-0193, invoice INV-20931 |
| Agent | treasury-payments, release 3.2; identity verified 09:41:07 |
| Mandate | mnd-treasury-ops-2026q4, version 2 |
| Rules applied | Per-action exposure band (Escalate); aggregate window (pass, US$170,000 headroom after action); evidence quality (pass, 0.96); payee status (existing) |
| Outcome and basis | Escalate (require_approval): amount within US$25,000–US$250,000 approval band |
| Human decision | Approved by a named treasury manager at 10:17:52 with recorded rationale |
| Execution result | Released at 10:17:55; rail payment reference recorded |
| Stage timings | Identity 18 ms; controls 41 ms; awaiting human decision 36 min; release 3 s |
| Integrity | Appended to the tamper-evident log; exportable with the rest of the day's records for independent verification |
Build vs buy for the SAFR runtime layer
SAFR is a reference approach, and the software choice is left open. Disclosure before the analysis: KLA is a vendor in this category. KLA Control Plane implements the SAFR pattern, shipping today. Read what follows with that in mind.
Building in-house means standing up six subsystems:
The six subsystems together are a platform-scale build, and the realistic planning unit is team-quarters. The work also continues after launch: calibration is an operating activity, because thresholds move with transaction volumes, product changes, and reviewer capacity.
Building makes sense when you have a deep in-house platform team that will own the layer as a product, when your rails or settlement infrastructure are bespoke enough that an off-the-shelf checkpoint cannot sit in front of them, or when adjacent systems you already operate (entitlements, case management, policy tooling) cover real parts of the table above.
Buying makes sense when the priority is governed coverage and exportable evidence within a quarter, when there is no platform team available to own six subsystems, or when auditors will ask for independently verifiable records sooner than an in-house roadmap can deliver them.
The hybrid is often the honest answer: buy the runtime checkpoint (registry, disposition engine, escalation Process, evidence store) and keep controls authoring in-house. The split matches SAFR itself: the framework standardizes the data structures and contracts, while rule configurations and governance arrangements remain the institution's. Under a hybrid, your risk and compliance teams own what the controls say, and the vendor operates the machinery that enforces and evidences them.
For the record on KLA specifically: KLA Control Plane maps component for component (Agent Registry, Policy Builder, KLA Policy Engine, Audit Trail) with the four dispositions expressed as allow, warn, require_approval, and block. Per-action authorization, fail-closed evaluation, and Sealed Evidence Bundles with offline verification are shipped. Aggregate exposure windows, per-window rate limits, confidence thresholds as a routing primitive, per-class escalation timeout defaults, and the standalone gateway are in development. The component-by-component map, with status flags on every requirement, is on our SAFR implementation page.
| Subsystem | What it takes |
|---|---|
| Agent registry | Registered, versioned agent identities with named owners; resolution of the authoritative registry; verification on every proposed action |
| Controls repository | Machine-readable, versioned policies; a governed publishing workflow with review and approval before a policy takes effect; coverage for regulatory, product, and mandate-derived rules |
| Disposition engine | Deterministic evaluation producing the four outcomes with machine-readable reason codes; fail-closed semantics when the decision service is unreachable |
| Escalation Process | Routing to named reviewers with full action context; approve, modify, or decline with recorded rationale; timeout handling; queue and turnaround visibility |
| Evidence store | Append-only, tamper-evident storage; export tooling; a verification path an external party can run independently |
| Instrumentation | Envelope emission in every agent for native integration, or an intercepting gateway for the existing estate, plus the latency work to keep per-action evaluation viable |
A four-week SAFR pilot
A credible first implementation fits in four weeks on one scoped Process, and the plan works whether the layer underneath is built, bought, or hybrid.
Before week one, score where you stand. The SAFR Readiness Checklist is an interactive gap assessment across eight sections, from agent identity through deployment pattern, with the evidence an assessor would ask for attached to every question.
| Week | Work |
|---|---|
| 1 | Scope one agent workflow. Register the agent, define its mandate, and author the controls: authorization scope, exposure limits, rate limits, evidence-quality thresholds, escalation conditions |
| 2 | Run governed traffic in simulation. Evaluate replayed or historical actions against the controls and calibrate dispositions until escalation volume matches reviewer capacity |
| 3 | Go live with escalations. Route real Escalate outcomes to named reviewers, measure turnaround against the timeout window, and tune thresholds on real behavior |
| 4 | Export the evidence. Produce the audit records for the pilot period, run independent verification on the export, and hold a go/no-go readout with risk and compliance |
Frequently Asked Questions
How do we retrofit an existing agent estate?
Put a gateway in front of it and give new builds native instrumentation from day one, the sequencing the white paper recommends. The engineering work concentrates in two places: the interception point, which should sit where the agent cannot forge the envelope, at the network boundary or inside the execution path; and the latency budget, because evaluation runs on every proposed action. Run the gateway against the same controls repository, disposition engine, and audit log as the native builds so the mixed estate produces one consistent governance record.
What does native integration require from our agent code?
The agent is instrumented to emit a Governance Envelope before each proposed action: the action type, scope, and parameters; the action trace; and context metadata. A validator evaluates the envelope against the controls repository and returns an outcome before the agent acts. The paper recommends native integration for new agent deployments; it gives the tightest integration, the most granular record, and the cleanest audit trail.
What does a SAFR pilot look like?
Four weeks on one scoped workflow: register the agent and author its controls; calibrate dispositions against simulated or replayed traffic; run live escalations with named reviewers and tune thresholds; then export the audit records, verify them independently, and hold a go/no-go readout with risk and compliance.
Does SAFR require specific technology or a specific vendor?
No. SAFR defines data structures, evaluation logic, and escalation contracts, and it "serves as an industry reference for institutions to implement within their own infrastructure, using their own rule configurations and governance arrangements." SAFR is not a managed service. Institutions can meet it by building, buying, or combining the two.
Is SAFR mandatory for MAS-regulated institutions?
No. SAFR version 1.1 (9 October 2026) states that it does not constitute regulatory guidance or supervisory expectations and does not anticipate future directions for them, and MAS has made no commitment to make it mandatory. The supervisory expectations for AI, including agents, are in the MAS Guidelines on Artificial Intelligence Risk Management issued on 7 October 2026, which take effect on 7 October 2027.
What should a SAFR decision record contain?
At minimum the elements SAFR lists for each audit entry: the Governance Envelope as submitted, the mandate the action was checked against, the outcome, the specific rules applied, the basis for the outcome, and the time elapsed at each stage. For an escalated action, add the reviewer, the decision, the recorded rationale, and the execution result, and state what the record does not prove, such as settlement.
Who sets the thresholds in a SAFR implementation?
The institution does. SAFR "does not constitute regulatory guidance or supervisory expectations," and rule configurations and governance arrangements stay with the implementer. In practice: exposure limits come from your existing delegated authority framework, escalation thresholds are sized against actual reviewer capacity, and disposition calibration is set at design time using the five factors the paper names, from action reversibility through novelty. Each institution remains responsible for determining how its deployment aligns with applicable supervisory expectations and internal governance requirements.
Key Takeaways
The implementation order that works: choose your deployment pattern (native for new builds, gateway across the existing estate), encode controls from your existing delegated authority framework, calibrate the four dispositions in simulation, design escalation operations against real reviewer capacity, and stand up an evidence layer an outsider can verify. Then prove it on one Process in four weeks, with a decision record like the worked example above for every consequential action.
Start by scoring your current state with the SAFR Readiness Checklist: an ungated, interactive gap assessment; the editable working sheet is available by email. If you want a second pair of eyes on the gap list, book a 30-minute SAFR gap review. And for the component-by-component view of implementing the SAFR framework on KLA Control Plane, including what is shipped and what is in development, see the pillar page.
Sources: Safeguards for Agentic Finance at Runtime, white paper v1.0 (3 July 2026) and v1.1 (9 October 2026), MAS BuildFin.ai; MAS, Guidelines on Artificial Intelligence Risk Management, 7 October 2026. Quoted passages © Monetary Authority of Singapore. SAFR is a voluntary industry reference and does not constitute regulatory guidance. The Northbridge Bank example is synthetic. KLA is independent of and not affiliated with, endorsed by, or certified by MAS or BuildFin.ai.