If your business sends crypto payouts — to contractors, suppliers, affiliates or partners — the crypto Travel Rule sits between you and every transfer. It is the piece of regulation most likely to delay, hold or return a B2B payout, and most senders meet it for the first time when a payment stops. This guide sets out where the obligation comes from, what data has to travel, the order the checks actually run in, and what breaks in production.
This article describes regulatory and market conditions for general information. It is not legal, tax, or financial advice — INXY Payments is a payment infrastructure provider, not a law or accountancy firm, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant jurisdiction.
What the Travel Rule is, and where it comes from
The Travel Rule is an anti-money-laundering standard requiring identifying information about the originator (sender) and the beneficiary (recipient) to travel alongside a transfer of value. It began in conventional wire transfers and now applies to crypto.
The instrument: FATF Recommendation 16
The obligation originates in Recommendation 16 of the FATF International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation, together with its Interpretive Note (INR.16), which sets out the required data fields for wire transfers. Crypto came in through Recommendation 15: FATF amended it in October 2018 to cover virtual assets and virtual asset service providers, and in June 2019 adopted its Interpretive Note (INR.15), which applies R.16's requirements to virtual asset transfers and permits a USD/EUR 1,000 de minimis threshold.
Two developments since then matter operationally:
- In June 2025 FATF adopted revisions to Recommendation 16 on payment transparency, modernising the standard for current payment systems, with a phased implementation timeline for jurisdictions (FATF, Updates to Standards on Recommendation 16 on Payment Transparency, June 2025).
- In July 2026 FATF published its Seventh Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs, the annual assessment of how far jurisdictions have actually got, and the current reference for implementation status (FATF, July 2026).
FATF recommendations are not law in themselves. Each jurisdiction legislates its own version, which is why the picture is fragmented and why a payout that is routine in one corridor stalls in another.
Who carries the obligation — and when you are the originator
The duty falls on virtual asset service providers: exchanges, custodial wallet providers and crypto payment gateways. When your business initiates a payout through one, the provider is the originating institution and carries the Travel Rule duty — but it can only discharge that duty using your data.
The burden is shared in a specific and often misunderstood way. The provider operates the machinery. You supply the beneficiary information, and incomplete or mismatched sender-supplied data is the single most common reason a payout stalls. Nothing about using a regulated provider moves that responsibility off your side.
The regulatory picture by region
| FATF baseline | European Union | United States | |
|---|---|---|---|
| Instrument | Recommendation 16, applied to virtual assets by INR.15 | Regulation (EU) 2023/1113, with EBA Guidelines EBA/GL/2024/11 | Bank Secrecy Act, administered by FinCEN |
| Threshold | USD/EUR 1,000, below which a reduced data set may apply | None. Full data on every crypto-asset transfer | USD 3,000 |
| Status | Standard, not law. Jurisdictions implement it. | Directly applicable, since 30 December 2024 | In force; stablecoin issuers being drawn in — see below |
| Companion framework | Recommendation 15 / INR.15 for VAs and VASPs | MiCA, Regulation (EU) 2023/1114, for provider authorisation | — |
| Served by INXY? | — | Yes | No |
European Union — no de minimis threshold
The EU regime is the strictest of the major ones. Regulation (EU) 2023/1113 — the recast transfer-of-funds rules, extended to cover transfers of crypto-assets — has applied since 30 December 2024, and it carries no minimum threshold. A EUR 5 payout and a EUR 500,000 payout attract the same information obligation. The EBA Guidelines EBA/GL/2024/11 set out how transfers with missing or incomplete information must be handled, including when to execute, reject or suspend.
It operates alongside MiCA, Regulation (EU) 2023/1114, whose Title V governs the authorisation and operating conditions of crypto-asset service providers, with authorisation under Article 59. The two regimes do different jobs: MiCA decides who may provide the service, 2023/1113 decides what information must accompany each transfer.
United States — market context only
In the US the Travel Rule sits under the Bank Secrecy Act with a USD 3,000 threshold, and stablecoin rails are being drawn further into the banking compliance perimeter following the GENIUS Act.
It does not create a path for US readers here. INXY Payments serves Europe, Asia and LatAm, and does not serve the United States, the United Kingdom or sanctioned jurisdictions. The US regime appears in this article as market context and nothing else.
The sunrise problem
Because jurisdictions adopt the rule at different speeds, a compliant provider in a regulated market frequently needs to send Travel Rule data to a counterparty in a market that has not implemented the rule and cannot receive it. This is the sunrise problem, and for a B2B sender it has a blunt consequence: the success of your payout can depend on your beneficiary's jurisdiction rather than your own.
In practice it shows up three ways. The counterparty provider accepts the transfer and ignores the data, which is fine. It rejects the transfer because it cannot process the message, which costs you a cycle. Or it accepts and then queries, which parks the funds without telling anyone. Ask your provider which counterparties in your corridor list fall into the second and third categories before you build a payment calendar around them — or bring the list to a demo and we will mark them.
What data must travel with a B2B crypto payout
The required set is consistent across regimes even where thresholds differ.
Originator (sender) fields
- Name of the originator — your business or the paying entity.
- Wallet address used for the transfer, or a transaction reference.
- Physical or registered address, and in some regimes an official identifier or account number.
Beneficiary (recipient) fields
- Name of the recipient.
- Wallet address receiving the funds.
The transaction amount, execution date and a unique transaction identifier are recorded with every transfer. The operational takeaway: beneficiary name and wallet must be accurate and verifiable before you send. A mismatch is a hold.
Self-hosted wallet payouts — the extra step
Paying a self-hosted, non-custodial wallet — common when paying contractors who hold their own keys — changes the mechanics. There is no counterparty provider to receive the message, so nothing is transmitted onward. Your provider must still collect originator and beneficiary information, and above the relevant threshold may require verification that the beneficiary controls the destination address, based on a risk assessment. Expect to attest to control of the address on larger payouts.
What screening actually runs, in order
This is the part most articles skip, and the order matters more than the list. Using INXY's outbound model, a payout passes through these gates before any transfer is created:
- The payout is created as a request, not a send. Nothing is on-chain yet. This is what makes everything below cheap: a problem caught here produces an error, not a transaction to unwind.
- Pre-send validation. Structural and field-level checks. Failure stops the operation with an error and no transaction is formed.
- Address history lookup. A previously unseen destination address is treated cautiously; a known one carries its last risk result forward.
- Blacklist check on the beneficiary address. A match fails the request outright. No transaction created.
- KYT risk screening. A risk provider scores the destination address. Low or Medium passes. High fails the request, no transaction is created, and an error returns.
- Approved-contact / allow-list check. A recipient marked declined blocks the payout regardless of every check above — the control finance teams use to maintain a vetted payee set for recurring and mass runs.
- Travel Rule message exchange. Only now. The required originator and beneficiary information is packaged and exchanged with the counterparty provider where one exists.
- Settlement.
Screen first, then transmit, then send. Every row in an INXY mass payout batch runs this sequence individually. A provider that exchanges Travel Rule data before screening has told you something about its architecture, and it is worth asking the question during evaluation.
KYB is the gate to the platform, KYT the gate to each transaction, and the Travel Rule the data that rides along with it. A provider handling only the first is one you will outgrow at your first screening event.
What breaks in production
Name mismatch and transliteration. Your beneficiary name does not match the one the counterparty provider holds — legal versus trading name, or a different transliteration from a non-Latin script. This is the most common single cause of a hold, and it is entirely preventable by capturing the name as the beneficiary's own provider holds it rather than as it appears on your invoice.
Screening true positives mid-batch. A row in a mass payout hits a sanctions or KYT match. The correct behaviour is that the row stops and is escalated for review while the rest of the batch proceeds. Some platforms halt the entire batch. Establish which before a payout Friday establishes it for you. To be unambiguous: the right answer is that the payout stops and is reviewed. Any provider positioning reduced screening as a feature is selling a future enforcement problem.
Self-hosted wallet attestations collected too late. If address-control verification is requested at payout time rather than at payee onboarding, you discover it during a cycle. Collect it when you onboard the payee.
Treating a passed screen as permanent. A destination address that scored Low last month can score High this month. Screening is per-transaction for a reason, and a cached pass is not a control.
Compliance risks of getting payouts wrong
- Held or returned transfers — funds sit in review or come back, delaying the people you owe.
- Counterparty refusal — a receiving platform that cannot accept the data, or flags your transfer, bounces it.
- Regulatory exposure — outbound flows without proper screening and recordkeeping invite AML enforcement.
- Operational drag — in-house screening and Travel Rule messaging is never finished, because standards keep moving, as the June 2025 R.16 revisions show.
The decision framework
Three questions settle whether you need to care about any of this in-house.
- Do you send, or only receive? Acceptance screening is the easier half. The outbound leg is where sanctions screening, address risk and transfer-information requirements bite, because on a payout you are the originator. If you will ever send, test the payout leg during evaluation, not after.
- Where are your beneficiaries, and what are their providers? Your corridor list, not your own jurisdiction, determines how much of the sunrise problem you will meet. Get a corridor-by-corridor answer from any provider you shortlist.
- Do you want to own the compliance stack? If not, require a provider that runs validation, blacklist and KYT screening, the Travel Rule exchange and an approved-contact control inside the payout flow, exposed through API and webhooks so a mass run applies the checks per recipient.
What none of this does is reduce your obligations. A regulated provider runs the controls; it does not remove them, and no rail helps anyone bypass KYC, sanctions screening or reporting.
For the asset most B2B runs settle in, see payouts settled in USDT.
FAQ
Does the Travel Rule apply to stablecoin payouts?
Yes. A stablecoin transfer handled by a regulated provider is a transfer of a crypto-asset and carries the same obligations as any other. In the EU, full originator and beneficiary data is required regardless of amount under Regulation (EU) 2023/1113.
What is the Travel Rule threshold?
It depends on the jurisdiction. FATF's standards, as applied to virtual assets by the Interpretive Note to Recommendation 15, permit a USD/EUR 1,000 de minimis threshold below which a reduced data set may apply. The EU applies no threshold — every crypto-asset transfer carries full data. The US applies USD 3,000 under the Bank Secrecy Act.
Do I need to collect data for self-hosted wallet payouts?
Yes. Even with no counterparty provider to receive the message, your provider must still collect originator and beneficiary information, and above the relevant threshold may require verification that the recipient controls the destination address. Collect that attestation at payee onboarding, not at payout time.
Is the Travel Rule the same as KYC?
No. KYC and KYB verify identity once, at onboarding. The Travel Rule governs the transmission of originator and beneficiary data alongside each individual transfer. KYT screens the transaction itself, including the risk of the destination address. Three distinct controls, running at three different moments, and a provider needs all three.
Who is responsible — the sender or the recipient platform?
Both sides carry obligations. The originating provider must collect and transmit the data; the beneficiary provider must receive and retain it. As the business initiating the payout, you are responsible for supplying accurate beneficiary information to your provider, and that is where most failures originate.
What is the sunrise problem?
It is the mismatch created when jurisdictions implement the Travel Rule at different speeds. A provider in a regulated market must send data to a counterparty in a market that cannot receive it. For a payer, it means a payout's success can depend on the beneficiary's jurisdiction rather than your own compliance posture.
Does using a regulated gateway reduce my compliance obligations?
No. It moves the operational work — screening, list maintenance, message exchange, recordkeeping — to a provider built for it. The underlying obligations on your business remain yours, including supplying accurate beneficiary data and keeping it current. No provider can help anyone bypass KYC, sanctions screening or reporting.
Last updated: 14 October 2026.
