The Virtual Currency Travel Rule in Practice (PCMLTFR s. 124.1)

The virtual currency travel rule sits in section 124.1 of the PCMLTFR. When a reporting entity sends a virtual currency transfer, it must include prescribed information about the originator and the beneficiary — name, address, and an account number or reference number for the transfer — and take reasonable measures to ensure that information is included with the transfer. FINTRAC's travel rule guidance sets out how the requirement applies on each side of a transfer and what reasonable measures can look like in practice.

Two things follow from that wording. First, the obligation is about information moving with the transfer itself, not a report filed afterwards — the travel rule is distinct from large virtual currency transaction reporting, which is a separate obligation with its own FINTRAC guidance. Second, 'reasonable measures' is a real standard: it expects a documented, genuine attempt to obtain and pass the information, not a guarantee that every counterparty will always supply complete data.

A common way this rule gets mis-built is as a dollar-threshold rule: someone on the team recalls a number, engineering hard-codes it, and originator information only attaches above the line. The safer starting point is the text of section 124.1 and FINTRAC's current travel rule guidance, which define which transfers qualify and exactly which fields must travel. Thresholds elsewhere in the regime — record-keeping triggers, reporting triggers — are separate questions under separate provisions. When a number is quoted from memory, the working answer is to check the current FINTRAC guidance, encode what it says, and note the guidance version in your procedures.

The travel rule is unusual among AML obligations in that it cannot be retrofitted with policy alone. If a transfer flow has no fields for originator and beneficiary details — or an integration with a counterparty platform silently drops them — no written procedure fixes that after the fact.

Design questions worth settling early: where the information is captured (onboarding data for the customer side, per-transfer entry for the beneficiary side); how it travels (inside the transfer message, through a travel-rule messaging solution, or by a documented parallel channel); and what happens when the destination is an unhosted wallet or a platform that cannot receive the data. A product that batches customer withdrawals into pooled on-chain transactions has an extra question to answer: how originator information maps to each underlying transfer within the batch.

The day-to-day test of a travel-rule control is what happens when originator or beneficiary information arrives incomplete. A workable playbook has four stages. Detect: validation that flags missing or obviously malformed fields at or before settlement, not a report someone runs weeks later. Decide: a defined choice — hold, execute with follow-up, or refuse — made under risk-based procedures that weigh the counterparty, the corridor, and the customer's profile, by someone with authority to make it. Follow up: request the missing information from the counterparty or the customer, and record the response — including a non-response. Document: what was missing, what was done, who decided, and the outcome.

The escalation should connect to the rest of the program rather than dead-ending in a product flag. Repeated gaps from one counterparty are a counterparty-risk signal; gaps clustering on one customer belong in that customer's monitoring picture and may feed a suspicious transaction report decision. A flag that no human ever reviews is, functionally, no control.

Everything above generates records. FINTRAC's record keeping guidance for money services businesses sets out what must be kept for virtual currency transactions; the practical test is whether, for any given transfer, the business can retrieve what information travelled with it, what was missing, and what was done about the gap. Follow-up that was never written down is indistinguishable from follow-up that never happened.

Travel-rule handling also belongs inside the compliance program required by PCMLTFA s. 9.6 and PCMLTFR ss. 156–157: written policies and procedures that describe the playbook, training so front-line staff recognize a travel-rule gap when they see one, transfer flows reflected in the risk assessment, and the two-year effectiveness review testing whether detection and escalation actually fire on real transfers — not just whether the policy document says they should.