Alert triage and investigation

An alert is a question, not an answer. What turns monitoring into compliance is the work done on each alert: gathering facts, testing explanations, and recording a decision that someone else can understand months later. Supervisors and auditors read closed alerts more closely than almost anything else in a program, because weak investigations and thin closure notes reveal whether the monitoring is real.

The alert lifecycle

Every alert moves through the same stages, and each stage needs an owner, a time standard and a record.

Alerts from different sources about the same customer should be grouped into one case, so one investigator sees the whole picture. Internal referrals from customer support, fraud teams or relationship managers are alerts too, and often the most productive ones.

Time standards matter because FATF Recommendation 20 requires reports to be made promptly. A firm sets internal targets for each stage and tracks aging: an alert that sits untouched for weeks is a control failure even if the eventual decision is right.

Prioritization

Queues are rarely empty, so order matters. A risk-based priority score usually combines:

• the severity of the scenario (exposure to sanctions, terrorist financing or child abuse material ranks above a volume rule);
• the amount and whether funds are still on the platform (a pending withdrawal can still be stopped);
• the customer's risk rating and history of prior alerts;
• the strength of analytics exposure (direct before indirect, recent labels before old ones);
• links to other open cases.

Alerts where funds can still be held or where a pre-transaction block applies go first. Prioritization must not become silent suppression: low-priority alerts still need a decision within the time standard, or a documented, approved reason why they are batch-closed.

Investigation steps

A consistent sequence keeps investigations comparable and complete.

1. Understand the alert. Which rule fired, with what parameters and values, and why is it considered a risk?
2. Review the customer profile. Onboarding data, declared occupation and purpose, expected activity, source of funds and wealth, risk rating, prior alerts and reports, recent changes to details.
3. Review the activity. The customer's full transaction history around the alert: deposits, trades, withdrawals, fiat rails, internal transfers. Is this a change from the customer's normal pattern?
4. Trace on-chain. Follow funds backward from deposits and forward from withdrawals, using analytics and manual review (see the lesson Blockchain analytics for compliance; for techniques, the IDFE-BA lesson Tracing funds forward and backward). Note hop counts, services passed through and label sources.
5. Check counterparty data. Travel Rule information from the counterparty VASP, its due diligence status, and whether the beneficiary or originator name matches what the customer said.
6. Use internal data. Logins, devices, IP addresses and geolocation, shared attributes with other accounts, support conversations.
7. Ask the customer if needed. A request for information (RFI) asks for documents or an explanation: an invoice, a trade record, proof of a sale, a source-of-funds document. It is normal due diligence, so it must be phrased neutrally and must never mention suspicion, alerts or any report (see the lesson Ongoing due diligence and exits on tipping-off).
8. Conclude. State the hypothesis tested, the evidence for and against, and the decision.

Investigators should consider at least one innocent explanation and one illicit explanation for each alert and record which the evidence supports. This guards against both rubber-stamping and confirmation bias.

Closing or escalating

The decision depends on whether the evidence explains the activity, not on how much effort has been spent.

Escalation is not the same as reporting: the compliance officer or MLRO applies the suspicion threshold described in the lesson Suspicious transaction reporting obligations and records the reasoning whether or not a report is filed. A closure is never "no concerns" alone.

Documenting the rationale

A good closure note lets a reviewer who has never seen the case understand, without opening other systems, what was alerted, what was checked, what was found and why the decision followed. It contains facts with sources and dates, references to transactions (txids, amounts, timestamps), the explanation and its evidence, and any limitations, such as an expired label or a trace that stopped at a service. Weak notes say "activity in line with profile" without saying what the profile is, or rely on the customer's word without evidence.

A structured case record captures the same in fields that can be audited and counted:

{
  "case_id": "CASE-2026-04417",
  "alerts": ["A-88121 rapid_in_out", "A-88134 indirect_scam_exposure"],
  "customer_id": "C-20931",
  "opened": "2026-10-02T09:14:00Z",
  "steps": ["profile reviewed", "trace 3 hops back", "linked accounts checked",
            "RFI sent 2026-10-03, answered 2026-10-06"],
  "findings": "Source funded by peel chain from cluster attributed to investment-scam platform; two other customers received from same source; explanation not evidenced",
  "decision": "ESCALATED",
  "decided_by": "L2-analyst-17",
  "mlro_outcome": "REPORTED",
  "account_action": "withdrawals restricted pending review",
  "qa_sampled": true
}

The record links the alerts to one case, lists the steps taken with dates, summarizes the findings in plain words, and separates the investigator's decision from the MLRO's outcome and the account action. Fields like these feed the metrics discussed in the lesson Tuning, metrics and model governance.

Quality assurance

Quality assurance re-reviews a sample of closed and escalated alerts against a checklist: were all steps done, is the rationale supported, was the decision right, was the time standard met? Sampling should be risk-based (more from high-risk scenarios and new analysts) and include closed alerts, since wrongly closed alerts are the costly errors. Results are fed back to analysts, used in calibration sessions where investigators decide the same case independently and compare, and reported to management. Recurring errors point to a training need, an unclear procedure or a rule that produces confusing alerts.

A worked case

Customer C-20931, a graphic designer onboarded fourteen months ago, declared expected activity of about USD 1,000 a month. Two alerts fire on the same day: a deposit of about USD 18,000 in BTC withdrawn as fiat to a newly added bank account within three hours, and 22% indirect exposure, two hops back, to a cluster attributed to an investment-scam platform.

• Profile: the amount is 18 times the expected monthly activity, with no prior crypto deposits of this size.
• Trace: the sending address was funded by a peel chain from the scam cluster; the label comes from a public law-enforcement release dated four months earlier.
• Links: two other customers received deposits from the same peel chain in the same week, and one shares a device with C-20931.
• RFI: the customer says the funds were payment for a used laptop but provides no invoice or messages, then says a friend asked for help receiving money.

The evidence supports the illicit hypothesis: the customer is probably acting as a money mule (see the lesson Red flags and typologies). The investigator escalates; the MLRO files a report, restricts withdrawals pending review, and opens cases on the two linked customers. The QA sample later confirms the decision and notes that the label date was correctly recorded.

Exam focus: the stages of the alert lifecycle and their owners; grouping alerts into cases and tracking aging against R.20's promptness; risk-based prioritization without silent suppression; the investigation sequence, including on-chain tracing, Travel Rule counterparty data, internal device and IP data, and neutral requests for information that avoid tipping-off; the close, pend, escalate decision table; escalation versus reporting; what a defensible closure note contains; risk-based QA sampling and calibration.