SAFR Assumes You Have Treblle

In July 2026, the Monetary Authority of Singapore's BuildFin.ai program published a 22-page white paper on how to govern AI agents written with eight industry members including HSBC, J.P. Morgan Chase, Mastercard, and Visa.

The white paper explains how agentic finance works: how agents initiate payments, submit trading orders, approve credit, and file regulatory reports, in production, without a human reviewing each action. It's a careful, detailed specification: four runtime components, a Governance Envelope, capability-based mandates, and four possible outcomes for every proposed action. It never once uses the word "API."

That's not a gap in the paper. SAFR (Safeguards for Agentic Finance at Runtime) is explicit that it's a specification, not a product, and institutions are expected to implement its logic within whatever infrastructure they already run.

But every mechanism it specifies runs on data that only exists if something is already capturing it: which agent called what, what the request actually contained, whether that pattern matches what's normal, and what happened as a result. SAFR describes the checkpoint. It assumes the substrate underneath the checkpoint is already built.

A white paper about governing AI agents that never says "API"

Read SAFR closely and the omission is almost strange. The paper names five application areas: payments, liquidity management, compliance triage, credit assessment, and post-transaction processing. In all of them, an agent's "action" is, mechanically, an API call.

The Governance Envelope's Action Trace is defined as "the tool calls made, data retrieved, and checks performed." That's a description of API traffic. The paper's own diagram of where SAFR sits in the stack shows an AI agent proposing an action, SAFR evaluating it, and financial rails executing it if approved. Every arrow in that diagram is an API call in production. The paper simply doesn't say so.

This matters because SAFR's requirements read very differently once you translate them into what they cost to build.

"Verify agent identity against a registry before any other evaluation proceeds" sounds like an access control problem. In practice it requires knowing, for every single request hitting an endpoint, which consumer sent it, distinguished from every other consumer hitting that same endpoint. "Capture the action trace for audit" sounds like a logging requirement. In practice it requires full request and response payload capture, not metadata, on every call, with nothing sampled out. These aren't policy decisions an institution can write into a document. They're API-layer engineering problems, and the paper doesn't tell you how to solve them because solving them isn't SAFR's job.

What SAFR's four components actually require underneath them

SAFR describes a runtime checkpoint for agentic financial actions: four components (Agent Identity, Controls Repository, Disposition Engine, Audit Log) that evaluate every proposed action and resolve it to Deny, Escalate, Auto-Execute, or Observe. Every one of those components depends on API-level visibility that has to exist before SAFR can run, and the paper is explicit that building that visibility is left to the institution.

Take Agent Identity. SAFR requires resolving "which registered agent identity corresponds to the claimed agent" for every proposed action, and doing it before anything else in the pipeline runs. That resolution is only as good as the institution's ability to fingerprint and distinguish callers at the traffic level in the first place. If two agents, or an agent and a human developer testing against the same endpoint, look identical in the logs, no registry lookup fixes that.

Take the Controls Repository. SAFR splits controls into generic (authorization checks, exposure limits, deterministic) and AI-specific (evidence quality, envelope integrity, often probabilistic). Both categories assume the institution can already check a proposed action against a rule at the moment it happens, not after a batch job runs overnight. That's the same design-time versus runtime split covered in what API governance means in practice rules evaluated against live traffic, not rules written into a policy PDF.

Take the Disposition Engine's five calibration factors: reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty or anomaly. Novelty and anomaly, in particular, only mean something if there's a baseline of normal behavior to depart from. An institution that doesn't already track endpoint-level usage patterns, request volume, and behavioral consistency has no anomaly to detect. It just has traffic.

And take the Audit Log, which SAFR requires to be tamper-evident, append-only, and to capture "the governance envelope as submitted, the mandate against which the action was checked, the outcome produced, the specific rules applied, the basis for that outcome, and the time elapsed at each stage." That's not a schema an institution writes once. It's a data pipeline that has to run correctly on every single request, indefinitely, without gaps.

The three gaps SAFR names are all the same gap

SAFR's own background section names three problems with existing governance infrastructure:

