Stablecoins and FINTRAC Scope: Practical Questions

Canadian AML law does not have a separate category for stablecoins. The Proceeds of Crime (Money Laundering) and Terrorist Financing Regulations define "virtual currency" in s. 1(2), and the definition is functional: it looks at what the asset is and what it can do — a digital representation of value that can be used for payment or investment purposes and that is not a fiat currency issued by a country. Marketing language, the issuer's reserve model, and the token's price behaviour are not part of that test.

A token pegged to the Canadian or US dollar is still issued by a private party, not by a central bank. However tight the peg, the token itself is not fiat currency. On a plain reading of the definition, most fiat-referenced and asset-backed stablecoins sit inside the virtual currency definition, and the analysis for a business handling them proceeds exactly as it would for any other virtual currency.

The instinct to treat a stablecoin as "digital dollars" is understandable — that is how the product is designed to feel to users. But FINTRAC obligations attach to the legal character of the asset and the service performed, not to the user experience. A transfer of a CAD-pegged token is a virtual currency transfer, not a funds transfer, and it picks up the virtual-currency-specific rules rather than (or in addition to) the fiat ones.

This matters operationally because the virtual currency rules have their own reporting forms, record fields, and transfer-information requirements. A business that scopes a stablecoin as if it were fiat will typically build the wrong reporting pipeline: right intent, wrong form, missing fields. The safer starting position is to treat any fiat-referenced token as virtual currency unless a careful, documented analysis of the specific token concludes otherwise.

Dealing in virtual currency is a money services business activity under PCMLTFA s. 5(h)(iv), and under s. 5(h.1)(iv) for foreign businesses directing those services at persons in Canada. In FINTRAC's framework, dealing includes virtual currency exchange services (fiat-to-stablecoin, stablecoin-to-fiat, and crypto-to-crypto swaps that include a stablecoin leg) and virtual currency transfer services carried out on behalf of clients.

Applied to common models: a platform that lets Canadian users buy a USD-pegged token with dollars is offering exchange; a wallet or payments product that moves a stablecoin from one person to another at a client's request is offering transfers; a cross-border payout product that accepts fiat and delivers a stablecoin to the recipient combines both. Registrable MSBs must register with FINTRAC under PCMLTFA s. 11.1 before operating, and the foreign-MSB limb means having no Canadian entity does not, on its own, keep a stablecoin platform out of scope.

Once stablecoin activity makes a business an MSB, the virtual currency obligations apply with full force. Large virtual currency transaction reporting applies to receipts of virtual currency above the reporting threshold — check the current FINTRAC LVCTR guidance for the threshold and the aggregation rules, and note that a "stable" price does not mean transactions stay small.

The virtual currency travel rule in PCMLTFR s. 124.1 applies to stablecoin transfers: when sending a virtual currency transfer, the business must include originator and beneficiary information — name, address, and account or reference number — and take reasonable measures to ensure it travels with the transaction. This is an information requirement on transfers, not merely a threshold-triggered report. Record keeping for virtual currency exchange and transfer transactions applies as set out in the PCMLTFR, and the whole activity must be covered by the compliance program required by PCMLTFA s. 9.6 and PCMLTFR ss. 156–157: a compliance officer, policies and procedures, a risk assessment that actually addresses the stablecoin products, training, and a two-year effectiveness review.

For each token handled, businesses typically keep a short scoping memo: what the token is (issuer, peg, redemption mechanics), which services the business performs with it (exchange, transfer, holding client balances), the conclusion on whether it is virtual currency and why, the date, and who signed off. When the analysis lands in scope — as it usually will — the memo should map each service to the reporting, record-keeping, and travel-rule workflows that cover it.

Set a review trigger: if the token's design changes (a new redemption structure, a change of issuer, a shift from asset-backed to algorithmic), or if the business adds a new service such as holding balances for clients, the scoping analysis gets redone rather than assumed. A payroll platform that briefly holds employer funds in a stablecoin before payout, for example, has a different service profile than one that only quotes conversions — and the documentation should show that the difference was noticed and analysed.