Custodial and Non-Custodial Wallets: FINTRAC Scope Questions

Founders tend to frame the scope question as "custodial versus non-custodial," as if the architecture label settles the regulatory answer. It does not. The PCMLTFA defines money services businesses by the services they provide — including dealing in virtual currency — under s. 5(h) for domestic businesses and s. 5(h.1) for foreign businesses directing services at persons in Canada. FINTRAC's MSB guidance applies that definition by looking at what the business actually does with client virtual currency: whether it exchanges it, transfers it, or holds and moves it on someone else's instruction.

That means two wallets with identical marketing can land on opposite sides of the line, and two wallets with different labels can land on the same side. The useful exercise is not naming your architecture; it is walking through the control points — custody of keys, ability to execute or block transfers, and who gives and receives transfer instructions — and documenting what you find.

A custodial wallet holds client virtual currency — the business controls the private keys — and moves that virtual currency when the client asks. Those two facts together are the classic control points of a virtual currency transfer service: the business has custody, and it executes transfers on client instruction. Under current FINTRAC guidance, a business offering that service to the public is dealing in virtual currency and generally needs to register as an MSB (or as a foreign MSB if it is outside Canada but directing services at Canadian clients).

Before concluding anything, review three things and write down the answers. First, who holds the keys — the business, the client, or some split arrangement such as multi-signature or MPC where the business holds a controlling share. Second, who can execute, delay, or reject a transfer — if the business's systems or staff can stop a withdrawal, the business controls the transfer. Third, whether client funds are commingled in omnibus wallets, which reinforces that the business, not the client, has custody. If the honest answers are "we hold keys, we execute transfers, funds sit in our omnibus wallet," the analysis points firmly toward MSB registration and the obligations that follow.

A non-custodial or software-only wallet — where clients hold their own keys and the business never touches the assets — removes some control points, and many pure self-custody tools do fall outside MSB scope. But "non-custodial" is a description of key management, not a regulatory conclusion. The business can still perform in-scope services around the wallet.

Before assuming no obligations, check each of these: Does the business exchange virtual currency for fiat or for other virtual currency anywhere in the flow — including through an integrated swap feature it operates rather than merely links to? Does it transfer virtual currency for clients, even briefly? Does it receive transfer instructions from clients and act on them? Does it route or initiate transfers — for example, constructing and broadcasting transactions on the client's behalf, or operating infrastructure that decides where funds go? Does it facilitate remittance, standing between a sender and a beneficiary? A "yes" on any of these means the non-custodial label alone does not resolve the question, and the specific service needs its own analysis against the MSB definition.

The common failure mode is treating the architecture as the conclusion: "we never hold keys, therefore FINTRAC doesn't apply." A wallet business that also runs an exchange feature, or that receives client virtual currency into its own address even momentarily before forwarding it, has reintroduced exactly the control points the non-custodial design was supposed to avoid.

The clearest in-scope pattern is receiving virtual currency in order to remit it to another beneficiary. A service that takes in a client's virtual currency and delivers value to someone else — a remittance corridor settled in stablecoin, a payout service that receives crypto and forwards it to workers' wallets — is providing a virtual currency transfer service. The sending/receiving relationship and who controls the transfer instructions drive the analysis: the client instructs, the business receives and sends, and the beneficiary is a third party.

Once a business is operating as an MSB dealing in virtual currency, a family of obligations follows: registration with FINTRAC, a compliance program under PCMLTFA s. 9.6 and PCMLTFR ss. 156–157 (compliance officer, policies and procedures, risk assessment, training, and a two-year effectiveness review), large virtual currency transaction reporting per FINTRAC's LVCTR guidance, record keeping, and the virtual currency travel rule under PCMLTFR s. 124.1 — including originator and beneficiary name, address, and account or reference number with a virtual currency transfer, and taking reasonable measures to ensure that information travels with it. The point at this stage is scope, not the full obligation set: settle whether you are in, then size the program.

Whatever conclusion the analysis reaches, it is worth writing down: a plain description of the product flow, who holds keys at each step, who can execute or reject transfers, whether client assets are ever in business-controlled addresses (and whether they are commingled), which features involve exchanging, transferring, routing, or remitting, and the reasoning that maps those facts to the MSB definition. Businesses that later face a FINTRAC question are in a far better position pointing to a dated scope memo than reconstructing the reasoning after the fact.

Product changes reopen the question. Adding a swap feature, a fiat on-ramp, a pay-someone-else function, or a managed-key recovery option can each add a control point that changes the answer. Treat the scope analysis as a living document that gets revisited when the product does — and when specifics matter, check the current FINTRAC guidance rather than relying on how the product was classified two versions ago.