GUIDE · TRAVEL RULE

The crypto Travel Rule for brokers

Published 2026-09-30 · Updated 2026-09-30

The Travel Rule is written for crypto-asset service providers. It still reaches a broker funded in stablecoins, through the exchange your client withdraws from and the processor that receives funds for you.

The Travel Rule makes the firms that move crypto for customers send the sender's and recipient's details along with the transfer, the way a bank wire carries the payer's name. It comes from FATF Recommendation 16, applied to virtual assets through Recommendation 15, and most major financial centres have written it into law, although FATF still reports gaps in how it is applied.

Most brokers that accept USDT or USDC are not crypto-asset service providers for that flow, so the rule does not usually bind them directly. But the firms on either side of a client's deposit are bound by it, and what they ask, send and hold ends up in your client's experience and, often, in your file. This guide covers the mechanics in the EU and the UK, the three set-ups brokers typically use, and what is worth keeping. It is a map, not legal advice. Whether your firm is a service provider for these transfers depends on your licence and structure, and that is the first question to settle with counsel.

Start free sandbox Talk to us50 screenings a month free, no card.

On this page

What the rule requires

The sending provider collects originator and beneficiary data and sends it with the transfer. The receiving provider checks it arrived and decides what to do when it did not.

In the EU the rule is Regulation (EU) 2023/1113, the recast Transfer of Funds Regulation, which has applied to crypto-asset transfers since 30 December 2024. Under Article 14, the provider sending a transfer must include the originator's name, distributed-ledger address and crypto-asset account number, the originator's address (with country), official personal document number and customer identification number or, instead of those, date and place of birth, and the LEI where there is one; and for the beneficiary, the name, distributed-ledger address, crypto-asset account number and LEI where available. The information has to travel "in advance of, or simultaneously or concurrently with" the transfer. For transfers between providers there is no minimum amount.

The receiving provider must have procedures to detect missing or incomplete information and, under Article 17, a risk-based way of deciding whether to execute, reject, return or suspend a transfer that arrives without it.

In the UK the rule sits in Part 7A of the Money Laundering Regulations 2017 and has applied to cryptoasset businesses since 1 September 2023. Below EUR 1,000 the basic set is names and account numbers. Above it, cross-border transfers need more, such as an address or date and place of birth. The FCA has said that firms stay responsible for compliance even when a third-party Travel Rule supplier does the messaging.

One point often missed

The rule is about information about people, sent between providers. It is not a sanctions check and not a blockchain analysis. A transfer can carry perfect Travel Rule data and still come from a listed or frozen address, and the reverse.

Self-hosted wallets and the EUR 1,000 line

A wallet no provider operates cannot receive Travel Rule messages. The EU rule makes the provider on the other side hold the data itself, and above EUR 1,000 assess who controls the address.

A self-hosted wallet is one the user holds the keys to, with no provider behind it. Under Article 14(5) of the EU regulation, a provider sending to a self-hosted address must obtain and hold the originator and beneficiary information itself and make the transfer individually identifiable; Article 16(2) mirrors this for transfers received from one. For amounts above EUR 1,000, the provider must also take adequate measures to assess whether the address is owned or controlled by its own customer.

The UK takes a lighter line: firms are not required to exchange Travel Rule information for transfers to or from unhosted wallets, but must assess the risk of such transfers and collect information where that assessment calls for it.

This is where a broker's clients notice the rule. When a client withdraws stablecoins from an EU exchange (USDC, say, since most EU platforms stopped offering USDT to EU users under MiCA) to a deposit address you gave them, the exchange has to work out what that address is. If it is a wallet you control, it is not the client's own wallet, so the exchange will ask who the recipient is. Expect clients to see questions like "Is this your wallet?" or "Who is the recipient?" and to ask you what to answer.

Three common broker set-ups

Who receives the Travel Rule data depends on who operates the address the client sends to.

