Crypto Travel Rule 2026: We Read 12 Gateways

Your gateway asks your customer for a date of birth and explains it with a compliance notice nobody reads. Then your own withdrawal stops, because the wallet you are paying yourself into is not one anyone has proved you own. That is the crypto travel rule as merchants meet it: invisible while you integrate, expensive the first time it moves.

The obligation is not yours. It sits on the regulated firm handling the transfer, which is why most merchants read nothing about it until a payment or a payout stalls. But the data the rule demands has to come from somewhere, and one gateway says plainly that it comes from you. So we read 25 documents — terms, privacy policies, AML policies — from twelve hosted crypto payment gateways on 22 October 2026, plus BTCPay Server's FAQ as the self-hosted control and the UK regulations as they now stand. Ten of the twelve never mention the rule.

Who the Travel Rule obliges, and why it is not you

The rule is older than crypto: information about both parties accompanies a transfer of value so it stays traceable, as banking has done for decades. A chain transfer carries no identity data, so the information moves alongside it, between the regulated firms at either end.

In the EU the duty arrives through the Transfer of Funds Regulation, which the European Commission says "ensures the traceability of crypto-assets transfers and the authentication of users, aligning with FATF standards" and "will apply as of December 2024", imposing it on "all crypto service providers involved in crypto transfers". In the UK the same standard sits in Part 7A of the 2017 money laundering regulations, which bites on a "cryptoasset transfer" — "an inter-cryptoasset business transfer or an unhosted wallet transfer".

Selling goods for crypto does not make you a cryptoasset business, so no clause in Part 7A addresses you. The rule reaches you through your counterparties, on five legs.

The leg	Who carries the duty	What it costs you
Buyer pays from an exchange account	Their provider and your gateway swap the data	A form at checkout, unless you pre-fill it
Buyer pays from their own wallet	Your gateway, as the business at one end	Your gateway asks who owns that wallet
Gateway settles into your exchange account	Your gateway sends, the exchange checks	A name mismatch can hold the payout
Gateway settles into your own wallet	Your gateway, before it releases funds	Proof the address is yours
Buyer's own wallet pays your own wallet	Nobody — no business in the path	Nothing, and nothing is traceable

Every explainer covers the first two. The third and fourth are where merchants lose money, and no page ranking for this query mentions them.

Ten of twelve gateways never name it

We looked for the phrase in the documents a merchant can read before signing up: terms, privacy policies, AML policies, developer docs. Two gateways name it.

Gateway	Documents we read (date on them)	Travel Rule named
CoinGate	Merchant terms; privacy policy (Aug 2026); glossary; blog post (24 Oct 2025)	Yes — twice
Confirmo	Privacy policy (16.10.2026)	Yes — with the regulation
BitPay	Merchant terms (1 Apr 2026); privacy notice (10 Jan 2026)	No
NOWPayments	AML/KYC policy (15 Dec 2025); privacy policy	No
Cryptomus	AML/CFT policy (reviewed 1 Oct 2026); privacy policy (30 Jul 2026)	No
BlockBee	AML policy (7 Sep 2026); terms (2 Oct 2026); privacy policy (10 Sep 2025)	No
B2BinPay	AML and KYC policy (9 Mar 2026); terms of use	No
PassimPay	Terms (11.05.2026); privacy policy (10 Feb 2024)	No
Plisio	Terms of use; privacy policy (12 Mar 2019)	No
Apirone	Privacy policy (in effect 1 Sep 2017) — its only legal document	No
OpenNode	Terms and conditions; privacy policy (both undated)	No
Triple-A	Terms; privacy policy (both undated)	No
BTCPay Server (self-hosted control)	General FAQ	Not applicable — no third party

The silence is not staleness. BlockBee's terms took effect on 2 October 2026 and Cryptomus reviewed its AML policy on 1 October 2026 — maintained documents, newer than either that explains the rule, and still silent on it. At the other end, Apirone's only legal document has been "in effect as of Sept 1, 2017" and Plisio's was last edited in March 2019. Silence is not a claim that a gateway ignores the rule; it is the absence of what a merchant needs — what gets asked, of whom, and when.

The UK crypto travel rule threshold fell to £800

Every page we read while planning this article gives the threshold as €1,000 or £1,000. For the UK that has been wrong since the end of June. Regulation 64C(4) now applies the extended dataset where a transfer "is equal to or exceeds the equivalent in cryptoassets of [£800] in value (taken together with any other cryptoasset transfer which appears to be linked)". The annotation gives the provenance: "Sum in reg. 64C(4) substituted (30.6.2026) by The Money Laundering and Terrorist Financing (Amendment) Regulations 2026 (S.I. 2026/621)". The same instrument moved the matching sum in regulation 64G(1)(b), for unhosted wallet transfers.

