Transaction Monitoring

Alert Triage Workflows: SLA Benchmarks & Case Standards

Once an alert fires, the work that determines whether it becomes a SAR — or gets dismissed in error — happens in triage. This is the operational layer regulators inspect when assessing whether the firm's transaction monitoring is working as a control. This guide covers the priority tiers that should exist, the SLA benchmarks production programmes operate at, and the case-handling documentation standards that distinguish defensible triage from rubber-stamping.

Published: May 2026 Category: Transaction Monitoring Read time: ~12 minutes
Quick Answer
Alert triage is the workflow between alert generation and case disposition. The structure expected by every major AML regulator has three components: priority tiering (typically P1/P2/P3 based on the alert's underlying risk signal), service-level expectations proportionate to each tier (typically 24h for P1, 5–10 business days for P2, 30 days for P3), and escalation paths from analyst review through senior compliance to MLRO sign-off. The standard distinction between defensible triage and rubber-stamping lives in the documentation: every alert disposition records the reasoning, the data reviewed, the customer context, and the supporting evidence. Programmes that consistently produce thin disposition records — even where the dispositions are correct — accumulate inspection findings because the regulator cannot verify the decision quality without the documentation. The architecture matters; the audit trail matters more.

Most firms have spent significant effort calibrating their transaction monitoring rules and significantly less effort designing the triage workflow that handles the alerts those rules produce. The result is recognisable across the industry: alerts accumulate, analysts work through them in queue order without prioritisation, dispositions are documented thinly because the time pressure does not permit more, and the case files that eventually reach a regulator are uneven in quality.

Triage is operational compliance. It is where the abstract architecture of transaction monitoring becomes a concrete control with measurable performance. The standards below are not aspirational — they are the operational benchmarks the better firms in each market actually hit, and the inspection expectations regulators have begun to apply consistently.

Priority Tiering: What Actually Distinguishes the Levels

A defensible triage system uses priority tiering aligned to the underlying risk signal of each alert. Three tiers are the operational standard; some firms use four or five for finer-grained workflow routing.

1

Priority 1 (P1) — Immediate Risk

Sanctions matches, suspected funding of terrorism, alerts on customers flagged as high-risk in the firm's risk assessment, alerts involving very large amounts above the firm's defined threshold for senior review. The defining characteristic is that delay is itself a risk — every hour the alert sits unworked, the firm is potentially facilitating activity it should be blocking. SLA expectation: same-day initial review, typically within 4 hours of generation during business hours; 24-hour maximum to initial disposition.

2

Priority 2 (P2) — Material Suspicion

Alerts on standard-risk customers exhibiting clear typology patterns (structured-deposit patterns, unusual cross-border activity, counterparty risk signals), alerts on PEP-classified customers, alerts where the underlying transaction has already settled. Delay is bounded — the activity has happened or is happening, but the firm's enforcement action is reactive rather than blocking. SLA expectation: initial review within 5–10 business days; full disposition within 30 days.

3

Priority 3 (P3) — Baseline Review

Alerts on low-risk customers with marginal pattern triggers; alerts that have been generated on the same customer-pattern combination repeatedly with consistent benign dispositions. The category includes much of the false-positive volume; the regulatory expectation is that they still receive substantive review, but the SLA is more relaxed because the inherent risk is lower. SLA expectation: review within 30 days; full disposition within 60 days.

Calibration Note
The tier definitions above are operational benchmarks, not regulatory mandates. Each firm should calibrate its tier definitions and SLA expectations against its risk appetite, customer base, alert volume and analyst capacity — and document the calibration. What regulators inspect is consistency: alerts of similar risk profile receiving similar SLA treatment, not arbitrary variation across the queue.

The Escalation Path That Should Exist

Every alert moves through a defined sequence of review stages. The number of stages and the criteria for advancement should be documented in the firm's procedures and reflected in the case-management system. The standard pattern:

  • Analyst initial review. The L1 analyst examines the alert, the underlying transaction(s), the customer context (KYC profile, prior alerts, transaction history) and supporting external data. Initial disposition: dismiss as false positive with documented reasoning, escalate for further investigation, or escalate directly to senior review.
  • L2 investigation. Where the initial review is insufficient to determine disposition, an L2 analyst conducts deeper investigation — extended counterparty analysis, source-of-funds documentation, adverse-media checks, customer contact where appropriate. The L2 review produces either a clear disposition or escalation to senior compliance.
  • Senior compliance review. Where the L2 investigation suggests material suspicion, the case escalates to senior compliance for review. The senior reviewer assesses both the case itself and the broader pattern — is this customer producing repeat escalations? Is this typology growing across the customer base? Senior review produces the recommendation for SAR filing or relationship action.
  • MLRO sign-off. SAR filings and material relationship decisions (account closure, restriction of services) require MLRO sign-off. The MLRO's review is the final check that the firm's response is consistent with both internal policy and regulatory expectation.

The escalation criteria should be explicit. "Customer is a PEP and the alert involves transactions above $100,000 from a high-risk jurisdiction" is documented; "the analyst thought it looked unusual" is not. Inspectors test whether escalation criteria are applied consistently across the alert population.

Case Handling Documentation Standards

The documentation each case requires is the single most consistent inspection finding. The standards below describe what should be in every closed case file — regardless of the disposition.

  • The alert itself. Which rule fired, what attributes triggered the rule, what was the customer cohort and risk classification at the time of firing.
  • The underlying transactions. Full transaction detail for every transaction the alert relates to — amounts, counterparties, dates, narratives, payment messages. The case file should be self-contained; a reviewer should not need to query other systems to understand the activity.
  • The customer context. KYC profile snapshot at the time of the alert (customer type, declared business, declared sources of wealth, risk classification), prior alert history, prior CDD/EDD documentation referenced.
  • The external data reviewed. Adverse media checks, sanctions/PEP rescreening, counterparty verification, any third-party data sources used. Negative results documented as explicitly as positive results — "no adverse media found" is itself a finding requiring documentation.
  • The customer engagement (where applicable). If the customer was contacted for explanation, the contact, the questions asked, the responses received, and the analyst's assessment of the responses. Customer engagement that produces verbal explanation should have the verbal explanation summarised in the case file.
  • The reasoning for the disposition. Not just "false positive" or "no SAR" — the substantive reasoning: which patterns were examined, what the analyst concluded about each, why the combined conclusion supports the disposition. The reasoning is the inspection target; thin reasoning is what produces findings.
  • The approval chain. Who reviewed at each escalation level, who approved the disposition, when each step occurred. Modern case management systems capture this automatically; legacy systems often have gaps.
Inspection Reality
In post-inspection feedback across MAS, FCA, FinCEN and AUSTRAC, the most common transaction-monitoring finding is not "you missed cases" — it is "your case-handling documentation does not allow us to verify the quality of your decisions." A case file with full evidence supporting a no-SAR disposition is defensible; a case file with thin documentation supporting the same disposition is not, regardless of whether the underlying decision was correct. Build the documentation discipline into the workflow, not into post-hoc clean-up.

SLA Benchmarks Used in Production

The SLA benchmarks below reflect the operational standards observed across mid-sized to large firms in the major financial centres. They are not regulatory mandates but they are the de-facto inspection benchmark in most jurisdictions.

  • P1 alerts: initial review within 4 business hours; full disposition within 24 hours. Where the alert involves a sanctions match, real-time pending-transaction holds may apply pending disposition. Same-day MLRO escalation for confirmed sanctions hits.
  • P2 alerts: initial review within 5–10 business days; full disposition within 30 days. Where investigation requires customer engagement, the 30-day clock may extend with documented reason. SAR filing decisions made within the 30-day window unless explicit extension is documented.
  • P3 alerts: review within 30 days; full disposition within 60 days. Where the alert is part of a recurring pattern with prior benign dispositions, aggregated review across the pattern is acceptable; per-alert review is not always required.
  • SAR filing deadlines: Per regulator. FinCEN allows 30 days from initial detection (extendable to 60 in specific circumstances); MAS expects "as soon as practicable"; FCA via the NCA expects "immediate" once suspicion is established; AUSTRAC has specific 3-day and 10-day windows for different SMR categories.
  • Backlog visibility: Open alerts older than their SLA window should be visible to senior compliance daily. Backlog accumulation is itself a finding; the absence of backlog reporting is a finding.

The SLAs should be calibrated to the firm's actual alert volume and analyst capacity — chasing benchmark numbers without the operational capacity to meet them produces missed SLAs and demoralised teams. Where the gap exists, the response is either to expand capacity, reduce alert volume through rule tuning, or document a different SLA reflecting the firm's risk appetite.

Common Failure Modes in Triage

Six failure patterns recur in supervisory feedback on transaction-monitoring triage:

  • No effective prioritisation. Alerts work through the queue in order of generation rather than order of risk. Real P1 alerts sit behind older P3 alerts; the underlying risk to the firm is invisible in the queue structure.
  • Thin documentation under workload pressure. Disposition notes shrink as the queue grows — "no STR" rather than the substantive reasoning. The reasoning is what regulators verify; its absence is the finding.
  • No escalation triggered where pattern warrants. The analyst dismisses each alert in isolation; the pattern across the customer's alert history is not visible at the L1 review level; senior compliance never sees the case despite repeat firings.
  • SLAs measured but not acted on. Backlog reports produced and ignored. The firm has visibility into the gap but no operational response — the inspection finding writes itself.
  • Customer engagement not used or not documented. The analyst could have asked the customer; either the policy does not permit it, or the policy permits it but the analyst defaulted to dismissal. The verbal explanation that would have resolved the alert is never obtained.
  • Rubber-stamp dispositions. Closure rates per analyst that are statistically anomalous (very high dismissal rates, very short average disposition times) without corresponding case-file evidence of substantive review. Inspectors look at per-analyst metrics specifically because rubber-stamping shows up there.

Operational Mechanics That Work

Five operational practices distinguish high-performing triage functions from struggling ones:

  • Single case-management platform. All alerts flow into one queue with consistent prioritisation, consistent documentation templates, consistent escalation routing. Multi-platform setups produce inconsistent handling at scale.
  • Pattern aggregation across alerts. The case manager surfaces the customer's full alert history when an analyst opens a case — the analyst sees the pattern, not just the individual alert. Repeat firings on the same pattern aggregate for review.
  • Templated documentation. Disposition templates that prompt for each required element of the case file. Templates do not write the reasoning, but they ensure the reasoning is structured and complete.
  • Per-analyst quality review. A sample of each analyst's dispositions reviewed periodically (typically 10% per quarter) by senior compliance. The review provides both individual coaching and aggregate quality assurance evidence for inspection.
  • Backlog management as a daily activity. The senior compliance team reviews backlog daily, reallocates capacity to drive SLA compliance, and escalates persistent gaps to management. The discipline is recurring rather than reactive.

One Constellation's transaction monitoring platform ships with integrated case management, templated dispositions, pattern aggregation across customer alert history, and configurable SLA tracking — designed to support the triage discipline rather than work against it.

Triage Workflow That Survives Inspection

One Constellation includes case management, priority tiering, SLA tracking, pattern aggregation and templated disposition workflows — so the documentation discipline is built into the platform, not retrofitted into post-hoc clean-up.

← TM Rule Tuning Behavioural vs Rule-Based → All Articles
Scroll to Top