The Two-Year Effectiveness Review — and What to Do with Findings

The Proceeds of Crime (Money Laundering) and Terrorist Financing Act requires every reporting entity to maintain a compliance program under PCMLTFA s. 9.6, and the regulations — PCMLTFR ss. 156 and 157 — set out its elements: an appointed compliance officer, documented policies and procedures, a risk assessment, training, and a review of the program's effectiveness at least every two years.

The effectiveness review is the element that checks all the others. Policies can be well written and still ignored; training can be delivered and not absorbed. The review exists to answer one question with evidence: does this program work in practice? A signed statement that it does is not a review — FINTRAC guidance frames it as a documented, planned test, and businesses that treat it as anything less tend to discover their gaps only when an examiner does.

A review that only re-reads the policy manual misses the point. The scope typically covers each program element as it actually operates: whether policies match what staff do day to day, whether the risk assessment still reflects the current business, whether training was completed and understood, whether reports were filed when they should have been, whether records exist and can be retrieved, whether know-your-client steps were performed on real files, whether monitoring caught what it was designed to catch, and whether issues found last time were actually fixed.

Scope should follow the business as it is today, not as it was when the program was written. A payments company that added a new remittance corridor or started briefly holding client funds has new exposure that the last review never touched — the review plan should say explicitly what is in scope and why.

In practice, an effectiveness review looks like light-touch audit work. It starts with a written plan: what will be tested, how, and against what standard. Testing then means pulling real artifacts — a sample of onboarding files checked against the identification procedure, a handful of transactions traced from alert to disposition, training records matched against the staff list, a filed report walked back to the underlying activity that triggered it.

Each test produces evidence: what was sampled, what was found, what passed and what did not. The output is a dated report with specific findings, kept with the program records. Who conducts the review varies by size of business — the key constraint is that the person testing should not simply be grading their own work; check the current FINTRAC guidance on compliance program requirements for what it expects here.

A finding that lives only in the review report is a finding waiting to be re-found two years later. Issue management is the discipline of turning findings into tracked remediation. Each issue gets a severity (how much exposure it creates), a root cause (why it happened, not just what happened), a named owner, and a due date. "Five onboarding files missing an identification record" is a symptom; the root cause might be a form that lets staff skip a step, and the remediation is fixing the form — plus repairing the five files.

This applies to findings from any source, not just the biennial review: gaps surfaced by staff, by a bank partner's questionnaire, or by day-to-day operations all belong in the same log.

An issue is closed when someone can show it is fixed — not when the due date passes. Closure evidence is concrete: the corrected files, the updated procedure with its revision date, the re-run sample showing the gap no longer recurs. Someone other than the owner — typically the compliance officer — reviews that evidence and approves closure, and the approval is recorded.

The log should let anyone trace a finding from the original review, through remediation, to closure evidence and sign-off. That traceability is what turns "we found problems" into a demonstrable record that the program corrects itself — which is much of what the next review, and any examination, will look for.

Two years is the outer bound, not a schedule to coast on. A major change — a new product line, a new customer segment, an acquisition, a shift into virtual currency — changes the risk the program was built around. Businesses commonly plan an interim review of the affected areas rather than waiting for the clock, and document that decision either way. A short, targeted review after a big change is far cheaper than discovering at the full review that a year of activity ran through untested controls.