If your business sends crypto payouts — to contractors, suppliers, affiliates, or partners — the crypto Travel Rule now sits between you and every transfer. It is the single piece of kyc aml crypto payments regulation most likely to delay, freeze, or return a B2B payout in 2026, and most senders only learn about it after a payment is held. This guide explains what the Travel Rule is, how the 2026 rules differ by region, what data must accompany each payout, and how a regulated crypto gateway runs the checks so you don't have to build a compliance stack yourself.
What the crypto Travel Rule is (and why it now applies to your payouts)
The Travel Rule is an anti-money-laundering standard that requires identifying information about the sender (originator) and recipient (beneficiary) to "travel" alongside a transfer of value. It originated in traditional banking and now applies to crypto.
FATF Recommendation 16, extended to crypto
The rule comes from the Financial Action Task Force (FATF), whose Recommendation 16 was extended in 2019 to cover virtual assets. The principle is simple: when a regulated provider moves crypto on a customer's behalf, it must collect, transmit, and retain originator and beneficiary details so that law enforcement can trace funds. FATF recommendations are influential but not law in themselves — each jurisdiction decides how to implement them, which is why the picture is fragmented (more on that below).
Who counts as a VASP — and when you are the originator
The obligation falls on Virtual Asset Service Providers (VASPs): exchanges, custodial wallet providers, and crypto payment gateways. When your business initiates a payout through such a provider, the provider is the "originating institution" and carries the Travel Rule duty — but it can only meet that duty with your data. In practice this means the gateway must know who you are paying and why, and you must be able to supply recipient details on demand. The compliance burden is shared: the provider operates the machinery, but incomplete sender data is the most common reason a payout stalls.
The 2026 regulatory picture: crypto compliance and regulations by region
By 2026, over 50 jurisdictions have enacted Travel Rule legislation — roughly 73% of FATF-assessed jurisdictions, up from a far smaller base two years earlier. Enforcement maturity, thresholds, and required data still vary widely, so a payout that is routine in one corridor can be blocked in another.
EU — Transfer of Funds Regulation (TFR), no de-minimis threshold
The EU's recast Transfer of Funds Regulation (TFR) took effect on 30 December 2024. It is the strictest major regime: full originator and beneficiary data must accompany every crypto-asset transfer handled by a regulated provider, with no minimum threshold. A €5 payout and a €500,000 payout carry the same data obligation. The TFR operates alongside MiCA, the EU's broader crypto-asset framework, which governs licensing of providers.
US — Bank Secrecy Act Travel Rule, USD 3,000 threshold
In the United States the Travel Rule lives under the Bank Secrecy Act (BSA), administered by FinCEN, with a threshold of USD 3,000 — notably higher than FATF's recommendation. A 2026 development matters for stablecoin senders: following the GENIUS Act (signed July 2025), the U.S. Treasury proposed a rule on 8 April 2026 treating permitted stablecoin issuers as BSA financial institutions, subject to AML programs, recordkeeping, and the Travel Rule, with compliance expected around April 2027. The direction of travel is clear — stablecoin rails are being pulled fully into the same compliance perimeter as the banking system.
FATF global threshold and the "sunrise problem"
FATF recommends a standard threshold of USD/EUR 1,000, below which a reduced data set may apply. Because jurisdictions adopt the rule at different speeds, the industry faces the "sunrise problem": a compliant provider in a regulated market may need to send Travel Rule data to a counterparty in a market that has not yet implemented the rule and cannot receive it. For B2B senders this means a payout's success can depend on the recipient platform's jurisdiction, not just your own.
What data must "travel" with a B2B crypto payout
The required data set is consistent across regimes, even where thresholds differ.
Required originator (sender) fields
- Name of the originator (your business or the paying entity).
- Wallet address used for the transfer (or a transaction reference).
- Physical/registered address, and in some regimes an official identifier or account number.
Required beneficiary (recipient) fields
- Name of the recipient.
- Wallet address receiving the funds.
In addition, the transaction amount, execution date, and a unique transaction identifier are recorded with every transfer. For your operations, the practical takeaway is that recipient name + wallet must be accurate and verifiable before you send — a mismatch is a hold.
Self-hosted (unhosted) wallet payouts — the extra step
Paying out to a self-hosted (non-custodial) wallet — common when paying contractors or partners who hold their own keys — changes the mechanics. There is no counterparty VASP to receive the Travel Rule message, so the data isn't transmitted onward; instead, your provider must still collect originator and beneficiary information from you, and above the relevant threshold may require verification of wallet ownership based on a risk assessment. Expect to attest that the recipient controls the destination address for larger payouts.
How a regulated crypto gateway runs the Travel Rule on outbound payouts
This is where a regulated crypto gateway earns its keep. Rather than connecting to Travel Rule messaging protocols, screening providers, and sanctions lists yourself, the gateway runs the controls inside the payout flow. Using INXY's outbound model as a concrete example, an outgoing payout passes through several gates before any transfer is created.
Pre-send checks — address risk and blacklist screening
A payout starts as a withdrawal request, not an immediate send. A pre-send validation stage runs first and can stop the operation with an error so that no transaction is ever formed. As part of this, the recipient address is looked up against historical risk data: a previously unseen address is treated cautiously, while a known address carries its last risk result. This means a problematic payout is caught at draft stage, not after funds have left.
KYT/AML screening of the recipient
Next is the outbound KYT (Know Your Transaction) sequence. The recipient address is checked against a blacklist; a match fails the request outright with no transaction created. If it clears, a risk provider screens the address and returns an outcome:
- Low or Medium → the payout draft passes and proceeds.
- High → the request fails, no transaction is created, and an error is returned.
This is the kyc aml crypto payments layer working in real time on the money leaving your account.
The Travel Rule message exchange
Only after screening passes does the Travel Rule step run, packaging and exchanging the required originator/beneficiary information with the counterparty provider where one exists. The payout then proceeds to settlement. The sequence matters: screen first, transmit data, then send.
Approved contacts and recipient allow-lists
Gateways typically maintain a contact list of approved recipients. A recipient flagged as declined blocks the payout regardless of other checks — a useful control for finance teams that want a vetted, reusable set of payees for recurring or mass payouts.
KYB is the gate to the platform; KYT is the gate to each transaction; the Travel Rule is the data that rides along with it. A gateway that handles all three is what "secure crypto payments" actually means in operational terms.
Compliance risks of getting payouts wrong
For a B2B sender, Travel Rule failures are not abstract — they hit cash flow and counterparties directly:
- Held or returned transfers. Missing or mismatched recipient data is the most common cause of a stalled payout. Funds can sit in review or be returned, delaying contractor and supplier payments.
- Counterparty refusal. If the receiving platform can't accept Travel Rule data (the sunrise problem) or flags your transfer, it may bounce the payment.
- Regulatory exposure. Operating outbound flows without proper screening and recordkeeping exposes the business to AML penalties — increasingly so as stablecoin issuers are folded into BSA-style obligations.
- Operational drag. Building and maintaining screening, sanctions, and Travel Rule messaging in-house is expensive and never "done," because rules and thresholds keep shifting.
How to automate crypto payouts without owning the compliance stack
The practical answer for most B2B senders is to run payouts through a regulated crypto gateway that treats the Travel Rule, KYT, and sanctions screening as part of the payout itself — not as something you bolt on.
With INXY, every outbound payout passes through pre-send validation, blacklist and KYT risk screening, and the Travel Rule step before settlement, and recurring payees can be managed through an approved contact list. Because the same flow is exposed via API and webhooks, you can run mass payouts — paying hundreds of contractors or partners at once — with compliance checks applied per recipient automatically, and receive status events back into your own systems. That is what "how to automate crypto payouts" looks like when compliance is built in rather than improvised.
If compliance posture is your priority, start with INXY's security & compliance capabilities; if payout mechanics are the focus, see crypto payouts and the cross-border and payroll options that build on the same rails.
FAQ
Does the Travel Rule apply to stablecoin payouts? Yes. Stablecoin transfers handled by a regulated provider are subject to the Travel Rule like any other virtual asset. In the EU, full data is required regardless of amount; in the US, stablecoin issuers are being brought explicitly into BSA Travel Rule obligations under a rule proposed in April 2026.
What is the Travel Rule threshold in 2026? It depends on the jurisdiction. FATF recommends USD/EUR 1,000; the US applies USD 3,000 under the BSA; the EU applies no threshold — every transfer carries full data.
Do I need to collect data for self-hosted (unhosted) wallet payouts? Yes. Even though there's no counterparty provider to receive the message, your gateway must still collect originator and beneficiary information, and above the relevant threshold may require proof that the recipient controls the destination wallet.
Is the Travel Rule the same as KYC? No. KYC/KYB verifies identity at onboarding. The Travel Rule governs the transmission of identity data alongside each transfer. They work together but are distinct obligations.
Who is responsible — the sender or the recipient platform? Both sides carry obligations. The originating provider must collect and transmit sender/recipient data; the beneficiary provider must receive and retain it. As the business initiating the payout, you're responsible for supplying accurate recipient information to your provider.
