Travel Rule Workflows for Crypto Exchanges

A crypto exchange does not move value in isolation. Every withdrawal to another platform, and every deposit from one, is a transfer between institutions, and supervisors now expect information about the people behind them to travel with the assets. The travel rule — the international standard under which sending and receiving institutions exchange identifying information about the originator and beneficiary — has applied to crypto-asset transfers in the United Kingdom since September 2023 and in the European Union since the end of 2024. For an exchange it is neither optional nor new.

The rule is simple to state and demanding to operate. An exchange sending a customer’s assets to another provider must attach specified information about its own customer and the intended recipient; one receiving assets must obtain and check the equivalent information before releasing the funds. Doing this reliably, at the speed customers expect and across thousands of counterparties in varying states of readiness, is an engineering and operational problem as much as a compliance one.

This article sets out what the rule asks of an exchange, how a workflow is built around outgoing and incoming transfers, how counterparty readiness and self-hosted wallets complicate it, and how UK and EU expectations shape the design — at the level of concept, process and high-level architecture, not a recipe for a messaging protocol.

What the Travel Rule Requires of an Exchange

The travel rule requires the provider that initiates a crypto-asset transfer and the one that receives it to exchange identifying information about the parties, so that neither end is anonymous to the institutions handling it. The originating exchange transmits information identifying its own customer, the sender, with what it holds on the beneficiary; the receiving exchange obtains it, checks it for completeness and consistency, and feeds it into its financial-crime controls. Because the obligation builds on the customer identification an exchange already performs, the capability is best designed alongside KYC verification and AML screening rather than added afterwards.

Exactly what must be sent, and when it must be verified, differs by jurisdiction and by the nature of the transfer, and this article does not restate any rulebook. The design point is constant: the exchange must produce accurate originator and beneficiary information for an outgoing transfer, and receive, validate and act on it for an incoming one — for every transfer in scope, without manual effort at the moment a customer clicks withdraw.

The Core Travel Rule Workflow

A travel-rule workflow has two mirror-image paths, and a good design treats them as first-class parts of the withdrawal and deposit flows. On the outgoing path, when a customer requests a withdrawal to another provider, the exchange decides whether it is in scope, identifies the receiving institution, assembles the required originator and beneficiary information, and transmits it through a channel both sides can use. On the incoming path, it receives the accompanying information, checks it is present and coherent, screens it against sanctions and risk criteria, and decides whether to credit, hold or query the transfer.

The two paths share a dependency: for a given blockchain address, the exchange must tell whether the counterparty is another regulated institution or a self-hosted wallet, because the handling differs sharply. The table below summarises the responsibilities; precise data and verification expectations vary by jurisdiction.

Counterparty VASPs and the Sunrise Problem

An exchange cannot exchange information with a counterparty it cannot identify or reach, and two practical problems follow. The first is identification: from a blockchain address alone, the exchange must work out whether it belongs to another regulated provider — a virtual asset service provider, or VASP — and, if so, which one and in which jurisdiction, which determines the applicable rules. The second is reachability: even when the counterparty is known, both sides need a shared, secure way to transmit the information, so interoperability between industry messaging solutions matters as much as any single tool.

The uneven pace of adoption worldwide creates what the industry calls the sunrise problem: the standard came into force in different places at different times, so an exchange routinely faces counterparties not yet subject to it, or unable to receive travel-rule data, so a workable design defines how the exchange behaves when information cannot be exchanged — collecting and retaining what it can, applying a risk-based decision to proceed, hold or decline, and recording the rationale — so gaps in the wider network do not become gaps in the exchange’s own controls.

Transfers Involving Self-Hosted Wallets

Not every transfer is between two institutions. Customers deposit from, and withdraw to, wallets they control themselves — self-hosted, or “unhosted”, wallets — which fall outside the institution-to-institution model the travel rule assumes. There is no counterparty provider to exchange information with, so the obligation changes shape: instead of transmitting data to another institution, the exchange collects the relevant information from its own customer about the wallet and, depending on the jurisdiction and value involved, takes steps to satisfy itself that the customer controls it.

This makes self-hosted-wallet handling a distinct branch of the workflow, not an exception worked by hand. The exchange needs to recognise when a counterparty address is likely self-hosted rather than institutional, capture the additional information its regime requires, and establish control of the wallet where that is expected — all within the same flows customers already use. Designing this path deliberately keeps a large, legitimate category of transfers from becoming a compliance gap or constant friction.

Data Protection and Record-Keeping

The travel rule moves personal data between institutions, and doing that lawfully is inseparable from doing it at all. Every message contains identifying information about real people, so an exchange must transmit and store it securely, limit it to what is required, and hold it under the same data-protection discipline as the rest of its platform. Building the workflow without a clear view of where this data goes, who can see it and how long it is kept turns a financial-crime control into a data-protection risk.

Record-keeping is the other half. An exchange must be able to show, after the fact, what information was sent or received for a given transfer, what checks were run, and why it was released, held or declined. That evidence supports sanctions and AML screening and is what a supervisor or auditor will ask to see. Treating travel-rule records as first-class audit evidence, retained and retrievable, lets an exchange show that the control works, not merely that it exists.

UK and EU Expectations

For an exchange serving UK and EU customers, the travel rule is settled law, not a future project. In the United Kingdom it has applied to cryptoasset transfers since September 2023, implemented through the money-laundering rules and supervised by the FCA, which has set out how it expects firms to collect, verify and share the required information. Registration under that regime is not, by itself, authorisation for the wider activities an exchange may undertake, and the incoming UK cryptoasset regime is expected to build on these obligations rather than replace them — where the design meets UK regulatory readiness.

In the European Union the information requirements apply to crypto-asset transfers from the end of 2024, without the low-value exemption used for some traditional transfers, and within the authorised-CASP environment set by the wider framework. The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning. The boundary of what a technology partner provides should be stated plainly. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations. Which transfers fall in scope, and what must be sent and verified, are matters for qualified advisers; the engineering task is to make the exchange able to meet them consistently, as part of EU regulatory readiness.

Building, Buying and Integrating the Capability

Few exchanges build travel-rule messaging from scratch: the value lies in reaching the largest possible set of counterparties, and reach depends on shared solutions and interoperability rather than a bespoke channel. The realistic choice is which capability to adopt and how to integrate it, against practical criteria — the counterparties it reaches, how it handles identification and the sunrise problem, how cleanly it fits existing withdrawal, deposit, KYC and screening flows, and where the personal data it carries is processed. Integration decides the outcome: travel-rule handling has to become a native part of the transfer lifecycle rather than a bolt-on, which is a question of architecture as much as vendor choice. An exchange can weigh this while planning its own crypto exchange platform.

Summary and Next Steps

The travel rule makes an exchange responsible for the identifying information that accompanies transfers in both directions: assembling and transmitting it when a customer sends assets, and obtaining, checking and acting on it when a customer receives them. The harder realities around it — identifying counterparties from addresses, working with a network that is not uniformly ready, handling self-hosted wallets and moving personal data lawfully — make it an engineering and operational matter, and for UK and EU markets it is established law.

Firms planning or operating an exchange can begin by mapping travel-rule handling onto their existing withdrawal, deposit, identity and screening flows, and by designing counterparty identification, self-hosted-wallet handling and record-keeping as parts of that whole. Our work on crypto exchange software and AML screening sets out how these controls are engineered into the transfer lifecycle rather than added at its edge.