“Travel Rule” Meets Web3: A Field Guide from a Regulatory Perspective
The “Travel Rule” has matured from a banking artifact into a global transparency standard for virtual asset transfers. In crypto, it demands that originator (sender) and beneficiary (receiver) information “travel” with the transfer, and that firms act on gaps in that data. This essay explains the rule’s legal underpinnings, how it actually works across borders, what to do about self-hosted (“unhosted”) wallets, and how Web3 building blocks, smart-contract wallets, verifiable credentials, and zero-knowledge proofs—can help square compliance with privacy.
1.What the Travel Rule Is (and Isn’t)
The baseline: The Financial Action Task Force (FATF) embeds “Travel Rule” expectations in Recommendation 16 and its interpretive guidance. For virtual assets (VAs) and virtual asset service providers (VASPs), the guidance clarifies that originator/beneficiary information must be transmitted immediately and securely, and it flags real-world adoption frictions like the cross-border “sunrise issue” (some countries live, others not yet).
The EU treatment: The EU hard-coded these principles into Regulation (EU) 2023/1113 (“TFR”).
For VASP ↔ VASP transfers, there is effectively no de minimis threshold for transmitting required data; the information must be submitted in advance of or at the same time as the transfer, via a secure channel—it does not have to ride on-chain.
The UK position: Since 1 September 2023, UK-registered crypto businesses must collect, verify, and share Travel Rule data, and apply risk-based measures when sending to or receiving from jurisdictions that haven’t implemented the rule (the “sunrise” reality).
The U.S. position: In the U.S., the recordkeeping and Travel Rule lives in 31 CFR §1010.410(f) (threshold $3,000), and FinCEN’s 2019 CVC guidance confirms that many crypto actors are “money transmitters,” making the rule operative for convertible virtual currency transmissions.
2. Data That Must “Travel,” in Plain Language
Under FATF/EU constructs, the sending VASP/VASP transmits:
• Originator data: name; account/ledger address; and, where fields exist, identifiers (e.g., LEI).
• Beneficiary data: name; ledger address or account number; and, if available, identifiers.
• Transmission: securely, before or concurrent with broadcasting the on-chain transfer.
EU law states this explicitly and clarifies timing and secure-channel expectations.
Accuracy vs. completeness. FATF distinguishes accuracy checks at the ordering (sending) side for the originator, while the beneficiary side must detect missing or incomplete data and decide whether to execute, reject, return, or suspend, based on risk.
3) The Hard Part: Self-Hosted (“Unhosted”) Wallets
When your customer is transacting with a self-hosted wallet (SHW), a wallet not custodied by a VASP, the question isn’t only “what data travels?” but also “who owns or controls that address?”
EU rule of the road. The TFR says: if a transfer to or from a self-hosted address exceeds €1,000, the VASP must take adequate measures to assess whether that address is owned or controlled by its own customer (originator side for outgoing; beneficiary side for inbound). Below €1,000, collect and hold the info; above €1,000, verify ownership/control.
How to verify ownership/control in practice (EU). The European Banking Authority’s Travel Rule Guidelines (EBA/GL/2024/11), applicable from 30 December 2024, list concrete methods. These include:
• Signing a specific message with the private key for that address (challenge/response);
• Sending a predefined “penny-test” amount (often the smallest denomination) from/to the address;
• Attended verification (as per remote onboarding guidance);
• Other suitable technical means.
They also allow whitelisting once you’re satisfied—subject to ongoing monitoring.
Industry protocols. You’ll see AOPP (Address Ownership Proof Protocol) and similar message-signing flows embedded in wallets and compliance tooling; some wallets integrated and later removed it amid user-privacy debate, useful context for customer experience planning.
4) Inter-VASP Messaging: What Actually Moves the Data?
The crypto ecosystem increasingly uses structured data aligned to IVMS-101, a common data model for originator/beneficiary info. Work continues on maintenance and updates, which helps with interoperability across jurisdictions and vendors.
Two prominent, interoperating rails for Travel Rule payloads are:
• TRISA (Travel Rule Information Sharing Alliance): a trust framework and secure peer-to-peer messaging network with global directories.
• TRP (Travel Rule Protocol): an open protocol used by several vendors and institutions; TRISA and TRP announced interop, mitigating vendor lock-in and “sunrise” fragmentation .
FATF’s 2025 Recommendation 16 note also encourages structured/remittance information and clarifies threshold logic for wire transfers; practical lessons learned in traditional payments are now being ported to VA messaging.
5) Where Web3 Fits In—and Why It Helps
5.1 Smart-contract wallets and account abstraction
Smart-contract accounts complicate “proof of control” because contracts don’t hold private keys; they implement logic. EIP-1271 standardizes how a contract proves a signature is “valid” for that account (isValidSignature(...)). This is foundational for Travel Rule ownership proofs on smart-contract wallets.
Account abstraction (ERC-4337) generalizes this: users operate programmable smart accounts with custom auth (multi-sig, passkeys), gas sponsorship, and off-chain signature flows—all while keeping a verifiable on-chain identity for address-control checks. Builders can use ERC-4337 primitives (UserOperations, EntryPoint, Bundlers) to create one-click compliance prompts (e.g., sign a message that encodes a Travel Rule challenge).
Developer takeaway. Combine SIWE (Sign-In with Ethereum, EIP-4361) for human-readable message signing with EIP-1271 validation: a portable, wallet-agnostic way to ask “prove you control this address,” including for smart-contract wallets.
5.2 Portable identity: DIDs + Verifiable Credentials
Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) can carry KYC attestations (e.g., “KYC-passed”, “over-18”, “non-sanctioned jurisdiction”) that a customer presents to a VASP without re-uploading documents every time. The W3C DID v1.0 and VC Data Model 2.0 are now web standards, with selective disclosure options. For Travel Rule, they can supply originator/beneficiary data elements in a structured, machine-verifiable format—ideally signed by a regulated KYC issuer .
5.3 Privacy-preserving proofs (ZKPs)
Zero-knowledge proofs (ZKPs) let users prove statements (e.g., “this address is controlled by a KYC-verified person at VASP X”) without revealing PII. Projects like Polygon ID show how ZK-backed credentials can enforce access/compliance checks while minimizing raw data exchange. For regulated environments, ZKPs won’t eliminate Travel Rule payloads, but they can reduce the blast radius of data sharing and support “verify more, expose less.” .
6) DeFi and “Who Is the VASP?”
Decentralized apps (the code) aren’t VASPs, but people who own/operate or exercise sufficient influence over arrangements that provide covered financial services can be. Regulators look at governance keys, fee extraction, and the ability to set parameters—functional control beats labels. If no accountable person exists, some jurisdictions consider requiring a regulated VASP to sit in the flow.
Implication: If your protocol team or affiliated entity runs a front-end, sets fees, or curates liquidity, you may be a VASP with Travel Rule exposure for transfers you facilitate as a business. Plan for interoperable messaging, KYC attestations, and address-control proofs that respect user privacy.
Conclusion
The Travel Rule in crypto is no longer theoretical. Between FATF’s clarifications and the EU’s TFR, firms must move accurate identity metadata quickly and securely, verify SHW ownership above €1,000, and act on deficiencies. Web3 doesn’t fight this; done right, it enables it, smart-account signature standards (EIP-1271), SIWE, DIDs/VCs, and ZK proofs give us tools to prove what’s necessary while protecting what isn’t. The operational art is to stitch these building blocks into a workflow that regulators recognize and users don’t hate.