• no pre-execution assurance (model risk management checks before deployment, audit checks after the fact, nobody checks at the moment of action),
• no human-agent governance interface (escalation today is "a notification, an email alert, or a dashboard flag," in the paper's own words, with no deadline and no audit record),
• and fragmentation (every institution has built its own guardrails independently, none of them interoperable).

Read those three gaps again and they collapse into one gap. Pre-execution assurance requires seeing the action before it lands, which requires real-time, unsampled request visibility. A structured human-agent interface requires a consistent evidence format for every escalation, which requires the same request-level data organized the same way every time.

Fragmentation exists because every team built its own instrumentation for its own deployment, which happens precisely when there's no shared, unified layer capturing traffic across every gateway, cloud, and framework in the first place. SAFR names three governance problems. Underneath all three is a data problem, and it's the same data problem three times.

What already produces a Governance Envelope's Action and Action Trace

This is the part of SAFR that maps most directly onto something that already exists, rather than something an institution has to invent. Treblle captures over 50 data points on every single API request in real time, with no sampling and no aggregation, including full request and response payloads rather than just metadata. That's a description of an envelope's Action field (type, scope, parameters) and Action Trace field (the tool calls, data retrieved, and checks performed) for every request an agent makes, before anyone builds a SAFR validator on top of it.

SAFR's own paper flags a problem with the envelope: an agent-declared trace can be fabricated by a sophisticated adversarial injection that stays internally consistent. That problem gets easier to catch with an independent record of what actually happened at the API layer, not just what the agent reported happened. An envelope authenticated against a separate traffic record is a stronger envelope than one authenticated only against itself.

The dependency runs deeper than a single request, too. Agent Identity and the Controls Repository can only govern APIs the institution knows exist. Treblle's discovery layer scans code repositories, gateways, and live traffic into a single API identity.

It also flags endpoints that are live and accessible but receiving no legitimate traffic, the same "zombie endpoint" pattern that showed up on 17% of tracked endpoints across Treblle's production dataset. An agent operating on inferred intent has no instinct that tells it to avoid a forgotten endpoint. A registry can't check identity against an API nobody registered.

What already produces SAFR's Audit Log

SAFR's Audit Log has to be "the authoritative record, independent of any party with an interest in how events are characterised after the fact." That independence requirement rules out logs the agent itself produces or curates. It has to come from somewhere that observes the request regardless of what the agent says about it.

Treblle's compliance layer already ties every evaluation to a specific request with full traceability. It checks traffic in real time against GDPR, PCI-DSS, HIPAA, and CCPA requirements rather than through scheduled audits, and retains that data indefinitely rather than on a log-rotation schedule tied to infrastructure costs.

That's most of an Audit Log's required fields already produced as a byproduct of normal operation: what happened, checked against what rule, with what outcome, timestamped, and kept.

None of this is coincidence. It's the same underlying problem SAFR is solving for at the decision layer, applied one layer down, at the traffic layer. An institution that already has this data isn't starting a SAFR implementation from an empty audit log. It's starting from a full one.

What Treblle doesn't do, and why that's the honest answer

Treblle doesn't issue agent identities. It doesn't hold a registry of which cryptographic credential belongs to which agent, and it doesn't create the mandates a user signs to delegate authority, the way the paper describes for the Agent Payments Protocol. Treblle doesn't run a Disposition Engine either. It doesn't take a proposed $50,000 wire transfer and resolve it to Deny, Escalate, Auto-Execute, or Observe in real time against a bank's specific risk thresholds.

That decision layer, the part of SAFR that actually blocks or approves an individual financial action, is a distinct piece of infrastructure that has to sit on top of whatever traffic visibility already exists.

What Treblle does is remove the excuse for not having the layer underneath that decision engine already built.

An institution evaluating SAFR adoption has two separate problems stacked on top of each other: building the runtime data plane (visibility, governance scoring, security detection, compliance checks, a complete API inventory) and building or buying the policy layer that reads that data and issues a disposition.

Conflating the two is how a SAFR pilot turns into an eighteen-month infrastructure project instead of a checkpoint bolted onto systems that were already producing the evidence it needs.

AI-related APIs grew 807% year over year against a 10% average across every other API category. And 47% of APIs process requests with no authentication at all while only 6% of recorded errors are 401 Unauthorized, meaning most systems aren't rejecting unauthenticated callers because they aren't checking for them.

Those aren't abstract statistics for a paper like SAFR. They describe exactly the baseline condition SAFR's Agent Identity and Controls Repository components assume doesn't exist.

For governance controls built specifically for agent traffic, the same gap shows up from the other direction: agents already calling production APIs that were never governed for non-human callers in the first place. The broader question of what an AI gateway does and when an institution needs one runs into the same dependency: a gateway can enforce policy at the traffic layer only if something is already producing the traffic-level data to enforce policy against.