From Alert to STR: Running the Escalation Pipeline

Transaction monitoring produces alerts; the law is only interested in what you conclude from them. Under PCMLTFA s. 7, every reporting entity must report to FINTRAC any financial transaction — completed or attempted — where there are reasonable grounds to suspect it is related to a money laundering offence, a terrorist activity financing offence, or (since August 19, 2024, per FINTRAC Special Bulletin FINTRAC-2024-SB002) a sanctions evasion offence. There is no dollar threshold for an STR, and attempted transactions count even though no money moved.

The escalation pipeline exists to bridge the gap between "a rule fired" and "reasonable grounds to suspect." A velocity rule tripping on a customer's payroll cycle is not suspicion; the same rule tripping on a new customer whose stated business does not explain the flow might be, once you have looked. The pipeline's job is to make that looking systematic, timed, and documented.

Most teams run three stages. Triage is a fast pass: is this alert explainable on its face (known customer behaviour, data error, rule misfire), or does it need a case? Triage should close obvious noise quickly but record why — a one-line disposition ("matches documented payroll pattern, see onboarding profile") is enough at this stage, a bare "closed — false positive" is not.

Investigation opens a case: pull the customer's profile and expected activity, the transaction history around the alert, counterparties, and anything from open sources your procedures call for. The question you are assembling evidence for is the s. 7 test — do the facts, taken together, give reasonable grounds to suspect a connection to ML, TF, or sanctions evasion? You are not trying to prove an offence; suspicion, reasonably grounded, is the standard.

Decision is a named person applying that test and writing down the answer. Three outcomes are normal: file an STR, close with a documented rationale, or close but adjust the customer's risk rating or monitoring intensity. If the suspected activity touches both ML/TF and sanctions evasion, FINTRAC's guidance is that one STR covering each suspected offence is filed — there is no separate sanctions-evasion report.

The STR timing rule is not in the Act — it sits in the Suspicious Transaction Reporting Regulations, SOR/2001-317, s. 9(2): the report must be sent as soon as practicable after you have taken measures that enable you to establish that there are reasonable grounds to suspect. That means the clock is tied to the completion of your assessment, not to the alert date — but it also means you cannot park alerts indefinitely, because "taking the measures" is itself expected to happen without unjustified delay. Timestamps on each stage (alert generated, case opened, decision made, report sent) are how you show the gap is investigation, not drift.

Keep the STR clock distinct from the fixed-deadline reports that the same monitoring data often triggers: an LCTR is due within 15 days of receiving CAD $10,000 or more in cash (PCMLTFR s. 132(3)), while an LVCTR is due within five working days — a common trip-up, as many teams assume the LCTR's 15 days applies — under PCMLTFR s. 132(2), and an EFTR within five working days of initiating or finally receiving an international transfer of $10,000 or more (s. 132(1)). Those are mechanical obligations; the STR is judgmental. A pipeline that treats them the same either files threshold reports late or STRs prematurely.

For MSBs and payment businesses, practical starting rules mirror the mechanical reporting triggers: cash or virtual currency at or approaching $10,000, aggregation patterns that would engage the 24-hour rules (PCMLTFR s. 126 for cash, ss. 127–128 for EFT initiation and final receipt, s. 129 for virtual currency), plus behavioural rules — velocity spikes against the customer's stated profile, structuring just under thresholds, rapid pass-through with no business rationale, and counterparties in higher-risk corridors. FINTRAC's 24-hour guidance frames three aggregation lenses — same conductor, same third party, same beneficiary — and each lens is assessed separately, which is worth reflecting in rule design so aggregated activity surfaces as an alert rather than being discovered at filing time.

False positives are managed by tuning, and tuning is managed by documentation. Every threshold change should have a record: what the rule caught before, what analysis supported the change, who approved it, and a back-test showing what the new setting would have missed. A rule quietly loosened to reduce queue pressure, with no record, reads very differently in a review than the same change supported by a tested rationale. Sample closed alerts periodically to confirm triage decisions hold up — that sampling is your evidence the noise you removed was actually noise.

A defensible case file lets a reader who was not there reconstruct the decision: the alert and the rule that generated it, the evidence gathered (transaction data, profile, notes of any customer contact), the analyst's reasoning against the s. 7 grounds, the named decision-maker, and dates for every step. The discipline matters most for no-file decisions — an STR speaks for itself, but a closed case is only as good as its written rationale. "Reviewed, no suspicion" is not a rationale; "flow is consistent with the documented import business, counterparties verified at onboarding, no structuring pattern across the 90-day lookback" is.

Two cautions on handling. PCMLTFA s. 8 prohibits disclosing that an STR has been, is being, or will be made — or its contents — with intent to prejudice a criminal investigation; the prohibition is conditioned on that intent rather than being a blanket confidentiality rule, but the operational practice it points to is the same: keep STR status out of customer-facing systems and on a need-to-know basis internally. And keep the escalation pipeline connected to your screening obligations — property of a listed or sanctioned person triggers a separate Listed Person or Entity Property Report under PCMLTFA s. 7.1(1), which replaced the former Terrorist Property Report with expanded scope covering sanctioned persons, and which FINTRAC's guidance says must be submitted immediately. For report field-level requirements, check the current FINTRAC guidance.