The Travel Rule for Cryptoasset Transfers: A Practical Guide
The travel rule is the obligation that most consistently separates cryptoasset businesses that can hold a banking relationship from those that cannot. It is also the one where compliance arrangements most often exist on paper while failing in the specific situations that matter.
This guide covers what the rule requires, the problems unique to cryptoasset transfers, and what a workable arrangement looks like at a firm that does not have a large financial crime team.
What the Rule Requires
In outline, a cryptoasset business transferring value on behalf of a customer must collect specified information about the originator and the beneficiary, transmit it to the receiving business, and hold it. The receiving business has corresponding obligations to receive, check and act on what arrives.
Our guide to customer due diligence at crypto firms covers the wider onboarding picture; this page deals with transfers.
The principle is borrowed from wire transfers in traditional payments, where information has travelled alongside value for years. The difficulty is that the underlying technology was not designed to carry it, which is where almost every practical problem originates.
The obligations sit within the broader anti-money-laundering framework under the Money Laundering Regulations 2017 and are supervised accordingly. The FCA’s cryptoasset pages set out its expectations of registered firms.
Why It Is Harder Than a Bank Transfer
Three features of cryptoasset transfers create problems that have no equivalent in conventional payments.
The information does not travel with the value. A blockchain transaction carries addresses and amounts, not names and account details, so the required data has to move through a separate channel between the two businesses. That requires both sides to be using a compatible mechanism, and there is no single universal one.
The counterparty may not be a business at all. Transfers to and from self-hosted wallets involve no receiving institution, which means there is nobody to send information to and nobody performing checks at the other end.
Identifying the counterparty business is itself work. Before sending anything, the firm has to establish who controls the receiving address and whether they are a regulated business capable of receiving the data — a step that does not exist when sending to a sort code and account number.
Self-Hosted Wallets
This is the area where firms most often have a policy that does not survive contact with their actual customer base.
Where a transfer involves a wallet not controlled by a regulated business, the firm cannot transmit information to a counterparty because there is none. What it must do instead is collect the required information about its own customer and apply risk-based measures to establish who controls the wallet at the other end.
Firms commonly adopt one of three positions: declining self-hosted transfers entirely, permitting them with ownership verification, or permitting them below a threshold with enhanced scrutiny above it. Each is defensible. What is not defensible is a policy that permits them in principle with no mechanism to establish control of the wallet.
Ownership verification approaches vary — signed messages, micro-transfers, screenshots with liveness checks — and each has weaknesses. The firm should understand the weakness in whichever it uses and reflect that in its risk assessment rather than treating verification as binary.
Blockchain Analytics and Screening
Travel rule compliance sits alongside, and does not replace, screening of the addresses themselves.
Analytics tools assess whether an address is associated with sanctioned entities, darknet activity, mixers or other higher-risk sources. That assessment is a separate control from the information exchange, and firms sometimes conflate the two — treating a clean analytics result as satisfying the travel rule, or a successful information exchange as removing the need to screen.
Our guide to sanctions screening covers the screening discipline more generally; the cryptoasset-specific point is that addresses, counterparties and customers all need screening, and they are three different exercises.
What to Do With Incoming Transfers
Receiving obligations receive less attention than sending ones and are equally real.
Where a transfer arrives with information missing or incomplete, the firm has to decide what to do: ask the sending business, hold or reject the transfer, or accept it and record the deficiency. That decision should follow a documented policy rather than being taken case by case by whoever notices.
Repeated deficiencies from the same counterparty are a finding in themselves. A firm that keeps accepting incomplete data from one sender, without escalating or reconsidering the relationship, has identified a problem and not acted on it.
Record Keeping
Information collected and transmitted must be retained, and in practice the retention is the part that fails quietly.
Where the exchange happens through a third-party solution, firms should establish early whether they can export their own records independently of that provider, and what happens if the relationship ends. A compliance record that exists only inside a vendor platform is a dependency rather than a record.
Thresholds and Proportionality
Firms frequently ask whether small transfers are exempt. The safer working assumption is that the information obligations apply broadly, with the scope of verification scaling to risk rather than switching off below a figure.
Where a firm operates a threshold-based approach, two things need to be true. The threshold must be justified by the firm’s own risk assessment rather than copied from a competitor, and there must be controls against structuring — a customer making repeated transfers just below a threshold is a pattern the firm should be detecting rather than one its policy inadvertently encourages.
This is an area where monitoring rules and travel rule policy need to be designed together. A threshold set in policy with no corresponding monitoring rule is an invitation that nobody is watching.
Getting It Right Before Registration
For firms seeking registration or authorisation, travel rule arrangements are examined rather than assumed.
Applications are materially stronger where the firm can describe the specific mechanism it will use, name the counterparty identification approach, state its self-hosted wallet position with the reasoning behind it, and show how incoming deficiencies will be handled. Applications that describe the obligation in general terms, without saying what the firm will actually do, invite questions that extend the timetable.
Our guides to cryptoasset FSMA authorisation and MLR registration versus FSMA authorisation cover how the two routes differ.
Who Owns It
Travel rule arrangements sit with the MLRO as part of the firm’s wider financial crime framework.
The hiring consequence is specific. An MLRO who has run financial crime at a conventional payments business is not automatically equipped for this — the concepts transfer, the practical problems do not. Firms recruiting in this space should test candidates on self-hosted wallet policy and counterparty identification rather than on general AML knowledge, because that is where the difference shows.
Our guide to the crypto MLRO role covers the wider remit, and SMF16 and SMF17 for cryptoasset firms covers the appointment side.
Where Firms Actually Fail
Four patterns recur in review.
A policy that describes the rule without describing the firm’s own mechanism — which solution is used, how counterparties are identified, what happens when data is missing. A self-hosted wallet position with no verification method behind it. No evidence of incoming transfers being checked, only outgoing ones. And no record of decisions where a transfer was accepted despite deficient information.
All four are documentation failures rather than conceptual ones, which is why they are fixable without significant expenditure — and also why they look careless when found.
Frequently Asked Questions
Does the rule apply to transfers between a customer’s own accounts?
Transfers between a customer’s own wallets still involve establishing who controls the receiving address. The firm’s policy should address this scenario explicitly rather than leaving it to inference.
What if the receiving business does not use a compatible solution?
The firm still has to meet its obligations. In practice that means either an alternative transmission method, declining the transfer, or accepting it with documented risk-based measures.
Is a clean analytics result enough?
No. Screening and the travel rule are separate obligations addressing different risks, and satisfying one says nothing about the other.
Can we simply block all self-hosted wallet transfers?
Yes, and some firms do. It is a commercial decision rather than a regulatory requirement, and it should be recorded as a deliberate risk decision rather than applied informally.
Hiring an MLRO?
We place the people who own this function
MLROs and deputy MLROs on a permanent, fractional and interim basis across payments, lending, wealth and cryptoasset firms. Tell us about the volumes and the risk profile.
Related guides and services
Practice area
Cryptoasset firms
About the author
Adrian Lawrence FCA
Adrian is the founder and Managing Director of FD Capital. A Chartered Accountant and ICAEW Fellow, he became a finance director at 28 and has spent more than 25 years at C-suite level, including as finance director of a listed company and of a private equity backed management buy-out. Every search is run by our specialist team, with Adrian overseeing each mandate.
Start a search
Tell us about your finance hire
Share a few details about your business and the role. A member of our team will review your brief and come back to you to talk it through.
- Reply within one working day, from a consultant who places finance leaders every day
- Confidential from the first conversation, with no obligation to go ahead
- Shortlists typically within three to seven days, faster for urgent interim cover
Your details are used only to respond to your enquiry.
Accredited Member of GBC
Accredited Member of LWF
Carbon Offset via TreeNation