# AML alert-triage control-path implementation checklist

Version: 1.0

Published: 28 July 2026

Owner: ____________________

Target Release: ____________________

Use this checklist to implement and test one governed AML alert-triage workflow. Record the
organisation's legal scope, source systems, policy bands, reviewer authority, recovery duties, and
evidence references.

## 1. Bound the workflow

- [ ] Define one run as one alert, one dated case snapshot, one recommendation, and one final
      disposition request.
- [ ] Assign stable alert, case, correlation, execution, lineage, and idempotency identifiers.
- [ ] Name the L1 analyst, customer-owned agent, accountable financial-crime owner, eligible L2/L3
      reviewers, and SAR-filing officer.
- [ ] Record the transaction-monitoring and case systems of record.
- [ ] Define the retry rule and prevent duplicate case effects.
- [ ] Record applicable jurisdictions, entity types, products, reporting clocks, confidentiality
      duties, and internal control owners.

## 2. Inventory every action

- [ ] List each source read and permitted purpose.
- [ ] List enrichment, summarisation, risk-indicator, and recommendation operations.
- [ ] Define the governed auto-close or dismiss action.
- [ ] Define the governed L2/L3 escalation action.
- [ ] Define the internal SAR/STR narrative-draft action.
- [ ] Define the governed case-disposition and rationale write.
- [ ] Prohibit agent filing to an FIU and verify no filing tool binding exists.
- [ ] Prohibit customer and out-of-perimeter disclosures.
- [ ] Prohibit alert close when a linked case is open.
- [ ] Prohibit writes outside the registered case system of record.
- [ ] Assign a stable reason code and zero-side-effect assertion to every prohibited action.

Action inventory owner: ____________________

Approved version: ____________________

## 3. Define the AML Data Boundary

- [ ] List permitted alert, transaction, KYC/CDD, expected-activity, risk, PEP, sanctions,
      related-case, and prior-disposition fields.
- [ ] Define purpose, case, tenant, region, recipient, time, and field-level boundaries.
- [ ] Set a maximum source age for each fact.
- [ ] Minimise raw personal data and tokenise publication or test samples.
- [ ] Exclude customer messaging, relationship-manager notes, general CRM writes, unrestricted
      database access, and external training exports.
- [ ] Protect SAR/STR material and information revealing an investigation across tools, logs,
      prompts, reviewer surfaces, and exports.

## 4. Bind identity and least-privilege tools

- [ ] Register the dedicated agent identity and accountable owner.
- [ ] Bind the executing workload identity and approved environment.
- [ ] Create an immutable Release reference for model, instructions, configuration, and tools.
- [ ] Bind case-scoped read tools.
- [ ] Bind restricted internal draft tools.
- [ ] Bind L2/L3 escalation and case-disposition writes to exact fields and destinations.
- [ ] Remove wildcard, FIU filing, customer-message, CRM-note, and general database grants.
- [ ] Test expired Release, wrong tenant, wrong audience, wrong case, wrong destination, and
      revoked credential failures.

## 5. Set the six policy threshold dimensions

The values below are organisation-owned.

| Dimension | `allow` | `warn` | `require_approval` | `block` | Owner and evidence |
| --- | --- | --- | --- | --- | --- |
| Confidence |  |  |  |  |  |
| Risk and case state |  |  |  |  |  |
| Amount and lookback |  |  |  |  |  |
| Sanctions |  |  |  |  |  |
| Novelty of Release/tool/typology/destination |  |  |  |  |  |
| Data quality, conflicts, completeness, freshness |  |  |  |  |  |

- [ ] Define strongest-outcome precedence: `block`, `require_approval`, `warn`, `allow`.
- [ ] Use concrete numeric, boolean, enum, age, count, destination, and action conditions.
- [ ] Give every rule a stable ID and reason code.
- [ ] Route every SAR/STR narrative draft to a SAR-filing officer.
- [ ] Block auto-close when a linked case is open.
- [ ] Version, approve, test, and monitor every threshold change.

## 6. Wire maker-checker routing

- [ ] Treat the agent as maker for its recommendation.
- [ ] Record the requester and every recorded maker identity.
- [ ] Route disposition exceptions to an eligible L2 investigator.
- [ ] Route higher-severity rules to an eligible L3 investigator.
- [ ] Route every SAR/STR narrative draft to an eligible SAR-filing officer or authorised delegate.
- [ ] Check decision permission, required role, delegation, competence, training, amount authority,
      conflicts, pending state, and due time.