A hundred pounds sounds like nothing until you see what sits in that band: a mid-range hardware order, two months of a B2B subscription, most single-item electronics sales. Payments that cleared without a second form in May can ask for one now.

Regime	What triggers the extended dataset	Figure	Source read 22 Oct 2026
UK, two cryptoasset businesses, not all UK-based	At or above the sum, counting linked transfers	£800 (was £1,000)	reg. 64C(4), substituted 30.6.2026
UK, two UK cryptoasset businesses	No threshold: follows a request, within three working days	Any value	reg. 64C(2)-(3)
UK, unhosted wallet transfer	At or above the sum, where the customer is the beneficiary	£800 (was £1,000)	reg. 64G(1)(b), substituted 30.6.2026
EU Transfer of Funds Regulation	Stated for "all crypto service providers involved in crypto transfers", from December 2024	No threshold stated	European Commission AML/CFT page
What a MiCA-licensed gateway says it does	Name, country, date of birth always; more above unpublished thresholds	Not published	CoinGate's Travel Rule post

Plan for the pattern, not the number: the basic dataset travels on everything, and the extended set arrives at a figure that moves. Build as though it is always coming, and a threshold change is somebody else's news story.

What has to travel with the transfer

The UK regulations split the data in two. Regulation 64C(5) travels with every transfer: "the name of the originator and the beneficiary", the registered or trading name of a firm, and "the account number of the originator and the beneficiary, or if there is no account number, the unique transaction identifier". Regulation 64C(6) is the extended set, satisfied for an individual by any one of four things: a customer identification number, an address, a "birth certificate number, passport number or national identity card number", or a "date and place of birth".

That "one of the following" answers a question merchants ask constantly: why does one gateway want a date of birth and another an address? The regulation offers a menu, and each firm picks what it can collect most reliably.

Dataset	Fields	When it applies
UK basic (reg. 64C(5))	Names of originator and beneficiary; registered or trading name for a firm; account numbers, or a unique transaction identifier	Every inter-business transfer
UK extended (reg. 64C(6))	For an individual, one of: customer ID number; address; birth certificate, passport or national ID number; date and place of birth	On request between UK firms; at or above £800 otherwise
CoinGate, from a shopper	Email, name, date of birth, country of residence	Before the payment can process
CoinGate, for a payout recipient	Email, name, surname, country of residence, address	When a beneficiary is paid by a merchant
Confirmo, about an end customer	Full name; account number or wallet address; full physical address; date and place of birth; official personal document number	On transactions processed for a merchant

Two clauses decide how hard that data is to supply late. Regulation 64C(8) requires the originator's information to have been "verified" against "documents or information" from an independent reliable source, and 64C(9) is categorical: a business "must not make an inter-cryptoasset business transfer before ensuring full compliance with this regulation". Nothing here is fixable afterwards; the transfer does not go.

CoinGate tells merchants what it will ask

CoinGate is the only gateway here that has written the whole thing down for the person integrating it, and as a MiCA licence holder in Lithuania it is bound by the EU rule directly. Its post separates the two cases a merchant must keep apart. "When a crypto transaction happens between two regulated providers in jurisdictions where the Travel Rule applies (for example, between CoinGate and Kraken), we'll need to exchange data to ensure that both sides know who the sender and the recipient are." Then: "Conversely, if the transaction involves a self-hosted wallet, we'll need to make sure we know who owns that self-hosted wallet."

For shoppers the ask is stated exactly: "we'll collect your name, country of residence and date of birth", with more "if your payment exceeds certain thresholds or conditions". The glossary gives the checkout version in a line — "Email address, name, date of birth and country of residence, before the payment can process" — then makes the commercial point: those fields are a conversion loss you can choose not to take. If your checkout holds the buyer's billing details, pass them through when you create the order and the shopper only confirms them.

That is the cheapest compliance win a crypto merchant has, and it is one API object. We mapped what each checkout accepts, field by field, in our reading of ten gateways' customer data.

Confirmo expects the data from you, not your buyer

Confirmo does not publish a merchant guide to the rule, but its privacy policy is the most legally precise document in the set, and one sentence in it should change how a merchant plans an integration. The Travel Rule data about end customers, it says, "may be collected directly from the End-Customer, but it is usually provided to us by the Merchant or another Virtual/Crypto Asset Service Provider processing the transaction".

Read that as an operational requirement, not a disclosure: the usual path, by the gateway's own account, runs through your systems. And the dataset is the deepest we read — full name, account number or wallet address, full physical address, date and place of birth, and an "official personal document number". Most e-commerce checkouts do not hold a passport number, or want to.

