Pre-Launch AML Checklist — and Reviewing Every New Feature

PCMLTFA s. 9.6 requires every reporting entity to establish and maintain a compliance program that is reasonably designed, risk-based and effective. PCMLTFR ss. 156 and 157 set out what that program must contain: an appointed compliance officer, written policies and procedures, a documented risk assessment, ongoing training, and a review of the program's effectiveness every two years.

That single obligation bites at two distinct moments in a product company's life. The first is before launch, when the program has to exist at all. The second is every product change after that — because a program that was reasonable for the product you launched is not automatically reasonable for the product you have now. Companies that handle this well treat both moments as one discipline: AML change control, applied first to the launch itself and then to every feature that follows.

Scope comes first: determine whether the business model makes you a reporting entity, and in which category. The money services business definitions are in PCMLTFA s. 5(h) — with s. 5(h.1) covering foreign businesses directing services at people in Canada — and if the analysis lands on yes, registration under PCMLTFA s. 11.1 comes before operating, not after. Scope is a facts-based question about fund flows, so write the analysis down: who holds funds, who instructs payments, and which activities belong to the business versus its providers.

With scope settled, the remaining items follow the program elements. Design controls against the actual product flows — onboarding identification, screening, transaction monitoring — rather than copying a generic policy. Map vendor dependencies honestly: if a KYC provider, screening vendor or banking partner performs part of a control, the obligation still sits with the reporting entity, so know what each vendor actually does and what evidence it can hand over. Train staff before they face live customers. Stand up the reporting workflow — how a reportable transaction is identified, how it reaches the compliance officer, how a report is filed with FINTRAC — and walk through it end to end while the stakes are still zero.

The last item is evidence planning: for each control, decide in advance what record it leaves behind and where that record lives. A control that produces no retrievable evidence is very hard to demonstrate later.

Retrofitting AML architecture after launch is usually harder and more expensive than building it in. An onboarding flow either captures the identification data your obligations require or it doesn't; a ledger either records transactions in a shape that supports reporting and retrieval or it doesn't. A payroll platform that briefly holds employer funds, for example, will find it far cheaper to structure its transaction records for retrieval before launch than to reconstruct them from raw database rows when a report or a FINTRAC request is due. Pre-launch is the one moment when the data model, the product flows and the compliance program can be designed together.

Once live, the same analysis applies to every material product change. Adding instant payouts, opening a new corridor, serving a new customer segment or introducing a stored balance can each change the AML risk profile — and sometimes the regulatory category itself. FINTRAC's risk-based approach guidance expects the risk assessment to reflect the products and services actually offered; a feature the risk assessment has never heard of is a gap, whatever the launch metrics say.

A workable launch review is short and repeatable. First, does the feature change what services the business provides? Re-check scope against current law, because the perimeter itself moves — cheque-cashing services are a prescribed MSB service under PCMLTFR s. 29.1, and new registerable categories continue to come into force. Second, does it change the risk assessment — new typologies, new customer exposure, new geographies? Third, which controls, procedures or training need updating before customers can use it? Fourth, compliance sign-off happens before the ship date, not after. For features with no plausible AML angle, the review can conclude in minutes; the point is that it happens every time.

Keep a dated record of each launch review: what was assessed, what changed in the risk assessment, which controls were updated, and who signed off. Even a conclusion of "no AML impact" is worth a short written record, because the absence of any record reads the same as the absence of any review.

This trail also feeds the two-year effectiveness review that PCMLTFR ss. 156 and 157 require. A reviewer asking whether the program kept pace with the product has an easy job when every material change carries its own documented assessment — and a slow, reconstructive one when it doesn't. Businesses that build the review habit early tend to find both the effectiveness review and any future FINTRAC examination far less disruptive.