SAFR for AML: Governing Compliance-Triage AI Agents at Runtime

Why AML triage is on SAFR's heightened-concern list¶

An AML triage agent performs three kinds of work: it enriches an alert with customer, account, and transaction data; it proposes a risk disposition (close as non-suspicious, or escalate for investigation); and it drafts a suspicious activity or suspicious transaction report (SAR/STR) where one is warranted. Each is an action with regulatory consequence: closing an alert ends scrutiny of that activity, and a filed SAR is a regulatory submission. At triage volumes there is no per-action human review.

SAFR identifies three gaps in the governance infrastructure most institutions run today, and AML triage sits squarely in all three. Model risk management validated the triage model before deployment; quality-assurance sampling reviews decisions after the fact; neither catches a problematic disposition before it executes. Escalation, where it exists, is ad hoc — a dashboard flag or an email alert 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." The third gap is fragmentation: each deployment carries its own bespoke guardrails, with no consistent audit format across them.

SAFR's answer is a runtime governance layer between the agent and the systems it acts on, evaluating each proposed action before execution: "no agentic action reaches execution without having been declared, authorised, and assessed." For the broader control pattern across financial-crime agents, see governing AML and payments agents and the AML agent control and evidence map.

The workflow, action by action¶

Under SAFR, each of the triage agent's proposed actions — an enrichment lookup, an alert closure, a SAR draft — is packaged in a Governance Envelope before it can execute. The envelope carries three classes of information: the action itself (type, scope, parameters), the action trace (the actual steps the agent 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, operative policy constraints).

The multi-step rule matters for triage in particular. SAFR applies its control flow to each agent action independently: "An Auto-Execute or Observe outcome at one step carries no authority into the next." Permission to enrich an alert confers no permission to close it. Every proposed action is authorized on its own facts, against current account state and the mandate, at the moment it is proposed.

What the triage agent's mandate looks like¶

SAFR defines a mandate as "the mechanism through which a user defines the bounds of the authority delegated to an agent" — explicit and machine-readable, drawing on capability-based security, the lineage that underlies OAuth 2.0.

For an AML triage agent, an institution's mandate would typically encode:

The boundary is structural: "An agent cannot extend the scope of a mandate through its own reasoning or inference." A triage agent that concludes, from its own analysis, that it should also close a related alert on an adjacent queue has proposed an out-of-mandate action, and the runtime layer will treat it as one.

• Permitted action types. Retrieve customer, account, and transaction data from named source systems; propose dispositions on designated alert queues; draft SAR/STR narratives. Filing is a separate action type, covered below.
• Scope limits. The alert queues, customer segments, and risk bands the agent may work; alert classes carved out entirely (for example, alerts linked to sanctions screening hits or to open investigations).
• Conditions and validity. The period the delegation is valid for, and the principal who granted it — typically the head of transaction monitoring or the financial intelligence unit, mirroring the institution's existing delegated-authority framework.

Which controls apply¶

The Controls Repository is the institution's configurable rulebook, drawn from organizational policy, regulatory requirements, product rules, and the mandates users have granted. SAFR's four control categories map cleanly onto AML triage:

Generic controls (authorization checks, exposure limits) are deterministic; AI-specific controls such as evidence quality and envelope integrity may involve probabilistic or semantic assessment. Each control encodes permitted action types, decision logic, escalation conditions, a validity period, and the principal authority behind it.

The four SAFR dispositions on real alert classes¶

The Disposition Engine evaluates every in-scope action deterministically against the retrieved controls and returns one of four binding outcomes. On an AML queue, they look like this:

Outcome assignment is calibrated at design time against five factors the paper names: action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty relative to established patterns within the mandate. A closed alert is hard to reverse in practice, and every disposition on the queue carries regulatory sensitivity, so a well-calibrated configuration shifts borderline cases toward Escalate and reserves Auto-Execute for alert classes where the evidence contract is explicit and consistently met.

Observe is the workhorse on high-volume queues: low-risk alert classes auto-close at machine speed while a defined sample of closures flows to human spot check, keeping sustained assurance over the population the institution has chosen to automate.

Maker-checker for the SAR filing¶

Drafting a SAR and filing one are different actions. Drafting can run autonomously: the agent assembles the narrative, supporting transactions, and customer context, and the draft is recorded like any other governed action. Filing is a regulatory submission and is calibrated to Escalate.

An Escalate outcome under SAFR is a structured obligation with three operational dimensions the paper is specific about:

This is maker-checker with substance: the agent as maker, a named and authorized human as checker, a deadline, a defined default, and a recorded decision.

• Reviewer authority. The reviewer must have clear authority to approve, modify, or decline, and reviewer decisions "carry the same institutional weight as the original agent decision." For a SAR, that reviewer is the person whose name the institution is prepared to stand behind on a filing.
• Review turnaround. Each escalation should carry a timeout window; if no decision arrives within it, the action defaults to block or escalates to a senior reviewer. The window should reflect realistic reviewer availability, including overnight and weekend coverage.
• Escalation volume. An escalation function that generates more reviews than the team can meaningfully process has stopped providing assurance. Calibration should hold the Escalate queue to the dispositions that genuinely need a human decision, and let Observe sampling cover the rest.

What the inspector sees¶

Every one of the four outcomes — including Deny — feeds the Audit Log, an immutable, append-only, tamper-evident record of every governance decision. For each proposed action on the AML queue, the entry captures the Governance Envelope as submitted, the mandate the action was checked against, the outcome the Disposition Engine produced, the specific rules applied, the basis for the outcome, and the time elapsed at each stage.

For an auto-closed alert, that means the record already contains what the agent retrieved (the action trace: tool calls, data, checks), which controls fired, and why the closure qualified for Auto-Execute. For a filed SAR, it contains the draft, the escalation, the named reviewer, and the decision. For a denied action, it contains the attempt and the specific constraint that stopped it — evidence the control layer works, produced by the control layer itself.

SAFR is careful about a failure mode that matters in adversarial settings: the action trace and the action details are both agent-declared, and a sophisticated adversarial injection could fabricate them together. The envelope is therefore "treated as a document to be authenticated against its origin, not merely as a record of what the agent reported." The paper's standard for the log itself: "The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact." That is the standard an AML inspector will hold the record to.

Running this on KLA Control Plane¶

KLA Control Plane implements the SAFR pattern, shipping today, and financial-crime triage is one of the workloads it has been demonstrated on end to end. The four SAFR components map directly: the Agent Registry holds each triage agent as a registered, versioned entity with a named human owner; the Policy Builder is the controls repository, with publishing gated by lint checks and two-person approval; the KLA Policy Engine evaluates every proposed action against the published policy version before execution and fails closed if unreachable; and the Audit Trail is the append-only, tamper-evident record, exportable as Sealed Evidence Bundles an auditor can verify offline.

The disposition grammar is one-to-one. Deny maps to `block`. Escalate maps to `require_approval`, which raises a Decision Request routed to a named, authorized reviewer on the Decision Desk, with maker-checker separation enforced server-side. Auto-Execute maps to `allow`. Observe maps to `warn`, and a sampling review queue routes sampled runs to scheduled human spot check — the auto-close-with-sampling pattern described under the four dispositions above, running as shipped product.

Two status notes: per-action value thresholds and AI-judge evidence checks are shipped; aggregate exposure windows, per-window rate limits, confidence thresholds as a first-class routing primitive, and timeout defaults per decision class are in development. The SAFR implementation page carries the full requirement-by-requirement status table.