Confirmo also names the parent standards, which no other gateway does: it processes end-customer data "as required to comply with binding legal and regulatory obligations, such as Financial Action Task Force (FATF) Recommendation 16 and its local implementations ('Travel Rule') such as Regulation (EU) 2023/1113". The legal basis is GDPR Article 6(1)(c), and retention for these records runs "ten years or more" after the relationship ends — your buyer's document number in someone else's system for a decade. Where that data lands is our reading of ten gateways' GDPR posture.

The leg that bites is your payout

On the checkout leg you are a bystander: the gateway collects what it needs and the payment processes or does not. On the payout leg you are the customer, the beneficiary, and the one whose information is missing.

Take the self-hosted case first. CoinGate states the consequence for business clients directly: "If you're making a transaction using a self-hosted wallet, we'll ask you to provide evidence of owning the external crypto wallet in your CoinGate account dashboard. This will typically be a one-time requirement, so long as you're depositing and/or withdrawing crypto using the same external address." The regulations say what happens if you do not: under regulation 64G(1)(b) a business may request the extended dataset where an unhosted wallet transfer reaches £800 and its customer is the beneficiary, and regulation 64G(4) closes it off — "In the event that the cryptoasset business involved in an unhosted wallet transfer does not receive information requested under paragraph (1) it must not make the cryptoasset available to the beneficiary."

Now the exchange case, which is how most merchants cash out. Paying from your gateway into your own exchange account is a transfer between two businesses, so the receiving side runs regulation 64D(1): before releasing funds it must confirm it got the required information and that "the information relating to the beneficiary corresponds with information verified by it under Part 3" — its own due diligence. In plain terms, the name your gateway sends has to match the name on your exchange account. A company paying out to a director's personal account, or to one opened under a trading name rather than the registered one, is a discrepancy the receiving firm must notice.

Neither failure looks like a compliance problem from your dashboard. It looks like a payout that has not arrived, which is why it is misread as an AML hold or as inbound screening — different mechanisms, different remedies.

What the receiving provider must do when data is missing

The regulations set out the sequence, and reading it tells you what to ask for when a transfer stalls.

Actor	Trigger	What it must do	Clause
Sending business	Any inter-business transfer	Must not transfer before "ensuring full compliance"; originator data independently verified	64C(8)-(9)
Receiving business	Data missing, or beneficiary data does not match its records	Request it; consider enquiries; consider delaying release; if unresolved "within a reasonable time", consider returning the asset to the sender	64D(2)
Receiving business	Repeated failures by one counterparty	Report the firm to the FCA, with the steps taken	64D(5)
Intermediary	Data missing on an onward transfer	Request it; consider delay or return; pass on all it received	64E(2), 64F
Either side	Unhosted wallet transfer, requested data not received	Must not make the asset available to the beneficiary	64G(4)

Three things follow. A delay under 64D(2) weighs risk factors including "the duration of its business relationship with the beneficiary", so a brand-new exchange account is the worst place to route a first large settlement. A return under 64D(2)(c)(ii) sends the asset to the sending business, not to you: recoverable, on someone else's timeline. And a stop under 64G(4) is no judgement call at all.

Where FATF appears without the rule

Four of the twelve name the Financial Action Task Force somewhere, which is how a gateway can look as though it has addressed this. Besides Confirmo, none of them is talking about transfers.

Cryptomus cites FATF six times in an AML policy reviewed on 1 October 2026, every time about posture or geography: a risk-based approach "in line with the principles set out by" FATF, exposure to "jurisdictions identified as high-risk". NOWPayments uses it once, to define a high-risk country. CoinGate's merchant terms use it for eligibility — refusing a merchant resident in "a country that is not a member of the Financial Action Task Force".

A FATF citation in an AML policy tells you how a gateway assesses you. Recommendation 16, the one that makes data travel, appears in one gateway document here.

The designs the rule does not reach

Two structures sidestep the whole question, and both are already in the directory.

The first is self-hosting. BTCPay Server calls itself "a non-custodial invoicing system which eliminates the involvement of a third-party", where "payments with BTCPay go directly to your wallet". Against the UK definitions the arithmetic is simple: a cryptoasset transfer is an inter-business transfer or an unhosted wallet transfer, the first needs two cryptoasset businesses and the second needs one. A buyer paying from their own wallet into your own node has none. There is a carve-out at the other extreme too: Part 7A "does not apply to a cryptoasset transfer where both the originator and the beneficiary is a cryptoasset business acting on its own behalf".

The second is the forwarding model, where the gateway watches the chain and funds land in a wallet you control — the pattern in our guide to non-custodial and forwarding gateways. It does not make the rule disappear, since the gateway may still be regulated for what it does, but it changes which legs exist: nothing settles into a third party's balance and back out, so the expensive leg is not there to fail. Neither route is free — a node to run, or no fiat conversion in the flow.

