Any U.S. virtual asset service provider moving crypto above the applicable recordkeeping threshold must collect, verify, and transmit identifying information about both the sender and recipient before the transaction settles. That is the Travel Rule in one sentence. The rule’s formal name in international standards is FATF Recommendation 16, extended to virtual assets in 2019, and it sits at the intersection of anti-money laundering law, data privacy, and real-time payment infrastructure. For U.S. compliance leads, the binding enforcement touchpoint is the Bank Secrecy Act and FinCEN’s recordkeeping rules at 31 CFR 1010.410, not FATF itself, which is a standard-setting body without direct legal authority in the U.S.
The core obligations, per FATF and Notabene’s operational guidance, break down as follows:
- Collect full originator and beneficiary information before or at the time of transfer.
- Verify that information against reliable sources, with depth proportional to risk and threshold.
- Transmit the data to the receiving VASP simultaneously with or before the transfer.
- Retain records for a minimum of five years.
- Screen both parties against sanctions lists before transmission.
The principal authorities and standards shaping U.S. compliance are FATF (global standard-setter), FinCEN under the BSA (U.S. enforcement authority), and IVMS101 (the data schema that defines exactly which fields travel with each transaction).
Key Takeaways
The Travel Rule requires U.S. VASPs to collect, verify, transmit, and retain IVMS101-formatted originator and beneficiary data for virtual-asset transfers at or above the BSA recordkeeping threshold, with FATF’s June 2025 revisions adding fraud-prevention tooling as an explicit compliance expectation.
Table of Contents
- What is the travel rule for crypto, and where does it come from?
- Who must comply in the U.S., and what about edge cases?
- What data must travel with each transaction?
- How do thresholds work, and what are the common misconceptions?
- How is Travel Rule data actually exchanged between VASPs?
- Operational checklist for U.S. VASPs: from policy to audit readiness
- What are the biggest risks, and how do you mitigate them?
- Enforcement risk and where to find official U.S. guidance
- What FATF’s June 2025 revisions mean for your compliance program
- The gap between policy and practice in U.S. Travel Rule programs
- Primary sources and further reading
- Sources
What is the travel rule for crypto, and where does it come from?
The Travel Rule predates crypto by decades. FinCEN introduced it for traditional wire transfers in 1996 under the BSA, requiring banks to pass originator and beneficiary data along the payment chain. The name comes from the idea that identifying information must “travel” with the funds. FATF extended the same logic to virtual assets in June 2019 when it revised Recommendation 16 to explicitly cover VASPs, creating the first global AML standard for crypto transfers.
That 2019 revision was significant because it treated crypto exchanges and custodians the same as banks for purposes of payment transparency. FATF’s virtual-assets guidance asks the sector to develop the technology and risk-based approaches needed to collect, transmit, and secure originator and beneficiary information at scale. The guidance also covers licensing, suspicious-activity detection, and how to apply a risk-based approach without excluding low-income users from financial services.
In the U.S., the legal lineage runs through the BSA. FinCEN has not yet issued a final crypto-specific Travel Rule rule, but it has enforced BSA recordkeeping failures against virtual-currency businesses and issued advisory guidance on AML vulnerabilities in the sector. The BSA wire-transfer recordkeeping rule at 31 CFR 1010.410 is the operative U.S. standard today. Compliance teams should monitor FinCEN rulemaking dockets on Regulations, particularly FINCEN-2020-0002 and FINCEN-2020-0020, where threshold proposals and public comments illuminate the likely direction of U.S. crypto-specific rules.
The EU moved faster and harder. Its Transfer of Funds Regulation (TFR, Regulation 2023/1113) applies a zero-threshold approach, meaning EU crypto asset service providers (CASPs) must accompany every crypto transfer with full originator and beneficiary data regardless of amount. For U.S. VASPs with EU counterparties, that zero-threshold standard effectively becomes the operational floor for those flows. The CLARITY Act discussion illustrates how far U.S. legislative efforts still lag behind EU frameworks like MiCA.
Who must comply in the U.S., and what about edge cases?
Under U.S. law, the Travel Rule applies to “money transmitters” as defined by the BSA, which FinCEN has confirmed includes businesses that exchange or transmit virtual currency. The term “VASP” comes from FATF; the U.S. equivalent is a crypto money services business (MSB) or money transmitter. If your business accepts and transmits virtual currency on behalf of customers, you are almost certainly in scope.
In-scope activities include:
- Centralized exchanges that execute customer trades and withdrawals.
- Custodial wallet providers that hold private keys on behalf of users.
- OTC desks that settle trades by moving funds between counterparty accounts.
- Payment processors that convert crypto to fiat or vice versa for merchants.
- Lending platforms that move customer funds to fund or repay loans.
The harder edge cases require judgment:
Self-hosted (non-custodial) wallets. A user sending from their own wallet to an exchange is not a VASP. The receiving exchange, however, must still attempt to collect originator information. FATF guidance calls for a risk-based approach when the counterparty is a self-hosted wallet, which in practice means enhanced due diligence on the customer and documentation of the wallet ownership claim.
OTC desks operating as principals. An OTC desk that buys and sells crypto as a principal (for its own account) may argue it is not transmitting funds on behalf of a customer. FinCEN’s guidance has not fully resolved this, so legal review is warranted before concluding an OTC operation is out of scope.
Bridging and cross-chain services. Protocols that move assets across blockchains are an unsettled area. If the service takes custody at any point, most AML counsel treat it as in scope.
Pro Tip: When you cannot confirm whether a counterparty is a registered VASP or MSB, check FinCEN’s MSB Registrant Search and FATF’s VASP registry resources before processing the transaction. Treating an unverified counterparty as a non-VASP and applying enhanced due diligence is safer than assuming VASP status and skipping verification.
What data must travel with each transaction?
Chainalysis defines the Travel Rule as the application of FATF Recommendation 16 to virtual assets, requiring VASPs to collect, transmit, and retain originator and beneficiary information for qualifying transfers. The specific fields are mapped in IVMS101 (Interoperability Message Standard for Virtual Asset Service Providers, version 1.01), the data schema developed by the Joint Working Group on interVASP Messaging Standards.
Required originator fields
Required beneficiary fields
The “OR” logic on the third field is intentional. FATF allows a choice between physical address, national ID, or date and place of birth to reduce friction in markets where street addresses are unreliable. IVMS101 encodes this as an anyOf constraint.
Verification depth scales with risk. Below the applicable threshold, reduced data sets may be acceptable. Above the threshold, full verification against a reliable source (government-issued ID, utility bill, or equivalent) is expected. For higher-risk customers or jurisdictions, enhanced due diligence applies regardless of amount.
Pro Tip: Build your data model around IVMS101 from day one, even if your current counterparties use a proprietary format. Every major protocol (TRISA, OpenVASP) and most vendor hubs translate to and from IVMS101. Starting with the standard schema means you will not need to rebuild when you add counterparties.
How do thresholds work, and what are the common misconceptions?
The FATF baseline threshold is USD/EUR 1,000. Transfers at or above that amount must carry full originator and beneficiary data. Below it, reduced data sets may suffice, though FATF still expects basic originator information.
In the U.S., the operative threshold under the BSA’s recordkeeping rule is $3,000 for wire transfers, and FinCEN has applied that same $3,000 standard to virtual-currency transmittals in its guidance. That gap between $1,000 (FATF) and $3,000 (U.S.) creates a practical question: should U.S. VASPs apply the lower FATF threshold when transacting with EU or other counterparties that operate at $1,000 or zero? The answer is yes, because the receiving jurisdiction’s rules govern what data the receiving VASP needs, even if the sending VASP’s domestic law sets a higher threshold.
A few misconceptions come up repeatedly:
- The $10,000 CTR threshold does not apply here. Currency Transaction Reports are a separate BSA obligation. The Travel Rule threshold for wire transfers is $3,000, not $10,000.
- Domestic transfers are not exempt. The BSA’s recordkeeping rule applies to domestic transmittals above $3,000, not just cross-border ones.
- Zero-threshold does not mean zero verification. Even below the threshold, basic originator information (name and account number) should accompany the transfer as a best practice and is required in some jurisdictions.
- Aggregation rules matter. Multiple transfers that appear structured to stay below the threshold can trigger suspicious-activity reporting obligations independent of the Travel Rule.
For threshold policy settings, compliance teams should:
- Apply the lower of the sending or receiving jurisdiction’s threshold to each transaction.
- Document the threshold logic in your AML policy so examiners can follow the reasoning.
- Build threshold-aware logic into your transaction monitoring system so sub-threshold transfers still capture basic data.
How is Travel Rule data actually exchanged between VASPs?
The technical challenge of the Travel Rule is that two VASPs must exchange sensitive personal data before or simultaneously with a blockchain transaction that is, by design, pseudonymous. Three broad architectures address this.
Direct bilateral messaging
Two VASPs establish a direct API connection and exchange IVMS101-formatted data peer-to-peer. This works well for high-volume counterparty pairs but does not scale to hundreds of counterparties. It also requires each party to maintain API credentials and>Hub and translator models
A central hub (sometimes called a “Travel Rule solution provider”) acts as an intermediary. Each VASP connects once to the hub, which routes messages to counterparties and translates between data formats. Notabene and similar platforms operate in this space. The trade-off is that a hub introduces a third party into a sensitive data flow, which requires careful>Protocol-based approaches
TRISA (Travel Rule Information Sharing Architecture) is a decentralized, PKI-based protocol that allows VASPs to discover each other’s endpoints and exchange encrypted IVMS101 payloads without a central intermediary. TRISA uses a directory service (TRISA Global Directory Service) for VASP discovery and mutual TLS for transport security.
OpenVASP is an open-source protocol that uses Ethereum’s Whisper/Waku messaging layer for peer-to-peer VASP communication. It emphasizes decentralization and avoids reliance on any single directory or hub. Adoption has been narrower than TRISA, but it remains an option for teams that want a fully open-source stack.
IVMS101 is the data schema across all four models. It is not a protocol; it defines the fields and their encoding (JSON-LD). Whatever messaging layer you choose, the payload should conform to IVMS101 so counterparties can parse it without custom integration.
Vendor roles in a typical Travel Rule stack:
- KYC/KYB providers (e.g., Sumsub): collect and verify originator and beneficiary identity documents.
- Screening providers (e.g., Elliptic): screen wallet addresses and counterparties against sanctions lists and risk scores.
- Messaging/protocol layer (e.g., TRISA, Notabene): handle the secure transmission of IVMS101 payloads between VASPs.
- Blockchain analytics: provide transaction tracing and on-chain transparency to support post-transaction monitoring.
Pro Tip: Before selecting a hub vendor, ask for their data residency and sub-processor list. IVMS101 payloads contain PII subject to GDPR, CCPA, and other privacy regimes. A hub that stores message data in a jurisdiction your customers did not consent to can create a separate compliance liability.
Operational checklist for U.S. VASPs: from policy to audit readiness
Getting to production-ready Travel Rule compliance is a four-phase program. Most teams underestimate the governance and testing phases and overestimate how long the technical build takes once the architecture decision is made.
Phase 1: Governance and policy (weeks 1–4)
- Assign a Travel Rule program owner (typically the BSA Officer or Chief Compliance Officer).
- Update your AML/BSA policy to explicitly address virtual-asset transmittal recordkeeping, threshold logic, and counterparty due diligence.
- Conduct a risk assessment covering your transaction volume, counterparty mix, and jurisdictions served.
- Identify all business lines and products that transmit virtual assets on behalf of customers.
- Draft a>Phase 2: Technical build and vendor selection (weeks 4–12)
- Select a messaging architecture (direct bilateral, hub, or protocol) based on your counterparty volume and privacy requirements.
- Integrate your KYC provider’s API to pull verified originator data at the point of withdrawal or transfer initiation.
- Map your internal customer data model to IVMS101 fields and identify gaps (missing address fields, no DOB capture, etc.).
- Integrate sanctions screening for both originator and beneficiary before transmission.
- Build a counterparty VASP registry: confirm which counterparties are registered MSBs and which are unhosted wallets.
Phase 3: Pilot and testing (weeks 12–16)
- Run end-to-end tests with at least two counterparties covering both sending and receiving flows.
- Test threshold logic: confirm sub-threshold transfers capture basic data and above-threshold transfers trigger full IVMS101 payloads.
- Test failure scenarios: what happens when a counterparty does not respond, returns an error, or is not a registered VASP?
- Review vendor contracts for SLA commitments on message delivery, data retention, and breach notification.
Phase 4: Go-live and audit readiness (weeks 16–20+)
- Enable Travel Rule data collection and transmission in production, initially for a subset of counterparties.
- Implement a retention policy: IVMS101 payloads and associated records must be retained for five years under BSA rules.
- Schedule a quarterly internal audit of Travel Rule records: sample transactions, verify data completeness, and document findings.
- Establish a process for handling unresolved transfers (where counterparty data cannot be obtained) including escalation to the BSA Officer and, where required, suspicious-activity reporting.
The most common gap teams discover at audit: they collected the data but cannot produce a complete, timestamped record of what was transmitted, to whom, and when. Build that audit log from day one.
What are the biggest risks, and how do you mitigate them?
Travel Rule compliance introduces risks that sit outside traditional AML programs. The three that cause the most operational pain are data privacy exposure, misdirected payments from inaccurate beneficiary data, and interoperability failures with uncooperative counterparties.
Privacy and cross-border data transfer. IVMS101 payloads contain full name, address, and government ID numbers. Transmitting that data to a foreign VASP triggers GDPR (for EU residents), CCPA (for California residents), and potentially other privacy regimes. The mitigation is end-to-end encryption of payloads, data minimization (send only the fields required by the receiving jurisdiction), and explicit target="_blank" rel="noopener">financial privacy implications of identity-sharing rules in digital assets are an active area of industry debate.
Misdirected payments from bad beneficiary data. If a beneficiary’s wallet address does not match the name on the IVMS101 payload, the transfer may reach the wrong person or a sanctioned address. Sanctions screening of the beneficiary wallet address before transmission is the primary control. Blockchain analytics tools that score wallet addresses against known illicit clusters add a second layer.
Interoperability failures. Not every VASP uses the same protocol or even supports Travel Rule messaging. When a counterparty cannot receive IVMS101 data, you have three options: hold the transfer, apply enhanced due diligence and document the gap, or decline the transaction. Your AML policy should specify which option applies in which scenario.
Financial inclusion trade-offs. Strict verification requirements can exclude customers who lack government-issued ID or a fixed address. CGAP has noted that FATF does not intend the Travel Rule to harm financial inclusion, and its guidance explicitly supports risk-based approaches that preserve low-cost access for retail customers. In practice, this means calibrating verification depth to transaction risk rather than applying maximum verification to every transfer regardless of amount.
For end-users navigating crypto payments in real-world contexts, the compliance overhead can affect the cost and speed of transactions. Services that accept crypto payments for everyday use are increasingly subject to the same Travel Rule obligations as exchanges, which shapes how those services design their onboarding and verification flows.
Pro Tip: Document every “hold” or “decline” decision with a timestamp, the reason, and the data you did or did not receive. FinCEN examiners look for evidence that your process is consistent and auditable, not just that you have a policy on paper.
Enforcement risk and where to find official U.S. guidance
FinCEN has not yet issued a final rule specifically calibrating the Travel Rule to crypto, but it has enforced BSA recordkeeping failures against virtual-currency businesses under existing authority. Civil money penalties for willful BSA violations can reach $1,000,000 per day of violation or the amount of the transaction, whichever is greater, under 31 U.S.C. § 5321. Recordkeeping failures, including failure to collect or retain originator and beneficiary information, fall squarely within that enforcement authority.
FinCEN’s advisory on virtual-currency AML risks identifies the specific vulnerabilities examiners look for: inadequate customer identification, failure to file suspicious activity reports, and lack of transaction monitoring. Compliance teams should treat this advisory as an examiner’s checklist.
Where to monitor U.S. rulemaking:
- FinCEN’s website (fincen.gov): guidance documents, enforcement actions, and regulatory updates.
- Regulations.gov dockets FINCEN-2020-0002 and FINCEN-2020-0020: threshold proposals and public comments on virtual-currency recordkeeping.
- Federal Register: final rules and notices of proposed rulemaking from FinCEN.
- FinCEN Exchange: a public-private information-sharing program where FinCEN shares typologies and emerging risks with financial institutions.
The documentation standard that reduces enforcement risk most reliably is a complete, timestamped audit trail for every Travel Rule decision: what data was collected, what was transmitted, to which counterparty, at what time, and what happened when data was missing or a counterparty was unresponsive. Examiners can work with a documented gap; they cannot work with no record at all.
What FATF’s June 2025 revisions mean for your compliance program
FATF’s June 2025 update to Recommendation 16 reframes the Travel Rule beyond pure AML. The revisions standardize the required information fields in payment messages, assign clearer responsibilities across the payment chain, and add an explicit requirement for tools that protect against fraud and error in transfers above USD/EUR 1,000. That last point is new: fraud prevention was not a named objective of the original 2019 VASP extension.
The practical implications for U.S. VASPs are three:
Verification tooling is now an expectation, not a nice-to-have. The 2025 revisions expect VASPs to use technology to verify that beneficiary account details are accurate before transmission. That means wallet-ownership verification tools, not just name-and-address collection. Sumsub and similar identity-verification platforms are increasingly integrating wallet-proof features to meet this expectation.
Clearer chain-of-responsibility. The revisions clarify which party in a multi-hop payment chain is responsible for ensuring data travels with the funds. For U.S. VASPs using correspondent or intermediary arrangements, this means reviewing contracts to confirm that>Fraud prevention as a compliance objective. The 2025 framing treats payment accuracy as a compliance obligation, not just a customer-service issue. A misdirected payment caused by inaccurate beneficiary data is now a Travel Rule compliance failure, not just an operational error. That shifts the risk calculus for teams that have been treating beneficiary verification as optional.
FATF also launched a public consultation in 2026 to gather input on implementation guidance, with member jurisdictions expected to be ready to implement changes by the end of 2030. U.S. VASPs should treat that 2030 horizon as a planning deadline for full alignment, while treating the 2025 revisions as immediately relevant to program design.
Policy actions to start now:
- Align your internal data model with IVMS101 v1.01 fields, including the new fraud-prevention fields as they are specified in FATF’s forthcoming implementation guidance.
- Add beneficiary wallet-address verification to your pre-transmission checklist, not just sanctions screening.
- Review your payment-chain contracts to confirm IVMS101/>
The gap between policy and practice in U.S. Travel Rule programs
Most U.S. VASPs I have seen build their Travel Rule programs in two distinct phases, whether they plan it that way or not. The first phase is reactive: a compliance officer gets an examiner inquiry or a counterparty demand, and the team scrambles to collect data retroactively and document a policy that already exists in practice but was never written down. The second phase, if the team is disciplined, is proactive: they rebuild the program around IVMS101, select a messaging architecture that scales, and integrate verification tooling before the next examination cycle.
The teams that skip straight to phase two share a common trait. They treat the Travel Rule as an engineering problem with a compliance wrapper, not the other way around. They assign a technical lead alongside the BSA Officer from day one, map their customer data model to IVMS101 before selecting a vendor, and build the audit log as a first-class system component rather than an afterthought.
The privacy tension is real and underappreciated. Sending full KYC data to a foreign VASP whose>One thing I would tell every compliance lead starting a Travel Rule program: the most valuable thing you can build is not the/>
Primary sources and further reading
Every compliance team building or auditing a Travel Rule program should work from primary sources, not just industry explainers. The documents below are the ones that actually govern or shape U.S. obligations.
- FATF Recommendation 16 update, June 2025: The most current version of the global standard, including the new fraud-prevention and standardized-fields requirements. Read this before finalizing any program design.
- FATF Virtual Assets guidance: Covers licensing, risk-based approaches, and the sector’s technology responsibilities. The primary FATF reference for VASP-specific obligations.
- FinCEN Bank Secrecy Act resources: The U.S. enforcement authority’s own page, including 31 CFR 1010.410 and links to guidance documents. Bookmark this and check it quarterly.
- FinCEN virtual-currency AML advisory: Identifies the specific AML vulnerabilities FinCEN examiners look for in virtual-currency businesses. Treat it as an examiner’s checklist.
- Regulations: The public rulemaking record for FinCEN’s virtual-currency recordkeeping proposals. Monitor this for threshold changes and final rules.
- FATF 2026 public consultation on payment transparency: The ongoing consultation that will shape implementation guidance through 2030. Submit comments if your organization has relevant operational experience.
FATF consultation timelines typically run 60–90 days from publication. Set a calendar reminder to check the FATF website each quarter for new consultation launches and finalized guidance. For U.S. rulemaking, sign up for FinCEN’s email updates at fincen.gov to receive notices of proposed rulemaking and final rules as they publish.
For broader context on how compliance obligations are reshaping exchange operations, Blockchainreporter’s coverage of KuCoin’s compliance push and the latest crypto news and regulatory analysis tracks how these requirements play out in practice across the industry.
This article provides general information about regulatory requirements and is not legal or compliance advice. Confirm current rules and obligations with qualified AML counsel and your primary regulator before making compliance decisions.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
Sources
- FATF updates Standards on Recommendation 16 on Payment Transparency
- Virtual Assets
- What Is the Travel Rule? Definition, Thresholds & Compliance – Chainalysis
- Bank Secrecy Act (FinCEN)
Recommended
- Expert Comments On The CLARITY Act: Why The Stalled US Bill Isn’t MiCA’s Rival — Yet
- U.S. Stablecoin Delay Benefits Global Crypto Markets, Says Venom CEO
- Circle Renews Coinbase USDC Deal, Rules Out Quarterly Payouts
- Bybit.eu Secures EMI Licence In Austria Amid EU Compliance Shuffle