FINTRAC Travel Rule: EFT and Virtual-Currency Transfer Checklist

What the travel rule requires—and what it does not

The FINTRAC travel rule concerns the information accompanying electronic funds transfers (EFTs) and virtual-currency transfers. For an MSB, a successful settlement is not enough: the required information must also move through the transaction chain. Information received under the travel rule cannot be removed from a transfer. FINTRAC states that the travel rule is not a separate recordkeeping requirement, although fulfilling it supports related recordkeeping and reporting duties.

This Canada MSB editorial checklist translates FINTRAC’s guidance into operational questions for payment and crypto teams. The control examples below are implementation suggestions, not additional regulator-prescribed steps. Use the linked primary sources to establish the requirements for your actual activity; this guide does not replace legal advice or FINTRAC’s guidance.

Classify the transfer before applying a threshold

FINTRAC’s travel-rule guidance uses EFT to mean international EFTs and EFTs within Canada sent through a SWIFT MT-103 message or its equivalent. Do not read that definition as every domestic electronic payment. For initiation, the guidance requires travel-rule information for an EFT for which an EFT record must be kept. Assess the recordkeeping trigger and any applicable exceptions using the MSB recordkeeping guidance, rather than using a reporting threshold as a substitute.

For virtual currency, FINTRAC states that MSBs must include the required information when sending transfers, and take reasonable measures to ensure it is included when receiving transfers that require a virtual-currency record. Identify your role—sender, receiving intermediary or final recipient—before selecting the control. An exchange transaction, a customer’s fiat deposit and an external virtual-currency transfer should not all inherit one generic compliance setting.

The travel rule, identity verification, transaction records and reports are separate obligations. A rule about when a report must be filed does not by itself answer what information must accompany a transfer. This checklist deliberately does not use a universal dollar threshold: consult the relevant recordkeeping, identification and reporting guidance for each leg.

• Record the asset, payment rail, origin and destination, and the entity performing each transfer step.
• Identify whether the business initiates, receives or passes on the transfer.
• Document the applicable recordkeeping trigger and its source separately from reporting and identification triggers.
• Escalate uncertain classifications rather than treating an unfamiliar rail as automatically exempt.

Outgoing EFTs: check the originator and beneficiary fields

For a covered outgoing EFT, FINTRAC lists the originator’s name, address and account number or other reference number, if any; the beneficiary’s name and address; and the beneficiary’s account number or other reference number, if applicable. The originator is the person or entity who requested the transfer. The conditional account/reference fields should not be confused with the required name and address fields.

Map these requirements to the actual outbound message—not just the customer profile or an internal ledger. A complete onboarding record can coexist with an incomplete payment message. Test whether names and addresses survive field mapping, message-length limits, provider transformations and retries. Keep an explicit distinction between a field that is not applicable and a field that staff or a supplier failed to collect.

• Compare the stored originator details with the outbound payment payload.
• Check beneficiary name and address, plus account or reference details where applicable.
• Test long names, address formatting and any transformation performed by a payment partner.
• Identify who owns correction of incomplete or truncated outbound information.

Virtual-currency transfers: a wallet address is not the whole data set

For virtual-currency transfers, FINTRAC lists the name, address and account number or other reference number, if any, of both the originator and the beneficiary. A blockchain transaction hash or wallet address alone does not supply the names and addresses in that list. Check what your transfer process actually communicates, rather than assuming an on-chain transaction contains all required information.

Separate settlement status from information-exchange status. If a transfer provider, counterparty or data channel fails, the team should be able to identify which information was sent, received or remains missing. Linking the information exchange to the correct transfer is a practical control; it avoids attaching one customer’s details to another transaction after a retry or batch-processing error.

Do not infer an exemption solely because a wallet is described as self-hosted. Assess the actual transfer and the applicable guidance. This guide does not provide a blanket conclusion about every wallet arrangement or prescribe a particular protocol or vendor.

• Check originator and beneficiary names and addresses, with account/reference details where present.
• Confirm how the information exchange is associated with the correct transfer.
• Test data-channel failures independently of blockchain settlement failures.
• Assign an owner to counterparty enquiries and unresolved information gaps.

Receiving and intermediary teams have their own duties

For EFTs, FINTRAC requires reasonable measures to ensure travel-rule information is included when an MSB receives a transfer, either as an intermediary or final recipient. When forwarding an incoming or outgoing EFT after receiving it as an intermediary, the MSB must include the information it received or obtained through reasonable measures. Receiving the payment is therefore not the end of the assessment, and forwarding it should not discard information already obtained.

A useful implementation check is to compare the incoming message, any subsequently obtained information and the outgoing message. Investigate dropped fields and overwritten values. Where different teams handle receipt, enquiries and onward processing, define a handoff that preserves the information and the unresolved issue—not merely the settlement instruction.

Missing information: obtain, assess, then apply the written policy

If a received EFT or virtual-currency transfer should include travel-rule information but does not, FINTRAC requires reasonable measures to obtain it. Those measures should be outlined in your policies and procedures. A practical workflow can identify the missing fields, direct an enquiry to the appropriate party, assign responsibility and record the response or lack of response. These are suggested ways to make the process accountable; FINTRAC’s cited guidance does not set a universal enquiry deadline.

If reasonable measures do not obtain the information, FINTRAC requires written, applied risk-based policies and procedures. They must address when the business allows, suspends or rejects the transaction, and the follow-up measures it will take. This is not a blanket instruction to reject every incomplete transfer, nor permission to allow every transfer because an enquiry was sent.

For each unresolved case, retain a usable explanation of the information gap, measures taken, relevant risk factors, decision and follow-up. Suggested risk considerations include repeated missing data from the same counterparty and inconsistency with the customer’s known activity. Do not present these editorial examples as an exhaustive FINTRAC checklist. Assess any separate reporting obligation independently.

• Identify the required information that is missing or incomplete.
• Apply the reasonable measures described in the business’s procedures.
• If the gap remains, apply the written risk-based allow, suspend or reject criteria.
• Record the decision owner, rationale and follow-up action.
• Preserve information already received if the transfer is passed onward.

Test failure cases, not only a successful transfer

Run controlled tests for an outgoing EFT with a truncated address, an incoming transfer missing beneficiary information, a virtual-currency transfer whose data exchange fails, and an intermediary flow that drops an originator field. These are operational test scenarios, not examples establishing a particular legal outcome. The expected result should follow your documented scope assessment and risk-based policy.

For each test, check that the team detects the gap, can retrieve the relevant transfer information, applies the right procedure and records the decision. Re-test after changing a payment rail, supplier, field mapping or counterparty arrangement. A vendor’s claim to support the travel rule does not demonstrate that your configured workflow preserves the required information.

• Keep a transfer-type matrix with the source and responsible owner for each obligation.
• Maintain field mappings for both incoming and outgoing information.
• Assign enquiry, escalation and transaction-decision responsibilities.
• Retain test results and verify that identified defects are corrected.