Govern an AML alert-triage agent one case at a time: bind the alert and current evidence to a named agent Release, evaluate every consequential action before execution, route material decisions to an eligible financial-crime reviewer, and attach the downstream case effect to a sealed audit record. The customer builds, operates, and remains accountable for the alert-triage agent. The KLA Control Plane supplies an independent runtime governance path for instrumented actions.
This implementation guide covers a single operational workflow from transaction-monitoring alert intake through evidence export. The AML Agent Control & Evidence Map remains the six-action reference hub. Governing AML and payments agents covers regulatory classification and regime timing. The human-reviewed AML alert-triage blueprint provides the broader control mapping. This guide is general information, current to 28 July 2026, and does not replace legal, risk, or technical advice.
Trigger and case intake
A transaction-monitoring system starts the run by creating one alert with a stable alert identifier, detection time, typology, triggering transactions, customer reference, and source-system version. The intake adapter creates or resolves one case in the organisation’s case system of record. One correlation ID binds every evaluated attempt to that alert and snapshot. A retry of an attempt reuses its execution ID and idempotency key so it cannot create a second effect.
Each attempted action gets its own execution ID. The run ends after one final disposition effect. Later source changes require a new snapshot and run. The L1 analyst owns the queue and can inspect the intake packet. The agent performs bounded enrichment and proposes the next action. A named reviewer owns any held decision.
| Input | Required binding | Failure behavior | Evidence |
|---|---|---|---|
| Transaction-monitoring alert | alert ID, rule or typology, detection time, triggering transaction IDs, source version | Missing identity, detection time, or transaction references returns block with AML_INTAKE_INCOMPLETE. | Source receipt and digest |
| Case context | case ID, customer token, linked open cases, current disposition, assigned analyst | Case lookup failure holds the run and returns block with AML_CASE_CONTEXT_UNAVAILABLE. | Snapshot time, query receipt, returned references |
| Run identity | correlation ID, per-attempt execution ID, agent Release, requester, accountable owner | A duplicate attempt reuses its execution ID and idempotency key; conflicting identifiers block. | Envelope and actor fields |
Data sources and permitted data use
Define one restricted AML Data Boundary for the run. Permitted reads can include the triggering transactions, customer KYC/CDD profile, expected activity, risk rating, sanctions and PEP screening results, related alerts and cases, prior internal case dispositions, counterparty links, and dated source references. Purpose-bind every read to AML alert triage and return the smallest field set needed for the case.
Exclude customer messaging, relationship-manager notes, general CRM write surfaces, unrelated household records, raw identity documents when verified attributes suffice, and unrestricted model-training or analytics exports. Regulation (EU) 2024/1624 Article 73 covers EU obliged entities and bars disclosure to the customer or other third persons that activity is being assessed, information is being or will be sent to an FIU, or an ML/TF analysis is underway. The US bank rule in 31 CFR § 1020.320(e) and 31 U.S.C. § 5318(g)(2)(A)(i) protects a SAR and information revealing its existence. Tool destinations and log sinks belong inside the same confidentiality boundary.
- Purpose: AML alert triage for the bound case.
- Fields: approved attributes and source references listed in the Data Boundary.
- Freshness: source timestamp and permitted maximum age travel with every fact.
- Region and recipient: organisation-approved processing region and restricted case roles.
- Output handling: tokenise publication samples; redact exports according to policy; preserve omission records.
Agent identity, tool access, and entitlements
Register a dedicated agent identity such as aml-alert-triage-agent. Bind the executing workload identity, accountable financial-crime owner, active Release, and permitted Tool Catalog entries. A Release is the immutable versioned snapshot of the agent configuration, model and instruction references, parameters, and tool bindings used for the run.
Resolve least privilege across agent, tool, resource, data, action, purpose, amount, environment, and time. Reads stay case-scoped. Draft permissions create internal artifacts. Write permissions reach only governed case-system operations. A Release with no FIU filing tool, customer-message tool, CRM-note tool, or general database writer gives prohibited actions an enforceable absence of authority.
| Tool Catalog entry | Scope | Entitlement boundary | Confirmation |
|---|---|---|---|
tm.alert.read | Read | One bound alert and triggering transaction references inside the AML Data Boundary | Source receipt and alert version |
aml.case_context.read | Read | One bound case, linked-case status, approved KYC/CDD, risk, PEP, sanctions, and history fields | Freshness and completeness result |
aml.case_packet.draft | Draft | Internal reviewer packet and SAR/STR narrative draft inside the restricted boundary | Artifact digest and confidentiality class |
aml.case.escalate | Write | Named case-system route to L2/L3 only | Policy result and downstream receipt |
aml.case.write_disposition | Write | Disposition enum and paired rationale on the bound case only | Policy or valid approval, idempotency key, before/after digest |
Alert enrichment, summarization, risk indicators, and recommendation
The informational phase reads approved sources, normalises transaction activity, calculates dated aggregates, identifies typologies, checks PEP and sanctions indicators, resolves linked cases, records missing or conflicting facts, and drafts a factual summary. It then recommends auto-close, escalation, or SAR/STR narrative preparation with confidence and source references.
Enrichment and summarisation create no case disposition, customer effect, filing, or external communication. Treat the result as a proposal. The policy checkpoint begins when the agent asks to auto-close, escalate, draft a regulated narrative, or write to the case system of record.
- List each risk indicator with its source, observed value, timestamp, and interpretation.
- Keep the recommendation and rationale paired so a consistency test can evaluate both.
- Expose uncertainty, missing fields, stale sources, and conflicts to policy and the reviewer.
- Record the initial-detection time needed for jurisdiction-specific reporting clocks.
Permitted and prohibited action table
The table defines the complete action inventory for this workflow. Permitted means eligible for policy evaluation inside a stated authorization boundary. A permitted action can still warn, require approval, or block for the facts of one case. Prohibited actions terminate before any side effect.
| Action | Class | Authorization boundary | Required confirmation | Enforced outcome |
|---|---|---|---|---|
| Auto-close or dismiss an alert | Permitted | close_alert binding for the bound alert, restricted AML Data Boundary, active Release, no linked open case | Current case check, complete sources, explicit confidence/risk/amount/sanctions/novelty/data-quality result | Execute only on allow, warn, or valid required approval; retain the close receipt and case effect. |
| Escalate to L2/L3 | Permitted | aml.case.escalate binding for the bound case and named investigator queue | Target queue, reason codes, evidence references, current case version | Execute after policy release; record assignment and downstream case status. |
| Draft a SAR/STR narrative | Permitted | aml.case_packet.draft binding with draft-only scope inside the restricted boundary | Named SAR-filing-officer route, source references, confidentiality class | Create an internal draft under require_approval; the human filing decision follows the organisation’s separate filing control. |
| Write disposition and rationale to the case system of record | Permitted | aml.case.write_disposition binding for one case and approved fields | Paired disposition/rationale consistency, current case version, policy or valid approval, idempotency key | Write once and capture before/after state plus the downstream receipt. |
| File a SAR/STR with an FIU | Prohibited | No filing tool exists in the agent Release. | No approval can create this binding for the agent. | block · AML_SAR_FILING_AGENT_PROHIBITED · no tool call |
| Disclose an investigation to a customer or out-of-perimeter channel | Prohibited | Customer messaging, CRM notes, relationship-manager queues, and external channels are absent from the Release. | Destination and confidentiality check | block · AML_TIPPING_OFF_DESTINATION_PROHIBITED · no write or message |
| Close an alert linked to an open case | Prohibited | Open linked case removes close authority for this request. | Current linked-case query | block · AML_AUTOCLOSE_LINKED_CASE_OPEN · preserve the alert and route escalation |
| Write outside the governed case system of record | Prohibited | Only the registered case-system destination and fields are bound. | Tool ID, audience, resource, tenant, and destination match | block · AML_CASE_DESTINATION_UNAPPROVED · no downstream effect |
Approval and escalation decision table
The bands below are illustrative policy examples. The deploying organisation owns the values, validates them against its risk assessment and alert population, and approves changes through its control process. Evaluate all matching rows before execution. block has highest precedence, followed by require_approval, warn, and allow.
Each condition is machine-testable and produces a stable reason code. Action-class rules remain decisive: every SAR/STR narrative draft routes to a SAR-filing officer, and an auto-close with a risk score of at least 95 or a linked open case stays blocked.
| Outcome | Dimension | Example condition | Reason code | Execution behavior |
|---|---|---|---|---|
| block | Sanctions | confirmed_designated_party = true or authoritative_match_score >= 0.98 | AML_SANCTIONS_CONFIRMED | Stop the proposed disposition; preserve the alert and page the sanctions route. |
| block | Data quality | A mandatory transaction, customer, sanctions, or linked-case source is unavailable, malformed, or older than 72 hours | AML_REQUIRED_DATA_UNUSABLE | Stop before a case write and request source recovery. |
| block | Risk score | risk_score >= 95 for an auto-close | AML_AUTOCLOSE_ELEVATED_RISK_SCORE | Deny auto-close and route the case for investigation. |
| block | Linked case state | linked_open_case_count >= 1 for an auto-close | AML_AUTOCLOSE_LINKED_CASE_OPEN | Deny auto-close, preserve the alert, and route the linked case for investigation. |
| require_approval | Action class | action = draft_sar_str_narrative | AML_SAR_NARRATIVE_HUMAN_SIGNOFF | Hold the draft for a named SAR-filing officer. |
| require_approval | Confidence | Proposed auto-close confidence < 0.80 | AML_AUTOCLOSE_LOW_CONFIDENCE | Hold for an L2 financial-crime investigator. |
| require_approval | Risk | 60 <= risk_score < 95 for auto-close; risk_score >= 60 for escalation, SAR/STR draft, or disposition write; PEP status, prior SAR/STR, or high-risk-jurisdiction nexus | AML_ELEVATED_RISK_REVIEW | Hold for L2; route L3 when the matched rule requires it. |
| require_approval | Amount | Alert aggregate >= EUR 25,000 during the configured 30-day lookback | AML_AMOUNT_REVIEW_25000 | Hold the disposition for L2. |
| require_approval | Sanctions | 0.80 <= authoritative_match_score < 0.98 or unresolved alias/counterparty match | AML_SANCTIONS_POSSIBLE_MATCH | Hold and route the sanctions-qualified reviewer. |
| require_approval | Novelty | First 20 governed disposition requests for a new Release, tool version, typology, or destination | AML_NOVEL_RELEASE_REVIEW | Hold for L2 and collect rollout evidence. |
| require_approval | Data quality | Source age over 24 and at most 72 hours, one non-mandatory source missing, or an unresolved source conflict | AML_DATA_QUALITY_REVIEW | Hold and show the gap to the reviewer. |
| warn | Bounded review signal | Confidence 0.80 <= confidence < 0.90, risk 40–59, amount EUR 10,000–24,999.99, sanctions score 0.50 <= authoritative_match_score < 0.80, Release requests 21–99, or source age over 12 and at most 24 hours | AML_ASSURANCE_SAMPLE | Execute a permitted reversible action, record the signal, and create the defined assurance follow-up. |
| allow | Routine band | Confidence confidence >= 0.90, risk < 40, amount < EUR 10,000, sanctions score authoritative_match_score < 0.50, at least 100 clean prior Release requests, complete sources <= 12 hours, and no linked open case | AML_ROUTINE_BAND | Execute the permitted action and retain the ordinary policy and downstream records. |
Analyst review and maker-checker steps
The agent is the maker for its recommendation. Record the requesting analyst or service, the agent identity, the accountable owner, the exact proposed side effect, and the evidence digest. A checker is a distinct person with the current role required by the matched rule.
Route auto-close and disposition exceptions to a named L2 financial-crime investigator. Route higher-severity cases to L3. Route every SAR/STR narrative draft to a named SAR-filing officer or authorised delegate. The reviewer sees the alert, source facts, source freshness, risk indicators, recommendation, uncertainty, policy version, matched rules, reason codes, linked-case state, proposed destination, expiry, and expected case effect.
- Eligibility: resolve identity, decision permission, current reviewer role, delegation, training status, amount limit, and conflicts at decision time.
- Separation: compare the reviewer with the requester, recorded maker identities, and agent sponsor rules.
- Binding: bind action, parameters, destination, case version, evidence digest, policy inputs, and expiry.
- Example expiry: hold for 30 minutes; at 20 minutes route to an eligible L3 backup; at 30 minutes expire and require a fresh policy evaluation.
- Decision: approve, reject, or escalate with a reason and role snapshot. An expired request remains held.
- Release: revalidate case state, source freshness, identity, policy, and action digest before one idempotent execution.
Disposition, downstream case effects, and customer-impact boundaries
A successful governed write changes the case system of record: alert status, disposition enum, paired rationale, assigned queue, linked-case relationship, reviewer reference, and updated time. Capture the target-system receipt plus before-state and after-state digests. A downstream effect is complete when the case system confirms the expected state under the same idempotency key.
Every customer-facing channel is outside this agent’s write authority. The agent cannot send a customer message, place a relationship-manager note, change account service, freeze funds, reject a customer, or file a report. Separate organisation-owned Processes govern those effects. The triage record can reference a downstream case outcome without exposing restricted rationale to a customer-readable surface.
Override, appeal, incident, revocation, and rollback
Keep each intervention path separate because authority, timing, and evidence differ. A reviewer cannot convert a prohibited action into an approval within the held request.
| Path | Authority and effect | Required evidence | Safe result |
|---|---|---|---|
| Override | A named financial-crime authority changes a recommendation or disposition under a separate policy path before the replacement action executes. | Original outcome, authority reference, replacement decision, reason, bound action, time, policy version | Fresh evaluation of the replacement action |
| Appeal | An independent L3 or MLRO-designated role reviews the original human decision and stated grounds. | Original request and decision, appellant, grounds, assigned reviewer, evidence considered, outcome and remedy | Alert and case remain in the defined interim state |
| Incident | The incident owner stops affected runs, holds queues, contains destinations, preserves evidence, and coordinates regulatory assessment. | Scope, actor, time, cancelled and in-flight work, last accepted effect, containment acknowledgements, residue, restart authority | No new governed disposition until containment and restart approval |
| Revocation | The IAM or agent owner removes the agent’s Release binding, tool grant, workload credential, session, or delegation. | Revoked object, actor, authority, command, acknowledgement, residual lifetime, failed follow-up attempt | Future reads, drafts, and writes fail authorization |
| Rollback | The case owner restores the correct operational state after an executed disposition write, using an authorised compensating action. | Original receipt, incorrect and restored state digests, actor, approval, reason, correction reference, validation result | Append a corrective case event and preserve both the original disposition and correction in the Audit Trail |
Failure-mode and recovery table
Test negative paths from source retrieval through the confirmed downstream effect. Keep the run held or blocked until recovery refreshes the inputs and policy re-evaluates the proposed action.
| Failure mode | Detection | Enforced outcome | Recovery or containment |
|---|---|---|---|
| Missing data | Mandatory source absent, malformed, or beyond its maximum age | block · AML_REQUIRED_DATA_UNUSABLE | Restore the source, obtain a fresh snapshot, and re-evaluate policy. Create a new Decision Request only for require_approval; follow any other fresh result. |
| Conflicting signals | Disposition rationale conflicts with risk indicators or two authoritative sources disagree | require_approval · AML_CONFLICTING_SIGNALS | Show both sources to L2/L3, resolve or record the uncertainty, re-evaluate. |
| Sanctions risk | Possible match holds; confirmed designated-party match blocks | require_approval or block · AML_SANCTIONS_POSSIBLE_MATCH / AML_SANCTIONS_CONFIRMED | Route a sanctions-qualified reviewer and preserve the alert and screening evidence. |
| Policy denial | Prohibited action, destination, case state, or authority | block with the matched reason code; no tool call | Change the proposed action or use the governed policy-change path. |
| Expired approval | Current time passes expires_at or a bound input changes | block · AML_APPROVAL_EXPIRED | Expire the capability, refresh context, and re-evaluate policy. Issue a new Decision Request only for require_approval; follow any other fresh result. |
| Downstream failure | Tool reports failure, timeout, or state confirmation mismatch | Execution failed; case outcome remains unknown or unachieved | Stop retries that lack the idempotency key, reconcile actual state, open an incident, then compensate or retry under current authority. |
| Silent suspicion extinction at auto-close | Closed alert lacks a valid policy result, source set, or required L2 decision | block close and flag the case for assurance review | Reopen the alert, route L2/L3, sample adjacent closes from the same Release. |
| Disposition–rationale decoupling | Rationale omits the observed behavior or supports a different enum | block · AML_DISPOSITION_RATIONALE_MISMATCH | Regenerate or edit the paired proposal, retain both versions, re-evaluate. |
| Tipping-off leakage | Restricted content targets a customer-readable or out-of-perimeter destination | block · AML_TIPPING_OFF_DESTINATION_PROHIBITED | Revoke the binding, contain any accepted write, open an incident, assess notification duties. |
| Stale-context disposition | Case, PEP, sanctions, KYC, or linked-alert version changed after evaluation | expire or block · AML_CONTEXT_CHANGED | Fetch a fresh snapshot, supersede the request, rerun policy. |
End-to-end process map
The map identifies each actor, source system, tool boundary, decision, approval, outcome, and evidence handoff. A policy checkpoint runs before every consequential action. The held path uses maker-checker review. Every terminal path reaches a sealed record.
Text alternative. The transaction-monitoring system creates an alert for the analyst. The customer-owned agent reads the governed case context, enriches and recommends, then submits each consequential action to a policy checkpoint. Allow and warn release the bound call. Require approval holds it for an eligible L2/L3 investigator or SAR-filing officer. Block stops it. Executed, held, and blocked outcomes join the case-system effect and sealed evidence.
Scroll horizontally to inspect the diagram.
One policy checkpoint precedes each consequential action; terminal outcomes and downstream effects share one evidence chain.
Open full-size diagramEvent sequence and audit-record mapping
Use stable identifiers and ordered event references. The public AI Agent Audit Log Schema provides a vendor-neutral draft 2020-12 JSON Schema for one governed action from request through integrity verification.
The published sample contains event 01: blocked auto-close and event 02: escalated disposition. Event 02 names event 01 in lineage.ordered_event_ids, and its signed integrity.previous_event_hash equals event 01’s integrity.record_hash.
| Sequence | Workflow event | Schema field groups | Published sample | Control question |
|---|---|---|---|---|
| 1 | Request and intake | audit_event envelope, correlation, scope, actors, components, requested_action | Events 01 and 02 carry distinct requested actions and execution IDs under the same correlation ID. | Which case action was proposed, by which agent Release, for which organisation boundary? |
| 2 | Policy evaluation | policy.decision_id, policy ID/version/digests, decision, matched rules, reason codes, evaluated time | Event 01 records block for auto-close. Event 02 records require_approval under aml-elevated-risk-review and aml-amount-review-25000 for the replacement disposition write. | Which rules produced allow, warn, require_approval, or block? |
| 3 | Approval when required | approval request, expiry, required role, evidence digest, reviewer, decision, reason, rationale reference, decided time | Event 01 has no approval. Event 02 binds the approved Decision Request to the replacement write. | Did an eligible independent checker decide before expiry on the bound evidence? |
| 4 | Tool call | tool_calls tool/version/action/destination, arguments digest, idempotency key, status, result digest | Event 01 has zero tool calls. Event 02 records one successful case-system call after approval. | Which permitted operation ran after policy and approval? |
| 5 | Downstream effect | tool_calls[].downstream_effects, execution.status, business outcome, rollback and incident references | Event 01 records no achieved outcome. Event 02 records the disposition update and before/after digests. | What changed in the case system, and was the intended outcome achieved? |
| 6 | Evidence seal and export | lineage, evidence, privacy, integrity record hash, signature, and verification | Both records are signed. Event 02 links to event 01 by its real record hash. | Can a reviewer reconstruct order, handling, artifacts, and integrity? |
Sanitized sample run
Download event 01: blocked auto-close and event 02: escalated disposition. Both records validate against the public AI Agent Audit Log Schema, carry publication-only Ed25519 signatures, and form a two-event hash chain. Event 01 uses key ID aml-publication-sample-event-01-v2-2026-07-28; event 02 uses aml-publication-sample-event-02-v3-2026-07-28 to illustrate signing-key rotation. Every identity, organisation reference, case ID, amount, key, and artifact reference is synthetic.
In case CASE-SYN-AML-2026-0728, rapid round-number transfers total EUR 48,000. The synthetic customer is marked as a PEP, the corridor is high risk, and a linked case is open. Event 01 records the blocked auto-close with no approval or tool call. Event 02 records a new escalation-disposition request, approval by a named reviewer for an action requiring the L2 financial-crime-investigator role, the governed case write, and the reported downstream state. The schema records the required role and reviewer identity separately; this sample does not include an IAM role-membership snapshot proving the reviewer held that role at decision time.
| Stage | What happened | Control meaning |
|---|---|---|
| Intake | Transaction-monitoring alert ALRT-SYN-77214 binds EUR 48,000 of rapid round-number transfers to CASE-SYN-AML-2026-0728. | The detection time, synthetic case, amount, run, and source packet share one correlation. |
| Recommendation | The agent proposes auto-close while the packet shows PEP status, a high-risk corridor, and linked open case CASE-SYN-AML-2026-0611. | The proposal and rationale remain evidence. They create no case effect. |
| Policy | The auto-close attempt matches AML_ELEVATED_RISK_REVIEW, AML_AMOUNT_REVIEW_25000, and AML_AUTOCLOSE_LINKED_CASE_OPEN. A fresh request to write an escalation disposition returns require_approval under the first two rules. | The linked-case block takes precedence. The replacement action receives its own evaluation and execution ID. |
| Reviewer | Avery Quinn (synthetic reviewer) approves the escalation disposition before the 30-minute expiry. | The event binds the named reviewer identity, required role, evidence digest, decision reason, and time. External IAM evidence is needed to prove role membership at the decision time. |
| Execution | The governed case-system tool runs once with event 02’s execution-scoped idempotency key after approval. | The approved replacement action reaches only the synthetic case system of record. |
| Downstream effect | The case disposition changes from open_pending_triage to escalated_l3 and reports case_disposition_updated with before/after digests. | The terminal record includes an explicit business outcome and target-system receipt. |
| Evidence | The two signed records list only their published event IDs. Event 02’s previous-event hash equals event 01’s record hash. | A reviewer can validate both envelopes, verify both signatures, check the two policy paths, and verify the chain link from the published files. |
Downloadable evidence bundle manifest
Download the AML alert-triage evidence manifest to define one Sealed Evidence Bundle. It lists the manifest, audit event, source lineage, policy result, approval record, tool receipt, downstream effect, artifact hashes, signature material, redactions, omissions, retention, and export verification.
The machine-readable reference contains the blocked auto-close record and the terminal escalated-disposition record. The manifest identifies the checks available from these two published files and the surrounding evidence a production bundle would need.
Implementation checklist
Use the AML alert-triage implementation checklist to stand up the control path. The worksheet covers the action inventory, six threshold dimensions, least-privilege bindings, maker-checker routing, evidence sealing, negative tests, interventions, retention, and export.
- Inventory every read, draft, write, filing, and communication action.
- Set and approve confidence, risk, amount, sanctions, novelty, and data-quality bands.
- Bind the active Release to case-scoped Tool Catalog entries and Data Boundaries.
- Wire L2/L3 and SAR-filing-officer routes with identity separation and expiry.
- Join policy, approval, tool, downstream effect, lineage, privacy, and integrity evidence.
- Test missing data, conflicts, sanctions risk, policy denial, expiry, and downstream failure.
- Exercise override, appeal, incident, revocation, and Rollback.
- Set the jurisdiction-specific retention schedule and verify a recipient can export and validate the bundle.
Evidence retention and export
Reconcile every applicable retention minimum, privacy or data-minimisation maximum, and legal hold, then retain each record only for the resulting lawful period. Minima can include the six-month floor in EU AI Act Article 26(6) when that deployer duty applies to a high-risk AI system and the five-year US bank SAR rule in 31 CFR § 1020.320(d). Privacy law can impose a shorter ceiling, and a legal hold can suspend scheduled deletion. Resolve conflicts under the organisation’s actual legal scope and preserve the rule and authority used for each record.
Export the alert slice through Evidence Room as a Sealed Evidence Bundle, or organise it around a framework as a Control Pack. Include redaction and omission records so the recipient can distinguish absent material from intentionally withheld fields. Compare the bundle shape with the public Evidence Room sample, then verify artifact digests, record hash, signature, event order, and downstream receipt outside the producing workflow.
How KLA implements the alert-triage control path
The KLA Control Plane governs instrumented actions from a customer-owned alert-triage agent. The KLA Policy Engine evaluates a proposed action and returns allow, warn, require_approval, or block. A require_approval outcome holds the action and creates a Decision Request for Decision Desk. A block prevents the governed tool call from reaching its destination.
For control-plane Decision Requests, Decision Desk checks decision permission, the required reviewer role, and pending status before recording a decision. Requester/maker separation and expiry or due-time enforcement remain organisation-owned controls. The organisation must implement and verify those controls across every producing and decision path, and keep reviewer competence, delegation, amount authority, and training current.
Lineage Explorer and Audit Trail expose policy, reviewer, execution, and downstream records. Evidence Room packages selected records into a Sealed Evidence Bundle with artifact hashes and integrity material. The organisation owns the alert-triage agent, source completeness, threshold values, action inventory, case-system integration, SAR/STR filing control, customer-impact boundaries, reviewer staffing, retention schedule, and recovery across external systems. The policies, tool names, threshold bands, roles, and synthetic run in this article are illustrative; they describe a reusable implementation pattern rather than a deployed customer control.
Primary sources and freshness
Source review completed 28 July 2026. Regulatory claims below state their jurisdiction and workflow scope. The example policy thresholds remain organisation-owned implementation choices.
| Jurisdiction or authority | Source and scope | Workflow relevance |
|---|---|---|
| Global standard | FATF Recommendations, updated June 2026: Recommendation 10(d) covers ongoing scrutiny for consistency with customer knowledge; Recommendation 20 calls for prompt reporting of suspicions to the FIU. | Current source context and escalation discipline for institutions implementing FATF-based AML/CFT rules. |
| European Union | Regulation (EU) 2024/1624, Article 69: EU obliged entities promptly report qualifying suspicions, regardless of amount, and report suspicious and attempted transactions plus CDD-failure suspicions. | Auto-close and escalation controls preserve the report-or-investigate path. The AMLR applies from 10 July 2027. |
| European Union | Regulation (EU) 2024/1624, Article 73: EU obliged entities and covered directors, employees, agents, and distributors restrict disclosure to customers and third persons about assessment, FIU transmission, or ML/TF analysis, subject to stated exceptions. | Data Boundaries and destination blocks contain tipping-off risk. |
| United States banks | 31 CFR § 1020.320(b)(3), (d), and (e): bank SAR filing within 30 calendar days after initial detection, up to 60 days where no suspect was identified; five-year retention; SAR confidentiality. | Seal initial detection, protect restricted content, and retain the filed SAR and supporting evidence for the applicable bank scope. |
| United States financial institutions | 31 U.S.C. § 5318(g)(2)(A)(i): reporting institutions and covered people or agents may not notify a person involved that the transaction was reported or reveal information showing it was reported. | Exclude customer and out-of-perimeter destinations from the agent Release. |
| US FDIC-supervised institutions in stated scope | SR 11-7 / OCC 2011-12 as adopted in FDIC FIL-22-2017, amended March 2026: model-risk practices include effective challenge by objective, informed parties; the FDIC applicability statement generally covers institutions with at least USD 1 billion in assets and smaller institutions where model use is significant, complex, or elevated risk. | Maker-checker review and independent sampling support effective challenge where this supervisory guidance applies. |
| European Union, high-risk AI systems | EU AI Act Article 12, Article 14, and Article 26: automatic logging, effective human-oversight capabilities, competent deployer oversight, and at least six months of deployer-controlled logs. | These requirements apply when the system is a high-risk AI system and the organisation holds the relevant provider or deployer duty. The workflow reuses their logging and oversight discipline more broadly. |
| European Union, high-risk classification list | EU AI Act Annex III lists high-risk use cases and includes the financial-fraud exception to point 5(b) creditworthiness systems. | Use the separate classification guide for the deployment-specific scope decision; this workflow guide does not resolve classification. |
| European Union, application dates | Regulation (EU) 2026/1744 moves Chapter III Sections 1–3 to 2 December 2027 for Article 6(2)/Annex III systems and 2 August 2028 for Article 6(1)/Annex I systems. | The changed date matters only where the relevant system falls within those high-risk categories. AML and model-risk duties keep their own scope and dates. |
Frequently Asked Questions
What starts an AML alert-triage agent run?
A transaction-monitoring alert starts one bounded run. The intake binds the alert, triggering transactions, detection time, current case context, agent Release, requester, accountable owner, and correlation identifiers.
Which AML alert-triage actions need a policy checkpoint?
Auto-close, escalation, SAR or STR narrative drafting, and disposition writes need a checkpoint before their side effect. Enrichment, factual summarisation, and recommendation remain informational.
Can the agent file a SAR or STR?
The agent has no FIU filing tool or entitlement. It can create an internal narrative draft inside the restricted Data Boundary. A named SAR-filing officer owns the separate filing decision and control.
How should approval thresholds be set?
Set concrete bands for confidence, risk, amount, sanctions, novelty, and data quality from the organisation’s alert population, legal scope, risk appetite, reviewer capacity, and validation evidence. Approve and version every change.
What happens when several policy rules match?
Evaluate every applicable rule and keep the strongest result. Block has highest precedence, followed by require_approval, warn, and allow. The record keeps all matched rules and reason codes.
How does maker-checker work for an AML case?
The agent is the maker for its recommendation. The organisation assigns a distinct eligible L2 or L3 investigator to check a held disposition and a SAR-filing officer to check every narrative draft. The organisation’s decision path must bind identity, role, evidence, action, destination, case state, and expiry.
What proves the downstream case outcome?
The tool receipt, idempotency key, effect reference, before-state digest, after-state digest, execution status, and business outcome join the policy and reviewer records under one execution and lineage record.
How should an executed disposition be rolled back?
Use an authorised compensating case action to restore the correct operational state. Preserve the original write, correction, actors, approvals, receipts, and both state digests in the Audit Trail.
How long should AML alert-triage evidence be retained?
Reconcile applicable retention minima, privacy or data-minimisation maxima, and legal holds, then keep each record only for the resulting lawful period. Relevant minima can include the EU AI Act Article 26 six-month floor and the US bank SAR five-year rule where each applies.
What does KLA provide for this workflow?
KLA provides shipped control-plane capabilities for instrumented action evaluation, four policy outcomes, Decision Desk routing, lineage and audit records, and evidence packaging. The organisation owns and runs the agent, sources, thresholds, case integration, reviewers, filing control, retention, and recovery.
Key Takeaways
A defensible AML alert-triage workflow binds one case, gives the customer-owned agent narrow read, draft, and case-write authority, evaluates six explicit threshold dimensions, holds consequential exceptions for an eligible checker, contains prohibited destinations, and joins the real case effect to signed evidence. Download the AML alert-triage evidence manifest and use it to define the proof package before testing the positive and negative paths.