What to check before your next payout

Five things, in the order they cost money.

• Match the name. The registered name on your gateway account and on the exchange account you settle into must be the same legal person. Regulation 64D(1)(b) makes the receiving firm compare them.
• Do the ownership proof while nothing is pending. CoinGate says it is typically one-time per address: doing it early costs nothing, doing it late costs a stopped payout.
• Pre-fill the shopper fields. You already hold the buyer's name and country. Passing them through turns a form into a confirmation.
• Decide what you will not hold. If a dataset reaches a passport number, choose whether it crosses your systems or goes straight to the provider — through your database makes it yours to secure, behind your API credentials.
• Ask the question no page answers. Ask support what they require on a withdrawal to a self-hosted address, and at what value. Ten of twelve do not publish it, so the answer only exists in a ticket.

The fewer parties hold your settlement, the fewer have to ask who you are.

FAQ

What is the crypto Travel Rule?

It is the requirement that identifying information about the sender and recipient travels with a crypto transfer between regulated firms. It comes from FATF Recommendation 16, implemented in the EU by Regulation (EU) 2023/1113 — applying from December 2024, per the European Commission — and in the UK by Part 7A of the 2017 money laundering regulations.

Does the Travel Rule apply to merchants accepting crypto?

Not directly. The duty sits on the regulated provider handling the transfer, and selling goods for crypto does not make you one. It reaches you through your gateway: data about your buyer and your payout recipient, and evidence that a wallet you withdraw to is yours.

What is the Travel Rule threshold in 2026?

It depends on the jurisdiction, and the UK figure changed this year: regulation 64C(4) now sets it at £800, substituted on 30 June 2026 by S.I. 2026/621, and the matching sum in 64G(1)(b) moved with it. Between two UK firms there is no threshold for the extended dataset; it follows a request, within three working days.

Why does my crypto gateway ask my customer for a date of birth?

Because the extended dataset can be satisfied by any one of several identifiers. Regulation 64C(6) lists a customer identification number, an address, a passport or national ID number, or a date and place of birth. CoinGate collects name, country of residence and date of birth, and lets you pre-fill those fields.

Do I have to prove I own my own crypto wallet?

If you withdraw from a regulated gateway to a self-hosted address, expect to. CoinGate asks for "evidence of owning the external crypto wallet", typically once per address. Regulation 64G(4) is why: a business that does not receive the information it requested on an unhosted wallet transfer "must not make the cryptoasset available to the beneficiary".

What happens if the Travel Rule information is missing?

The receiving business must request it, consider enquiries and a delay, and if unresolved within a reasonable time consider returning the asset to the sender. Repeated failures by one counterparty go to the FCA. On an unhosted wallet transfer there is no discretion: without the requested information the asset is not released.

Does the Travel Rule apply to BTCPay Server or a self-hosted gateway?

On the UK definitions, a transfer with no cryptoasset business at either end is not a cryptoasset transfer, so neither limb of Part 7A is engaged. BTCPay Server has "no third-party involvement" and payments go "directly to your wallet" — at the cost of running your own node and fiat conversion.

Sources

Read 22 October 2026:

• The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017, Part 7A (regs. 64A–64H; £800 substituted 30.6.2026 by S.I. 2026/621, regs. 32-33)
• European Commission — Anti-money laundering and countering the financing of terrorism at EU level (TFR 2023/1113; "applies as of December 2024")
• CoinGate — The Travel Rule (TFR) at CoinGate, Explained (wallet ownership evidence; 24 October 2025)
• CoinGate — What is the travel rule? (checkout fields; shopper-object pre-fill)
• CoinGate — Privacy Policy (payee and beneficiary datasets; August 2026)
• CoinGate — Merchant Terms of Service (clause 27.5.9)
• Confirmo — Privacy Policy (PDF) (FATF R16 and Regulation (EU) 2023/1113 named; 16.10.2026)
• Cryptomus — AML/CFT Policy (FATF for risk approach only; reviewed 1 October 2026)
• NOWPayments — AML/KYC Policy (PDF) (FATF only defines a high-risk country; 15 December 2025)
• BitPay — Merchant Terms of Use (effective 1 April 2026; no Travel Rule clause)
• BlockBee — AML Policy (7 September 2026)
• B2BinPay — AML and KYC (9 March 2026)
• PassimPay — Terms (11.05.2026)
• Plisio — Privacy Policy (PDF) (12 March 2019)
• Apirone — Privacy Policy (in effect 1 September 2017)
• OpenNode — Terms and Conditions (undated)
• Triple-A — Terms (undated)
• BTCPay Server — General FAQ ("no third-party involvement")