FATF Travel Rule for Crypto Compliance 2026: What VASPs Must Do
FATF Travel Rule: the $1,000 threshold, zero-threshold jurisdictions, and which vendors support TRP and OpenVASP natively. Full 2026 compliance guide.
Crypto exchanges and custodians face a compliance requirement that most traditional AML platforms were not built for: before settling a crypto transfer, they must collect and transmit structured data about who sent the funds and who is receiving them. This is the FATF Travel Rule, and it creates a category of vendor capability that matters a lot in procurement and almost never appears in product demos.
TL;DR
- FATF Recommendation 16 extends traditional wire transfer data requirements to Virtual Asset Service Providers, with a typical threshold of around $1,000 USD per transfer
- Some jurisdictions apply a zero-threshold variant: the rule applies from the first dollar of any transfer, with no minimum-value exemption
- Of the vendors covered here, Sumsub and ComplyCube have native Travel Rule support via TRP and OpenVASP; SwiftDil and RegTechONE do not
- Protocol interoperability is the real technical challenge: a vendor that only supports one protocol creates compliance gaps whenever a counterparty VASP uses a different one
What the FATF Travel Rule actually requires
The FATF Travel Rule requires a crypto exchange or custodian to collect and transmit originator and beneficiary information before or alongside any transfer that clears the applicable threshold. It’s Recommendation 16, the decades-old wire-transfer rule, applied to virtual assets.
FATF Recommendation 16 has governed bank wire transfers since 1989: the originating bank transmits the sender’s name, account number, and address to the receiving bank along with the payment, and the receiving institution keeps that data and passes it on if the funds move again.
In June 2019, FATF extended the same framework to virtual assets. The rule now applies to Virtual Asset Service Providers (VASPs): entities that exchange, transfer, safeguard, or administer virtual assets on behalf of clients. That covers crypto exchanges, custodians, and certain wallet providers acting as intermediaries.
The specific obligation: before or simultaneously with a transfer, the originating VASP must transmit the following to the beneficiary VASP:
- Originator name
- Originator account number (the wallet address or equivalent)
- Originator physical address, national identity number, or date and place of birth
- Beneficiary name
- Beneficiary account number
The beneficiary VASP must collect this data and make it available to regulators on request. Neither party can process the transfer as a clean movement of value without handling the accompanying data requirement.
The mechanism that makes this hard is the word “transmit.” Wire transfers go through a correspondent banking system that already carries message fields for this data. Crypto transfers go directly on-chain, so there is no message envelope. The data must travel through a separate, off-chain channel, and both VASPs need to be using compatible systems for that channel to work.
The $1,000 Travel Rule threshold
Most FATF member jurisdictions set the Travel Rule threshold at around $1,000 USD (or the local equivalent) per transfer. Below that value, a transfer is typically exempt from the originator and beneficiary data transmission requirement, though basic AML screening still applies.
“Typically” is the operative word. FATF’s own guidance gives jurisdictions flexibility in setting their thresholds, and harmonization across member states is incomplete. For a compliance team running exchanges across several markets, that turns the threshold question into jurisdiction-by-jurisdiction analysis rather than one global configuration.
What is the zero-threshold Travel Rule?
Some jurisdictions apply the Travel Rule from the first dollar of a transfer, with no minimum-value exemption at all. For an exchange operating across borders, the rule that governs a given transaction is the stricter of the two regimes involved: a transfer that would sit below the $1,000 threshold domestically can still trigger full Travel Rule obligations if the counterparty VASP is domiciled in a zero-threshold jurisdiction.
That asymmetry is where exchanges that assume $1,000 is a universal floor get caught out. A $200 transfer to a counterparty VASP in a zero-threshold jurisdiction isn’t exempt the way the same transfer would be domestically, and a system wired to trigger data collection only above $1,000 will simply miss it.
The safer build is to collect originator and beneficiary data on every VASP-to-VASP transfer regardless of value, then use threshold logic only to size the minimum required data set. It’s more data to handle, but it closes the jurisdiction-edge-case gap at the counterparty level rather than hoping it doesn’t come up.
TRP, OpenVASP, and the protocol interoperability gap
Because crypto transfers carry no native message envelope for Travel Rule data, the industry built off-chain messaging protocols to handle the data exchange between VASPs. Two protocols have the widest adoption among compliance vendors:
TRP (Travel Rule Protocol) is a REST-based messaging standard developed by a consortium that includes major exchanges. It uses HTTPS for data exchange between VASPs, with a discovery mechanism that lets one VASP find the other’s TRP endpoint and open an encrypted channel. The Travel Rule Protocol Group maintains the standard, and most enterprise compliance vendors have built support for it.
OpenVASP is an open-source protocol specification designed to operate without a central intermediary. It uses Ethereum’s Whisper messaging layer (and later adaptations) for VASP-to-VASP communication, avoiding dependency on any single service provider. That decentralized structure is the whole pitch: no vendor sits in the middle of the data flow, which matters to compliance teams wary of routing personal data through a third party they don’t control.
The interoperability problem is straightforward: if exchange A uses TRP and exchange B uses OpenVASP, the two cannot exchange Travel Rule data without a bridge between the protocols. This is the gap that makes compliance vendors’ protocol support lists more than a checkbox exercise.
A vendor that lists “Travel Rule support” in its feature table but implements only one protocol will encounter counterparty coverage gaps in real deployments. The question to ask in a vendor evaluation is not “do you support the Travel Rule?” but “which specific protocol versions do you implement, and what is your process when a counterparty VASP is not reachable via any of those protocols?”
Some compliance platforms route through intermediary networks that handle protocol translation, but this introduces a third party into data flows that regulators may scrutinize.
Vendor Travel Rule support: what the AML directory shows
The comparison below covers the four AML vendors most directly relevant to this question based on the PrimeBiometry AML vendor directory. Assessment is based on published documentation and the confirmed capabilities in the directory data.
| Vendor | Travel Rule support | Protocols | Primary AML focus |
|---|---|---|---|
| Sumsub | Native | TRP, OpenVASP | Full-stack KYC + AML, crypto and fiat |
| ComplyCube | Native | TRP, OpenVASP | EU/UK regulated platforms, GDPR-native |
| SwiftDil | Not offered | N/A | Fiat AML screening, KYC, PEP/sanctions |
| RegTechONE | Not offered | N/A | Fiat transaction monitoring, rule-based |
Sumsub is the only vendor in this directory that treats Travel Rule as a core product feature rather than an integration layer. The Travel Rule module sits within Sumsub’s broader compliance platform, sharing the same case management interface as KYC and transaction monitoring. For a crypto exchange that wants KYC, AML, and Travel Rule from one API contract, Sumsub is the most direct answer. The tradeoff is cost: Sumsub’s per-check pricing and bundled module structure means you pay for the full stack even if parts of it overlap with existing tools.
ComplyCube supports TRP and OpenVASP natively and is the stronger choice for EU-regulated buyers. GDPR-native data residency and explicit EU data infrastructure make it the practical option for crypto platforms licensed under MiCA or operating under national transpositions of EU AML directives. Pricing is custom and contact-based, which means the Travel Rule module cost is negotiated as part of the broader contract.
SwiftDil and RegTechONE are both capable fiat AML platforms with solid PEP, sanctions, and adverse media screening. Neither currently offers built-in Travel Rule routing. For crypto exchanges, that means a separate Travel Rule solution is required alongside either of these platforms, adding integration complexity and an additional vendor contract to manage.
On Ondato: Ondato bundles KYC, KYB, and Know Your Transaction (KYT) in one contract and holds MiCA compliance certification, making it relevant for EU-regulated crypto-adjacent buyers. Travel Rule routing specifics are not confirmed in publicly available Ondato documentation, so it should be evaluated on its KYT and MiCA credentials rather than assumed to cover Travel Rule protocol implementation.
For crypto exchanges with significant on-chain transaction volume, dedicated blockchain analytics providers (Chainalysis, TRM Labs, Elliptic) handle the KYT and on-chain investigation layer. Most enterprise AML programmes at exchanges layer one of these on top of a core AML platform rather than expecting a single platform to handle everything from wallet screening to Travel Rule messaging. For the full vendor shortlist and VASP registration requirements by jurisdiction, see best KYC software for crypto exchanges 2026.
How to evaluate Travel Rule vendor support before you buy
The gap between “Travel Rule capable” in a feature list and actual production-ready implementation is wider than it is for most compliance features. These are the questions that surface the difference.
Protocol version and counterparty network. Ask which specific versions of TRP and OpenVASP the vendor implements. Ask for the vendor’s counterparty VASP network: how many VASPs are discoverable through their protocol implementation? A small network means more gaps in real transactions.
What happens when the counterparty VASP is unreachable. Some counterparties are in jurisdictions with no compliant Travel Rule infrastructure. Ask whether the vendor has a documented process for sunrise period transfers, where the receiving VASP cannot yet accept Travel Rule data, and whether that process creates a compliance record or simply drops the data requirement.
Unhosted wallet handling. If your exchange processes transfers to self-custodied wallets, confirm the vendor’s approach. There is no VASP counterparty to exchange Travel Rule data with on those flows, so the compliance requirement shifts to enhanced due diligence on the originator side. Ask whether the platform has tooling for this or whether it simply excludes unhosted wallet flows from Travel Rule scope.
Data storage and retention. Travel Rule data includes personal information about both originator and beneficiary. Ask where this data is stored, what the retention period is, and whether storage is configurable to match your data residency obligations. EU buyers should confirm the data never leaves EU infrastructure.
Audit trail for regulators. When a regulator requests Travel Rule records, the platform needs to produce a complete record of what data was transmitted, when, to which counterparty, and through which protocol. Ask for a sample export or audit report format before signing a contract.
Compare AML vendors with Travel Rule capabilities side by side on the AML compliance vendor directory.
FAQ
What is the FATF Travel Rule for virtual assets? The FATF Travel Rule extends the wire transfer requirements of FATF Recommendation 16 to virtual assets. Virtual Asset Service Providers, including crypto exchanges, custodians, and certain wallet providers, must collect and transmit originator and beneficiary information for transfers that exceed local thresholds, which typically sit around $1,000 USD, before or simultaneously with the transfer.
What is the zero-threshold Travel Rule variant? Some jurisdictions apply the Travel Rule from the first dollar of a transfer, with no minimum-value exemption. This contrasts with the roughly $1,000 threshold used in most FATF-aligned regimes. For exchanges processing transfers across multiple jurisdictions, the operative rule is the stricter of the two: a transfer under $1,000 that would be exempt in one jurisdiction may still trigger full Travel Rule obligations when the counterparty VASP is domiciled where the zero-threshold rule applies.
Which compliance vendors support the FATF Travel Rule natively? Of the vendors in the PrimeBiometry AML directory, Sumsub and ComplyCube support Travel Rule workflows natively via TRP and OpenVASP protocols. SwiftDil and RegTechONE focus on traditional fiat AML screening and do not currently offer built-in Travel Rule routing. For crypto exchanges with significant on-chain volume, dedicated blockchain analytics providers are typically layered on top of a core AML platform rather than replacing it.
What is TRP and how does it differ from OpenVASP? TRP (Travel Rule Protocol) is a messaging standard developed by major crypto exchanges to handle Travel Rule data exchange between VASPs. OpenVASP is an open-source protocol framework designed to avoid vendor lock-in and enable direct VASP-to-VASP messaging without a central intermediary. Both address the same interoperability problem: enabling two VASPs using different compliance systems to exchange originator and beneficiary data before a transfer settles. Most enterprise compliance vendors publish support for both protocols, but implementation depth varies.
Does the FATF Travel Rule apply to unhosted wallets? FATF guidance classifies transfers involving unhosted wallets as higher risk, but the Travel Rule obligation falls on the VASP side of the transaction. In practice, a VASP processing an outbound transfer to an unhosted wallet must still collect originator information; for inbound transfers from unhosted wallets, enhanced due diligence applies. The core difficulty is that there is no VASP counterparty to exchange Travel Rule data with, so automated protocol-based solutions do not cover these flows.
James Whitfield is an independent researcher and mobile app developer who built PrimeBiometry after evaluating KYC and AML vendors for integration work and finding no reliable source for pricing, protocol support, and compliance certification data in one place. Coverage is based on public documentation, API references, and aggregated review data, not vendor briefings. About the author and methodology.