- [ ] Prevent a recorded requester or maker from deciding the request.
- [ ] Bind the reviewer to the exact action, parameters, destination, case version, policy inputs,
      evidence digest, and expiry.
- [ ] Define timeout escalation and the safe state after expiry.
- [ ] Revalidate case state, source freshness, identity, policy, approval, and action digest before
      one idempotent execution.

## 7. Join and seal evidence

- [ ] Record schema version, event, correlation, execution, scope, actors, and components.
- [ ] Record exact requested action, purpose, resource, Data Boundary, environment, and amount.
- [ ] Record policy ID/version/digest, inputs digest, outcome, matched rules, reason codes, and time.
- [ ] Record approval request, expiry, role, evidence digest, reviewer, decision, reason, and time.
- [ ] Record tool/version, destination, arguments digest, idempotency key, status, and result digest.
- [ ] Record before/after state digests, effect reference, business outcome, and unresolved residue.
- [ ] Order source, recommendation, policy, approval, tool, outcome, recovery, and seal events in
      lineage.
- [ ] Record classification, access policy, redactions, and omissions.
- [ ] Hash artifacts, canonicalise the audit event, sign the record, and verify the signature.
- [ ] Export a Sealed Evidence Bundle and verify it outside the producing workflow.

## 8. Test the six required negative paths

| Test | Expected policy or execution result | Observed result | Evidence | Verdict |
| --- | --- | --- | --- | --- |
| Missing mandatory data or stale source | `block` before case write |  |  |  |
| Conflicting authoritative signals | `require_approval`; conflict visible to reviewer |  |  |  |
| Possible and confirmed sanctions risk | Hold possible match; block confirmed match |  |  |  |
| Prohibited action or destination | `block`; zero tool calls |  |  |  |
| Approval expired or input changed | Expire; fresh evaluation required |  |  |  |
| Downstream failure or confirmation mismatch | Failed or unknown outcome; reconcile safely |  |  |  |

## 9. Test the AML-specific failure paths

- [ ] Silent suspicion extinction: deny unsupported auto-close, reopen affected alert, sample
      adjacent Release decisions.
- [ ] Disposition-rationale decoupling: deny mismatched pair, retain both versions, re-evaluate.
- [ ] Tipping-off leakage: deny destination, revoke binding, contain any accepted write, open an
      incident.
- [ ] Stale-context disposition: expire request after source or case change, refresh, re-evaluate.

## 10. Test intervention and recovery

- [ ] Override uses distinct authority, reason, evidence, and a fresh replacement-action evaluation.
- [ ] Appeal uses an independent L3 or MLRO-designated reviewer and preserves a safe interim state.
- [ ] Incident response stops runs, holds queues, contains destinations, preserves evidence, and
      names restart authority.
- [ ] Revocation removes Release bindings, tool grants, credentials, sessions, and delegation; a
      later request fails.
- [ ] Rollback uses an authorised compensating case action and preserves original and corrected
      states.
- [ ] Partial, timed-out, duplicated, and ambiguous downstream effects reconcile through the
      idempotency key and target-system receipt.

## 11. Confirm retention and export

- [ ] Record every applicable legal and sector retention minimum, privacy or data-minimisation
      maximum, legal hold, and internal schedule with its authority.
- [ ] Apply at least the EU AI Act Article 26(6) six-month floor where that deployer duty applies.
- [ ] Apply the US bank SAR five-year retention rule where 31 CFR § 1020.320(d) applies.
- [ ] Reconcile retention minima, maxima, and legal holds, then retain each record only for the
      resulting lawful period; do not default to the longest schedule.
- [ ] Set access review, deletion authority, legal-hold, redaction, and export controls.
- [ ] Export the alert slice as a Sealed Evidence Bundle or Control Pack.
- [ ] Validate schema, hashes, signature, event order, reviewer separation, policy outcome,
      downstream effect, redactions, and omissions as the recipient.

## 12. Sign-off

- Control owner:
- Financial-crime risk owner:
- MLRO or designated authority:
- Technical owner:
- Case-system owner:
- Privacy owner:
- Approved policy version:
- Approved Release:
- Negative-test evidence:
- Recovery drill evidence:
- Effective date:
- Next review:
- Change triggers:
- Known limitations:

This checklist supports implementation and internal control testing for the stated workflow,
organisation, systems, jurisdiction, period, and evidence. It does not certify legal compliance.