The travel rule does not apply to your business. It applies to the institution you hand the payment to. If you are a company paying a supplier, contractor or employee in stablecoins, you carry no obligation under it. You still feel all of it, because your provider cannot move your money until it holds the data the rule requires.
Key takeaways
- The obligation sits with regulated institutions, not with their customers. A business sending a payment is the originator, not the originating institution.
- It reaches you anyway, through four mechanisms: data your provider must collect before the payment moves, payments held when the receiving institution will not accept that data, proof of control over a self-hosted wallet, and counterparties in countries that have not implemented the rule.
- Thresholds decide how much data travels, not whether the rule applies. The FATF ceiling is USD/EUR 1,000, the United States sets USD 3,000 for transmittals of funds, and the European Union applies no minimum at all to crypto-asset transfers.
- The standard changed on 18 June 2025 and most published guidance predates it. The revised Recommendation 16 comes into effect by the end of 2030.
- Give your provider complete beneficiary details once, correctly, and most travel rule friction disappears. Incomplete data is the single most common reason a payment stops.
What the travel rule is
The travel rule requires that identifying information about the sender and the recipient travels alongside a payment, so the institution receiving the money knows who is on the other end. It began as a wire transfer rule and now applies to virtual asset transfers as well.
It sits in Recommendation 16 of the Financial Action Task Force standards, the global body that sets anti-money-laundering rules. FATF has no direct authority over any business. Countries implement its recommendations in their own law, which is why the detail differs by jurisdiction while the principle does not.
Who the travel rule binds, and where your business sits
Regulated institutions. Banks, payment service providers, money services businesses, and virtual asset service providers. In the European Union these are crypto-asset service providers. The obligation attaches to the entity executing the payment on someone's behalf.
The revised standard is specific about where that chain begins. Under the changes agreed at the FATF Plenary in June 2025, the payment chain is considered to start with the financial institution which receives an instruction from the customer. The customer giving the instruction sits outside the chain. That customer is you.
So the answer to whether the travel rule applies to your business is no, and the answer to whether it affects your payments is yes. Those are different questions and most published guidance answers only the first, because most published guidance is written for the institutions the rule binds.
One consequence worth holding onto. Your provider cannot satisfy an obligation you have not helped it meet. The rule lands on them, the data comes from you, and the payment waits for both.
The thresholds that decide what data moves
A threshold does not switch the rule on or off. It decides how much information has to accompany the payment.
| Jurisdiction |
Threshold |
What it means |
| FATF baseline |
Countries may set a de minimis threshold no higher than USD/EUR 1,000 |
Above it, full originator and beneficiary data. Below it, a reduced set still applies: the names of both parties and an account number or unique transaction reference for each |
| United States |
USD 3,000, under 31 CFR 1010.410(f) |
Applies to transmittals of funds, and applies to banks and non-bank financial institutions alike |
| European Union |
No minimum threshold for crypto-asset transfers, under Regulation (EU) 2023/1113 |
Every transfer between crypto-asset service providers carries full data, whatever the amount. In force since 30 December 2024 |
Two practical points follow.
Splitting a payment to stay under a threshold does not work and creates a worse problem. Transaction monitoring is built to detect payments sitting just below a reporting line, and a pattern of them reads as structuring.
Thresholds are set nationally within the FATF ceiling, so the figure that governs your payment is the one in the country of the institution handling it, not the one in your own country.
How the travel rule reaches a business that has no obligation under it
Four mechanisms. Each one is something that happens to your payment rather than something you are required to do.
Your provider asks you for data before the payment moves. The full legal name of the beneficiary, their account details, and often an address. Not because your provider is cautious, but because it cannot transmit information it does not hold. A beneficiary record with a trading name instead of a registered name is the most common cause of a rejected payment in this category.
Payments stop when the receiving institution will not accept the data. The institution at the other end runs its own checks on what arrived. If a required field is missing or inconsistent, it can hold the payment, ask questions, or return it. Your provider tells you, but the decision was made somewhere you have no relationship.
Self-hosted wallets add a verification step. Covered below.
Some counterparties sit in countries that have not implemented the rule. Also covered below.
The practical implication is dull and useful. The quality of your beneficiary records determines how often your payments stop. It is the one part of this that sits entirely within your control.
A self-hosted wallet is one no institution controls, which means there is no institution at the other end to receive travel rule data.
Regulators handle this by putting the burden back on the institution nearest the transfer. In the European Union, a crypto-asset service provider transferring to or from a self-hosted address must collect the required information and, above EUR 1,000, assess whether its customer actually owns or controls that wallet before making the assets available.
The provider performs that verification. You supply the proof, usually by signing a message from the wallet to demonstrate control. It is a one-time step per wallet rather than a per-payment one, which is why doing it during onboarding rather than mid-payment is worth the half hour.
Why a compliant payment still gets held
Because the rule is not implemented everywhere at the same pace. The industry calls this the sunrise problem: an institution in a jurisdiction that has implemented the rule sends data to one in a jurisdiction that has not, and the receiving side has no obligation, no system, and sometimes no interest in accepting it.
The gap is closing and remains real. In its seventh targeted update, published 16 July 2026, FATF reported that 83 per cent of surveyed jurisdictions have now passed legislation implementing the travel rule, up from 73 per cent in 2025, with a further eleven reporting implementation under way. FATF also continues to record gaps in licensing, supervision and enforcement among those that have legislated.
For a business paying into many countries, this shows up as inconsistency. The same provider, the same data, the same payment size, and a different experience by corridor. That is not your provider being unreliable. It is the map of which jurisdictions have built the receiving end.
What changes before the end of 2030
FATF revised Recommendation 16 at its June 2025 Plenary, and published Annex IV to its assessment methodology on 28 October 2025, setting out how compliance with the revised standard will be assessed. The changes come into effect by the end of 2030. Four of them matter to a payer.
The data set is standardised. For cross-border payments above USD/EUR 1,000, the payment message carries name, address and date of birth. One list instead of a different combination per jurisdiction.
Responsibility in the chain is clarified. The chain starts at the institution receiving the customer instruction, and information must remain unchanged as it passes along. Fewer arguments about who dropped a field.
Verification of recipient details becomes a requirement. Institutions will have to use tools that check the recipient's banking information before the payment goes, to catch fraud and misdirected payments. If you have used a confirmation-of-payee service, that is the mechanism.
Card payments for goods and services stay exempt. The revision clarified the scope of what counts as a purchase of goods and services rather than removing the exemption.
The direction is consistent. More data, verified rather than asserted, moving in a standard format. A business that keeps clean beneficiary records is already most of the way there.
What to give your provider before your first payment
Four things. Assembling them once removes most of the friction described above.
- Beneficiary legal names, not trading names. The name on the bank account, exactly as the bank holds it. This single field causes more stopped payments than the rest combined.
- Complete account details and a registered address for each beneficiary. Address is required above the threshold in most jurisdictions, and supplying it upfront avoids a request mid-payment.
- Proof of control for any self-hosted wallet you send from or to. Done once per wallet, at onboarding.
- Your own entity details, matched to your registration documents. Your provider transmits these as the originator. A mismatch between your onboarding record and your payment instruction is a held payment.
Then ask your provider one question: when a payment is held for travel rule reasons, who tells you, how quickly, and what do they need from you to release it.
How zPayments handles travel rule data
Screening, travel rule handling where in scope, and ongoing monitoring run on the platform rather than on the sender. Your own regulatory obligations remain your own, and this article is the reason that distinction matters: no provider can absorb a duty that the law places on you.
Beneficiary data is captured once, at onboarding, and reused on every payment to the same counterparty rather than re-requested each time. zPayments is registered as a Money Services Business with FINTRAC, which is a registration rather than a licence, and works with a network of licensed partners regulated in each corridor, with stablecoin payouts to 171 countries.
Settlement is instant across supported corridors, and next business day where the local rail clears on a cycle.
Start with zPayments.
Read next: Are stablecoin payment rails actually compliant and What is a stablecoin payout and how it works
Last reviewed: 26 September 2026. This article describes regulatory frameworks in general terms and is not legal advice.
