Travel Rule for stablecoin payins: what businesses need to know in 2026

The Travel Rule requires regulated entities to pass sender and recipient information along with qualifying transfers. It applies to the entities that facilitate the transfer, not to every business that receives a payment. A business that uses a compliant payin provider usually relies on that provider to exchange this data, while it keeps its own customer records accurate.

A payin is fiat coming in, such as a bank transfer, with stablecoins going out to a wallet. A stablecoin is a token pegged to a currency such as the US dollar. This page covers the payin side. For the off-ramp side, see the Travel Rule for stablecoin off-ramps.

Key takeaways

• The Travel Rule comes from FATF Recommendation 16 and binds regulated providers, so most payin businesses depend on their provider for it.
• Thresholds differ: $3,000 in the US, no minimum between crypto-asset service providers in the EU.
• The data that travels is a short list: names, account or wallet identifiers, and more detail above the threshold.
• A payin delivered to a self-hosted wallet has no counterparty provider, so the provider relies on its own customer records instead.
• Ask your provider exactly which checks it runs and what happens when data is missing.

What is the Travel Rule?

The Travel Rule is a payment transparency rule. FATF Recommendation 16 says that when money moves between financial institutions, originator and beneficiary information must move with it. FATF applied the same logic to virtual assets in 2019, so a provider that sends a stablecoin transfer must pass details of both parties to the receiving provider.

It exists so that authorities can trace funds and so that each institution in the chain knows who it is dealing with. It sits next to, not instead of, customer checks and sanctions screening. For how the checks differ, see KYC vs KYB vs KYT and KYC and KYB for stablecoin payins.

Who does it apply to?

It applies to regulated providers that move virtual assets or funds: in the US, money transmitters that register with FinCEN as money services businesses; in the EU, crypto-asset service providers (CASPs) and payment providers under Regulation (EU) 2023/1113. In FATF terms these are virtual asset service providers, or VASPs. See what a VASP is.

It does not usually apply directly to an ordinary business that receives payments through a provider's API. That business is the provider's customer. The provider carries the transfer-layer duty. This is a general pattern and not a guarantee. If your business itself transmits value for others, you may be a regulated provider too. Ask counsel.

Two payin cases matter in practice:

1. The payer pays by bank transfer. The bank payment carries its own originator and beneficiary data under the rules of that rail, and the provider converts the funds to stablecoins after the deposit lands.
2. The provider sends stablecoins to the customer's wallet. If that wallet is hosted by another provider, data is exchanged between providers. If it is a self-hosted wallet the customer controls, no counterparty exists and the provider relies on its own records of that customer.

What are the thresholds in the US and EU?

In the US the threshold is $3,000, and in the EU there is no minimum for transfers between crypto-asset service providers. FATF itself recommends USD or EUR 1,000, and each country sets its own number. Thresholds change, so check the date.

A common mistake is to read the EU's EUR 1,000 as a de minimis threshold for the rule. It is not. In the EU the data travels on every transfer between CASPs. The EUR 1,000 figure concerns what the provider must verify when the other side is a self-hosted wallet.

Other countries have their own versions, including the UK, Singapore and Brazil. The off-ramp article above has a snapshot, and you should confirm each market before you launch.

What information must travel with a payment?

A short, fixed set of fields travels with the transfer. The details vary by country, but the pattern below follows FATF's model and the EU regulation.

Providers exchange this data over messaging networks built for the purpose, often using a common data format called IVMS 101. The blockchain transaction itself carries none of it. The data moves beside the transfer. For the receiving side, the provider must check the data and keep it.

For a stablecoin payin, much of this data begins as your customer's KYC or KYB record. If that record is wrong or thin, the transfer layer has nothing good to pass on. That is why your own onboarding quality matters even when you do not run the Travel Rule yourself.

How does a payin API handle it?

A payin API handles it by tying every payin to a verified customer, screening and monitoring the transfer, and holding anything that cannot be cleared. Exactly which messages a provider exchanges, and with whom, depends on its licenses and its network connections, so that detail belongs in your contract.

Here is what BlindPay's docs say about the compliance steps around a payin:

1. A customer must complete KYC or KYB before it can have a payin. The customer record holds name, address and ID data.
2. For some payment methods, BlindPay asks for payer identity details so it can match and screen the deposit. For Pix, pix_allowed_tax_ids lists the CPF or CNPJ tax IDs allowed to send. For PSE in Colombia, full payer details are required.
3. For international wires into a virtual account, the payin reports sender_name, sender_bank_name, sender_account_number and a transaction_reference from the payer.
4. BlindPay's transaction monitoring can flag a payin. It then moves to on_hold for manual review. If the flag cannot be cleared, BlindPay sends a request for information about the sender, the purpose and the expected outcome. Without an answer in 24 hours, the transaction may be refunded to the sender.
5. Holds can take up to 30 days to resolve. Approval resumes the flow, and a timeout without a decision fails the transaction.

The BlindPay docs do not describe a Travel Rule messaging step for payins, and this page does not claim one. For that exact question, ask BlindPay's compliance team. Related: the Travel Rule in an automated workflow covers when a workflow should collect, hold, return or reject.

Destination also changes the picture. A payin can deliver to an external blockchain wallet the customer controls, or to an optional BlindPay-managed wallet (beta). Whether the Travel Rule data flows to another provider depends on where the stablecoins end up, which is one more reason to say which destination you use when you ask your provider.

What should I ask my provider?

Ask for specifics and write down the answers with the date. Use this list.

1. Which licenses do you hold in the countries where my payers and customers are, and does the Travel Rule duty sit with you for payins?
2. Which Travel Rule network or protocol do you use, and for which transfers?
3. What do you do when the destination is a self-hosted wallet? Do you verify that my customer controls it?
4. What data do you need from me about each customer, and in what format?
5. What happens to a payin when data is missing: hold, return, reject or refund? How long can it take?
6. How do I find out about a hold: webhook, email or dashboard?
7. Can I export an audit trail of checks and decisions for a regulator or a bank partner?
8. Do your answers change by chain, token or country?

Where does BlindPay fit?

BlindPay is payment infrastructure for stablecoin payins and payouts, with KYC, KYB and transaction monitoring in the same flow. Per its docs, a customer must be verified before it can have payins, monitoring can place a payin on hold, and a payin that fails review can be refunded. The facts above are what the docs state.

BlindPay offers payins that deliver to an external blockchain wallet the customer controls, or to an optional BlindPay-managed wallet (beta). Read the what is a stablecoin payin API overview for the full model, and the step-by-step payin guide to see where each check sits. More on BlindPay's controls is on the compliance page and in the KYC docs and on-hold transaction docs.

Sources

• FATF, Update to Recommendation 16 on payment transparency (June 2025): https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html (checked on 2026-10-22)
• eCFR, 31 CFR 1010.410, Records to be made and retained by financial institutions: https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/subpart-D/section-1010.410 (checked on 2026-10-22)
• FinCEN, Application of FinCEN's Regulations to Certain Business Models Involving Convertible Virtual Currencies: https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-certain-business-models (checked on 2026-10-22)
• EUR-Lex, Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets: https://eur-lex.europa.eu/eli/reg/2023/1113/oj (checked on 2026-10-22)
• BlindPay docs: /docs/kb/kyc, /docs/kb/on-hold-transactions, /docs/payins, /docs/payin-quotes

This article is general information, not legal advice.