Escalation Policy — and Procedures Someone Can Actually Operate

The compliance-program obligation is concrete, not aspirational. PCMLTFR s. 156(1) requires a reporting entity to (a) appoint a compliance officer, (b) keep written compliance policies and procedures up to date, (c) document a risk assessment, (d) maintain a written ongoing compliance training program for employees, agents or mandataries and others authorized to act on its behalf, (e) institute and document a training plan and actually deliver the training, and (f) institute and document a plan for a compliance-program effectiveness review. Under s. 156(3), that review must be carried out — and its results documented — every two years by an internal or external auditor.

Notice what is missing from a one-line procedure like "we review transactions": it names no owner, no trigger, no deadline, no decision rule, and no record. Each of those gaps is something the written-procedures requirement in s. 156(1)(b) exists to close, and each is something a reviewer conducting the two-year effectiveness review will look for. The practical test for any procedure: could a competent new hire, on their first day, follow it without asking anyone what it means?

An escalation policy is a decision map. It answers three questions for every alert type your business generates: who looks first, who decides, and by when. A common three-tier structure for a small payments or remittance business: front-line staff or an automated rule flags an event and records what they saw; a designated reviewer (often the compliance officer in a small firm) assesses it against documented criteria within a stated number of business days; and the compliance officer — the person s. 156(1)(a) requires you to appoint — owns the final decision on regulatory outcomes such as whether to file a report, exit a relationship, or apply enhanced measures.

The policy should also name deputies and deadlocks: who decides when the compliance officer is away, what happens when the reviewer and the compliance officer disagree, and which decisions can never be delegated below the compliance officer. Write the escalation triggers as observable facts ("customer refuses to explain source of funds after two requests") rather than judgments ("customer seems suspicious"), so different staff escalate the same situations the same way.

Every escalation decision — including the decision not to escalate further — should leave a record: what was reviewed, what was decided, by whom, on what date, and why. Records kept under the Regulations generally carry a five-year retention period under PCMLTFR s. 148(1), with s. 148(1)(c) — five years from the day the record was created — as the default for decision records like these, and s. 149 requires records to be kept so they can be produced within 30 days of a FINTRAC examination request under s. 62 of the Act.

A procedure needs five elements: trigger, owner, steps, deadline, and record. Compare "we review transactions" with: "When the system flags a transfer of $1,000 or more with a mismatch between sender name and account name, the on-duty analyst opens a case the same business day, checks the elements listed in section 4.2, and either closes with a written rationale or escalates to the compliance officer within two business days." The second version can be operated, audited, and improved; the first cannot.

Anchor procedures to the record obligations your business already carries, so the procedure and the record requirement reinforce each other. For an MSB, that means the large cash transaction record at $10,000 or more (PCMLTFR s. 31), the large virtual currency transaction record at $10,000 or more (s. 32), EFT records at $1,000 or more for initiation, intermediary sending and final receipt (s. 36(d)–(f)), and virtual currency transfer records at $1,000 or more (s. 36(g), (h)). A procedure that says who compiles each record, from which system, and where it is stored is far easier to keep current than a generic monitoring narrative — and s. 156(1)(b) requires you to keep it current, not just to have written it once.

The training obligation in s. 156(1)(d) and (e) is role-blind on its face — it covers employees, agents or mandataries, and anyone else authorized to act on your behalf — but effective training is role-specific. Front-line and support staff need recognition and routing: what unusual behaviour looks like in your product, the exact escalation channel, and the rule against tipping off a customer that they are being reviewed. Operations and engineering staff who touch transaction systems need the record thresholds their systems must capture and the retention consequences of deleting or purging data early. Reviewers and the compliance officer need decision-quality training: applying the documented criteria consistently and writing rationales that stand up two years later.

Because s. 156(1)(e) requires the plan to be documented and the training delivered, keep evidence: dated attendance or completion records, the materials used, and the version of the procedures the training was based on. When your procedures change, the training program is required to be kept up to date along with them — the two documents should share a change log.

A new hire at a fintech should leave onboarding able to do four things: describe what the business is registered or regulated to do and which obligations follow from that; recognize the escalation triggers relevant to their own role; use the escalation channel — the named person or queue, not "tell someone"; and understand that they must never alert a customer to an internal review or report. Keep the day-one module short and operational, and defer depth to the annual role-based cycle.

One retention point worth teaching early, because it reassures staff: under PCMLTFR s. 148(2), individuals are generally relieved of personal retention obligations after their employment or contract ends where the records belong to the employer — the retention duty follows the business, not the departing employee. For anything your program design leaves open — such as exactly how FINTRAC expects effectiveness-review findings to be reported internally — check the current FINTRAC guidance on compliance programs rather than improvising.