The Travel Rule for crypto explained

For decades, banks have had to attach sender and recipient details to wire transfers so money cannot move anonymously through the system. Crypto initially sidestepped that — not by design, but because the rules predated it.

The Travel Rule closes the gap. FATF Recommendation 16 carries the underlying principle, that information travels with the transfer, and Recommendation 15 with its interpretive note extended the standard to virtual assets and to the businesses that handle them.

The principle takes a sentence. Implementation is where the work is, because jurisdictions adopted it years apart, with different thresholds and different data sets, and the technology to move the data between institutions was largely built after the obligation already existed.

What has to travel

On a qualifying transfer, the sending institution must transmit to the receiving institution:

About the originator — name; account or wallet identifier; and, depending on the regime, a physical address, national identity number, customer identification number, or date and place of birth.

About the beneficiary — name; and account or wallet identifier.

The information must be transmitted securely, and it must accompany the transfer. It does not go on-chain: a public ledger is the wrong place for customer identity data, and putting it there would create a data-protection problem considerably larger than the one it solved. It moves through a separate messaging channel between the two institutions.

The receiving institution is not a passive recipient. It must check the data is present and complete, screen the named parties, and hold a policy for what to do when information is missing — which, in practice, it often is.

Thresholds differ, and assuming yours is the common one is a real risk

This is the most consequential difference between regimes, and it is routinely misconfigured.

Regime	Threshold for full information
FATF standard	Permits a de minimis of USD/EUR 1,000; below it, reduced information may be sent without verification
European Economic Area	No threshold for crypto-asset transfers — full information travels regardless of value, under the Transfer of Funds Regulation
Canada	CAD 1,000 for virtual currency transfers, under the PCMLTFA regime
United Kingdom	£800 since 30 June 2026, when the thresholds were redenominated into sterling (SI 2026/621). It was previously €1,000 — it was never £1,000, a figure that appears widely and has never been correct

The EEA position deserves emphasis, because it is the one that surprises people. The EU deliberately declined to adopt the FATF de minimis for crypto-asset transfers. A system configured to a USD 1,000 threshold and pointed at EEA flows is not partially compliant — it is non-compliant on every transfer below that threshold.

The two problems nobody has fully solved

The sunrise problem

Jurisdictions turned the rule on at different times, and some still have not. A compliant business therefore transacts routinely with counterparties that have no obligation to receive Travel Rule data, and sometimes no technical means of doing so.

Your obligation does not soften because theirs has not arrived. What is expected instead is that you attempt transmission, record the outcome, and treat a counterparty’s inability to receive as a risk factor feeding your own assessment — rather than as a reason to stop asking.

Unhosted wallets

Where the counterparty is a self-custodied wallet there is no institution to send data to, and the rule cannot operate in its normal form.

Regimes diverge here more than anywhere else. The common shape is that the regulated side collects and retains beneficiary information itself, applies risk-based measures to the transfer, and above defined values takes further risk-based steps regarding the destination address.

The precise standard is worth getting right, because the wrong version is everywhere. Under the EU Transfer of Funds Regulation (Articles 14(5) and 16(2)) a CASP must assess whether the customer controls a self-hosted address — not verify it. A lot of vendor content says verify, and that overstates what the law requires. Transfers to self-custodied wallets are not prohibited and are not unregulated — they are handled differently, and your policy has to say how.

What it means operationally

• You need a way to collect, transmit, receive and store the data set for every qualifying transfer, in a channel separate from the chain itself.
• You need due diligence on the institutions you exchange data with. Sending customer identity data to an entity you have not assessed is its own problem, distinct from the laundering risk the rule addresses.
• You need a documented policy for incoming transfers with missing or incomplete data — accept, hold, return or report — applied consistently. Inconsistency here is exactly what supervisors find.
• It runs alongside the rest of the AML programme, not instead of any part of it. Travel Rule data feeds screening and monitoring; it does not replace them.
• Done properly it is invisible to the customer, who simply sees a transfer that settles.

How KwiikPay handles it

KwiikPay is a trading name of KWP Finance Limited, registered in Canada as a Payment Service Provider under the Retail Payment Activities Act, supervised by the Bank of Canada, and as a FINTRAC-registered Money Services Business including dealing in virtual currency.

The Travel Rule is built into the stablecoin settlement rail rather than bolted onto it: qualifying transfers carry the required originator and beneficiary information, parties are screened on both sides, and incoming transfers with incomplete data follow a documented policy rather than an analyst’s judgement on the day. The detail is on the Travel Rule compliance page.

The practical value for a regulated business is that the plumbing already exists. If you are an authorised CASP or a registered firm elsewhere, talk to us about how transfers are handled before committing to build it yourself.