A licensed processor or custodian receives for you
The client sends to an address operated by a payment processor or custodian that is itself a service provider. That firm is the beneficiary provider: it receives the Travel Rule message from the client's exchange, checks it, and credits you. The data sits with the processor. Ask in your contract for it to be passed on per transfer, at least the sending provider's name and LEI and the country, because it answers "where did this come from?" in a review.
You receive on a wallet you operate
The client's exchange sees a self-hosted address. No message reaches you. The exchange holds the data and may ask the client who the recipient is. Give clients a one-line answer to use (your legal entity name, and that the address belongs to it), so the exchange's check does not stall the deposit. Keep the address registered to your entity in your own records.
Your firm is itself a service provider
If your licence or registration makes you a crypto-asset service provider for these transfers, for example an EU investment firm that has notified crypto-asset services under MiCA, the rule applies to you in full: you send and receive the messages, detect missing data and decide under Article 17. That usually means joining a Travel Rule messaging network, which is a separate project from screening.

What to keep, whatever your set-up

The sending provider's identity and country per deposit, kept with the decision, and a record of what you did when it was missing.

Even where the rule does not bind you, the data it produces is some of the best source-of-funds evidence you can get for a crypto deposit: a named, identifiable exchange sent it. Worth keeping per transfer:

The originating provider's name and LEI, and its country.
The account reference it used for your client, if the processor passes it on.
Whether the data was complete when the deposit was decided, and what you did when it was not: credited, held or asked the client.
For deposits from a self-hosted wallet, the client's proof that they control it. The wallet ownership guide covers the three methods.

What not to keep in a screening tool: people's names and identity documents. Those belong in your KYC system, where access and retention are already controlled.

How KYTGate handles Travel Rule data

It records what your processor hands over, shows it on the case and in the SAR draft, and says in the coverage matrix whether it was present. It does not send Travel Rule messages.

POST /api/v1/processor-signals accepts optional originator and beneficiary objects with vaspName, vaspLei, accountRef and country. LEIs are checked against their ISO 17442 check digits and countries against ISO 3166; anything else sent in those objects, such as a person's name, is dropped rather than stored.

The screening that matches the processor signal carries the travelRule coverage dimension: COMPLETE when both parties were received, PARTIAL when one was, MISSING when none. "Complete" means recorded as received. KYTGate cannot verify the content. The data appears on the case, in the evidence pack, and in the transaction legs of the SAR draft, and your policy can decide what a gap means, for example routing large deposits without Travel Rule data to review.

KYTGate is not a Travel Rule network and does not originate, relay or answer Travel Rule messages. If your firm must send them, you need a messaging provider as well. KYTGate records the outcome next to the sanctions, freeze and behaviour checks on the same deposit.

Questions

Does the Travel Rule apply to a forex or CFD broker that accepts USDT?

Usually not directly: it binds crypto-asset service providers, and accepting stablecoins as client funding does not by itself make a broker one. It applies to the exchange your client sends from and to any processor or custodian that receives for you, and in full if your own licence makes you a service provider for these transfers. Confirm your position with counsel.

What is the Travel Rule threshold in the EU?

For transfers between crypto-asset service providers there is none: the recast Transfer of Funds Regulation, applicable since 30 December 2024, applies to every amount. EUR 1,000 matters for self-hosted wallets: above it, the provider must assess whether the address is owned or controlled by its own customer.

Why does my client's exchange ask who owns our deposit address?

Because an address your firm operates is a self-hosted wallet from the exchange's point of view, and under the EU rule the exchange must hold the recipient's details itself and, above EUR 1,000, check whether the address belongs to its customer. It does not. Give clients your legal entity name as the recipient.

Is Travel Rule data the same as a sanctions check?

No. Travel Rule data says who the sender and recipient are, as stated by the providers involved. A sanctions check compares addresses and names against official lists, and an issuer-freeze check reads the stablecoin contract. A deposit needs all three answered separately.

Start free sandbox Talk to us