The Identity Gap Hiding Inside Crypto Travel Rule Compliance

Crypto travel rule compliance is usually framed as an integration task. A compliance team picks a travel rule solution provider, an engineering team wires up the interoperability protocol, originator and beneficiary information starts moving between exchanges, and the obligation is treated as met. The travel rule, on this reading, is a messaging problem — connect the pipes and the requirement is discharged.

That framing is incomplete. The crypto travel rule does move information about the sender and recipient of a transfer between virtual asset service providers, but the data it moves is only as trustworthy as the identity verification sitting beneath it. A travel rule message asserts who the originator is. It does not, by itself, prove it. The name, account number, and address that travel with a crypto asset transfer are claims about a person — reliable only if that person was verified against independent evidence in the first place. The travel rule is an AML control, and every AML control depends on the identity underneath it being real.

This is the identity gap hiding inside crypto travel rule compliance. The travel rule fixes the message. It does not fix the identity assumption underneath it. This article walks through what the travel rule requires, which businesses it captures, how it treats self-hosted wallets and cross border transfers, how the UK, EU, and US regimes differ, and where the real control point sits — the identity layer beneath the message.

What the Crypto Travel Rule Is and Where It Comes From

From Wire Transfers to Virtual Assets

The travel rule is not a crypto-native invention. It is a wire-transfer rule that crypto inherited. The Financial Action Task Force — the FATF, the intergovernmental body that sets the international standards for anti money laundering and countering the financing of terrorism — first framed the requirement for traditional financial institutions moving money across the payment system. FATF Recommendation 16 requires that financial institutions include required and accurate originator information, and required beneficiary information, on wire transfers, and that the information remains with the transfer throughout the payment chain (1).

That last clause is the whole idea. The data must "travel" with the payment — hence the name. When a bank sends a wire, the originator's details accompany the transfer from institution to institution so that each party in the chain can screen, record, and, where necessary, report the underlying transactions. The rule was built for banks and other traditional financial institutions long before virtual assets existed, and it has applied to their wire transfers as a matter of AML routine for years.

FATF Recommendation 16 in Plain Terms

Recommendation 16 is one of the FATF's forty recommendations, the framework that national regulators translate into domestic law. Its interpretive note (INR.16) sets out the detail: which information is required, what the sending and receiving institutions must do, and how the requirement scales with the value of the transfer. The plain-English name — the travel rule — describes what INR.16 mandates, that originator and beneficiary information must travel alongside the funds. These international standards bind financial institutions worldwide, and when national regulators adopt the FATF standards, the travel rule requirements become law for the financial institutions and virtual asset service providers in their market.

In 2018 and 2019 the FATF extended the definition of "financial institution" and the scope of R.16 and INR.16 to virtual asset service providers, bringing virtual asset transfers into the same framework (1). The FATF's October 2021 updated guidance for a risk-based approach to virtual assets then spelled out how the standards apply to crypto assets, to peer-to-peer transactions, and to self-hosted wallet risk (2). The crypto travel rule, in other words, is the wire-transfer travel rule applied to a new set of rails, under the same FATF standards that bind banks. The travel rule requirements did not change in substance; only the businesses in scope did.

Why the Rule Exists

The purpose is the same across banking and crypto: to make the movement of value legible to the institutions obliged to detect money laundering and terrorist financing. Anonymous value transfer is the precondition for laundering; attaching verified identity information to a transfer removes that anonymity at the institutional layer. The travel rule is one of the FATF's core AML standards for that reason, sitting alongside the wider money laundering terrorist financing controls firms must operate.

For crypto, the case is sharper. A blockchain records wallet addresses, not people, and its transactions are pseudonymous by design. Without the travel rule, crypto transactions between two exchanges carry no information about who is sending and who is receiving. The rule closes that gap by requiring virtual asset service providers to collect, hold, and transmit the originator and beneficiary data the underlying ledger omits. It is an information requirement layered on top of a pseudonymous settlement system — an AML overlay on transactions the chain itself leaves anonymous. For financial institutions and virtual asset service providers alike, the travel rule is a money laundering and terrorist financing safeguard: it forces the parties to a transfer to hold the information that makes otherwise-anonymous transactions traceable. The FATF standards treat that traceability as foundational, which is why the travel rule requirements bind so many businesses across so many jurisdictions, and why money laundering investigators lean on travel rule data when they reconstruct a chain of transactions.

Which Businesses the Crypto Travel Rule Applies To

Virtual Asset Service Providers (VASPs) and CASPs

The crypto travel rule applies to virtual asset service providers — VASPs — and, in the EU, to their statutory equivalent, crypto-asset service providers, or CASPs. A VASP is any business that, as a business, exchanges, transfers, safekeeps, or administers virtual assets on behalf of clients. In practice that captures cryptocurrency exchanges, custodial wallet providers, and brokers dealing in digital assets. The businesses in scope are the intermediaries — the firms that stand between a customer and the blockchain, the businesses that hold client assets and process client transactions. The travel rule requirements fall on these businesses because they control the crypto transactions their customers make; a business that processes crypto transactions on behalf of clients is exactly the business the travel rule is written for.

The distinction that matters is custody and intermediation. A business that holds or moves crypto assets for other people is a VASP; a person moving their own assets between their own wallets is not. When two such businesses sit on either side of a transfer, the travel rule applies: the originating VASP must send the required information, and the beneficiary VASP must receive and check it. Stablecoin issuers and the platforms that distribute stablecoins fall within the same perimeter where they act as service providers — a point we develop in stablecoin KYC compliance. These are the businesses that must comply, and the businesses a supervisor will hold to account.

What Triggers the Obligation

The travel rule applies to a transfer of crypto assets made between two obliged businesses. It is the act of transferring value on behalf of a customer that triggers the requirement, not the mere holding of assets. When a customer of one exchange sends crypto assets to a customer of another, the originating business must transmit the originator and beneficiary information to the receiving business, and the receiving business must be able to receive it. Both businesses carry a duty on the same set of transactions. Not every movement of crypto assets is in scope, but every transfer of crypto assets between two service providers is, and the businesses on both ends must comply with the travel rule on those transactions.

Below-threshold transfers are not exempt. They carry a reduced set of required information rather than none at all — typically the names of the parties and an account number — with the obligation to verify that information falling away unless there is a suspicion of money laundering or terrorist financing. The businesses in scope must therefore build for two cases: full data on transactions above the threshold, reduced data on transactions below it. Businesses must design their systems to sort transfers by value automatically, because the data set changes at the threshold. Registered businesses must comply on every qualifying transfer, and a business registered in a market with the travel rule in force cannot pick which transactions to report; the requirement attaches to the transfer itself, so the businesses must comply whether the transaction is large or small.

The USD/EUR 1,000 Threshold and Its Variants

The FATF sets a de minimis threshold of USD/EUR 1,000 for virtual asset transfers (2). At or above that transaction threshold, the full originator and beneficiary data set must accompany the transfer. Below the transaction threshold, the reduced set applies, and the business need not verify the accompanying information absent a suspicion. The transaction threshold is the switch that determines how much data a transfer must carry, and how much AML friction it attracts. Below the transaction threshold the burden is lighter, but the threshold does not switch the travel rule off; it only changes how much data the transfer must carry, and businesses must still apply the travel rule to transactions above the threshold in full.

Jurisdictions vary. The EU sets no de minimis for crypto transfers at all — the full data requirement applies to every CASP-to-CASP transfer regardless of value, so every transfer is a full-data transfer. The existing US Bank Secrecy Act travel rule sits at USD 3,000. So the transaction threshold that governs what a business must send depends on where the business is registered and which regime binds it; a business registered in more than one market must apply the strictest rule that reaches its transactions. Whatever the threshold, the required information is the same category of originator and beneficiary data; only the amount of it changes. Firms must map each transaction threshold to the regime that governs the transfer, because the required data on a small transfer differs from the required data on a large one, and money laundering risk rises with value.

The Originator and Beneficiary Data Set for Crypto Asset Transfers

Required Originator Information

The heart of the travel rule is the data set — the specific fields that must be collected, verified, and transmitted with a crypto asset transfer. For the originator, FATF INR.16 requires the name of the originator; the originator's account number or, in crypto, the wallet address used to process the transaction; and the originator's physical address, or national identity number, or customer identification number, or date and place of birth (1). That is the originator information the sending business must collect and transmit on qualifying transactions. Financial institutions have run this collect-and-verify workflow for wire transfers for years; crypto businesses must build the same discipline for crypto assets, collecting the required information before a transfer moves.

The "or" in that list matters. The originating business does not need every identifier — it needs the name, an account number or wallet address, and one of the listed secondary identifiers. The UK regime frames the whole obligation as "collect, verify and transmit": the cryptoasset business must collect the required information, verify it against reliable evidence, and transmit it with the transfer (4). Collect verify and transmit is the operative verb string, and each of the three is a separate duty a business must be able to evidence. The required information is not optional: the travel rule requirement is that the originator and beneficiary data be complete and accurate on every in-scope transfer, and a business that transmits incomplete required information has not met the requirement.

Required Beneficiary Information

The beneficiary data set is lighter. INR.16 requires the beneficiary's name and the beneficiary's account number or wallet address — the identifiers the receiving business needs to match the incoming transfer to an account it holds (1). The beneficiary information does not need the same secondary identifiers as the originator, because the receiving business is expected to hold its own verified customer record for the beneficiary.

The asymmetry is deliberate. The originator's business vouches for the sender; the beneficiary's business vouches for the recipient. Between them, the two sets of originator and beneficiary information let each side screen the parties to the transfer against sanctions and watch lists, which is the AML point of the exercise. The necessary information is split across the two providers, and neither side has the complete picture without the other.

Account Numbers, Wallet Addresses, and Unique Transaction References

In traditional payments the account number identifies the parties. In crypto, the wallet address does the equivalent work, and the travel rule treats a wallet address as the functional account number for a virtual asset transfer. Where a transfer has no conventional account on either side, a unique transaction reference that permits traceability can stand in as the identifier. Where the originator is itself a business rather than a natural person, a legal entity identifier can serve as the account identifier.

The practical requirement is that the information transmitted be sufficient to identify the sender and recipient and to reconstruct the transfer if a regulator asks. That is why the data must be accompanied by, and remain linked to, the transfer itself — the "travel" in the travel rule. A name account number pairing that arrives detached from the transaction it describes satisfies nothing; the following information only has value while it stays bound to the transfer it belongs to, and the receiving business must store it against its own record for the retention period AML rules require. On the receiving side, the business must receive the data, match it to the account, and identify the customer named in it — the identification step that confirms the named person is the account holder the business already verified. Only then does a received message become usable AML information.

Self-Hosted Wallets and the Verification Problem

How the Rule Treats Transfers To and From Self-Hosted Wallets

A self-hosted wallet — also called an unhosted wallet — is a wallet controlled directly by an individual rather than held by a service provider. When a customer sends crypto from an exchange to a self-hosted wallet, there is no beneficiary VASP on the other side to receive the travel rule message. The information has nowhere to travel to, and the standard VASP-to-VASP exchange cannot happen for those transactions.

The rule handles this by shifting the burden onto the business that does have a customer relationship. Where one side of the transfer is an unhosted wallet, the obliged business on the other side must still collect the required information about its own customer and apply additional scrutiny to the transfer. The FATF's 2021 guidance treats transfers to and from self-hosted wallets as higher risk precisely because the counterparty verification a VASP-to-VASP transfer provides is absent (2). The business must conduct that scrutiny itself, using whatever tools establish the facts, and it must decide on a risk basis whether to allow the transactions at all. The originating business bears the money laundering risk on these transfers, so it must weigh the risk of each transaction to a self-hosted wallet and refuse the transactions it cannot verify. A risk-based approach is not a light-touch approach; the money laundering risk on high-value crypto transactions is where regulators expect the most scrutiny, and firms must document the risk decision behind every transfer they let through or hold.

Verifying Wallet Ownership: the EBA EUR 1,000 Test

The EU regime is specific about what this scrutiny means. The EBA's Travel Rule Guidelines (EBA/GL/2024/11) of 4 July 2024 require that, for transfers of crypto assets to a self-hosted address above EUR 1,000, the originator's CASP verify whether the self-hosted address is effectively owned or controlled by its client (7). The test is ownership: whether the customer actually controls the wallet the funds are going to. It is a risk-based control aimed squarely at the highest-risk transactions.

Technical means establish that control — signing a test message with the wallet's private key, a micro-transfer from the address, or blockchain analytics that link the address to the customer. Taking these reasonable steps is how a business identifies the natural person behind a self-hosted address. This is the same verification challenge that platforms integrating KYC for DeFi platforms face, where users interact from wallets rather than accounts and ownership cannot be assumed from mere possession of an address.

Why Self-Disclosure Is Not Enough

The EBA is explicit on one point: self-disclosure by the client does not qualify as adequate verification (7). A customer simply asserting "this wallet is mine" does not satisfy the requirement. The business must take reasonable steps to establish, by independent and robust technical means, that the natural person it has verified controls the address in question. The risk the travel rule is managing is that a customer names a wallet that belongs to someone else — a sanctioned party, a laundering conduit, a mule.

This is where the travel rule quietly becomes an identity problem. Verifying that a wallet belongs to a specific verified person is not a messaging function — it is an identification function. The rule can require the check; it cannot perform it. That gap between the requirement and the mechanism is the thread that runs to the end of this article, and it recurs everywhere the travel rule assumes an identity it does not itself establish.

The Sunrise Problem and Cross-Border Compliance

What the Sunrise Problem Is

Crypto moves across borders by default, but the travel rule is adopted country by country. The "sunrise problem" — a term popularised by RegTech provider Notabene (11) — describes the period during which different countries bring the travel rule into force at different times, like a sunrise reaching some places before others. An originating VASP in a travel-rule jurisdiction may need to send to a business in a jurisdiction that has not yet implemented the travel rule and cannot receive the required information. This is the central cross border friction of travel rule compliance.

The result is a structural mismatch across jurisdictions. One side is obliged to transmit originator and beneficiary information; the other side, in a jurisdiction that has not implemented the travel rule, has no obligation to receive it and often no system to process it. The data has a sender but no destination, and the compliant business is left holding an obligation it cannot fully discharge because the counterparty's country has not caught up. Cross border transactions are where the travel rule's uneven adoption bites hardest. The travel rule spread jurisdiction by jurisdiction, and the businesses that operate across jurisdictions carry the heaviest travel rule burden, because they must comply with the requirement in every jurisdiction their transactions reach.

Risk-Based Decisions on Inbound Transfers With Missing Information

Regulators address this with a risk-based approach rather than a prohibition. The FCA expects UK firms to fully comply when transacting with businesses in the UK, or in any jurisdiction that has implemented the travel rule, and to take a risk-based approach when sending to, or receiving from, jurisdictions that have not yet implemented it (5). A business receiving an inbound transfer with missing information must make a risk-based assessment: collect what it can, weigh the risk, and decide whether to proceed, hold, or reject the transfer.

The obligation to try does not lapse because the counterparty cannot reciprocate. Firms remain responsible for the decision even where the required information cannot be obtained across countries — the responsibility sits with the receiving business, not with the absent standard. A risk-based assessment documented at the time is what a supervisor expects to see, not a blanket refusal and not a blind acceptance. The firm must still comply with its own regime even when the counterparty's jurisdiction offers it nothing to work with.

The State of Global Adoption

Adoption is uneven but advancing. The FATF's Targeted Update of 26 June 2025 reported that 73% of responding jurisdictions — 85 of 117, excluding those that prohibit VASPs — had passed legislation implementing the travel rule, and that the travel rule was adopted or in process across 99 jurisdictions (3). Countries with materially important VASP activity account for roughly 98% of the global virtual asset market, so the coverage of economically significant crypto is far higher than the raw count of countries suggests.

The same update carried a warning: supervision, enforcement, and compliance lag behind legislation. Passing a law is not the same as enforcing it, and many jurisdictions that have implemented the travel rule on paper have not yet built the supervisory capacity to test compliance in practice. The change is real but incomplete, and the sunrise, in the FATF's own framing, is still rising across much of the world. Until more countries reach full implementation and enforcement, cross border transfers will keep producing the same gaps. As more countries implement the travel rule, the businesses caught by it grow in number, and firms that operate across many jurisdictions must comply with each regime a transfer touches. Countries that have implemented the travel rule expect registered businesses to comply in full; countries that have not implemented it leave the gap the risk-based approach must cover.

Crypto Travel Rule Compliance Across the UK, EU, and US

Three regimes account for most of the crypto travel rule compliance work a global business faces. They share the FATF standard but differ in threshold, scope, and the date each came into force. A short comparison sets out the differences before we walk through each.

The UK Regime: Part 7A, in Force 1 September 2023

The UK implemented the travel rule through the Money Laundering and Terrorist Financing (Amendment) (No. 2) Regulations 2022 (SI 2022/860), which inserted a new Part 7A into the Money Laundering Regulations 2017 (4). Made on 21 July 2022, Part 7A came into force on 1 September 2023. From that date UK cryptoasset businesses must collect, verify and transmit information on the originator and beneficiary of cryptoasset transfers, under the force of the UK regulations. The UK was among the earlier large markets to bring the travel rule into force.

The FCA set out its expectations for UK firms on 17 August 2023: firms must take all reasonable steps and exercise all due diligence to comply, and they remain responsible even when using third-party suppliers to move the data (5). Responsibility, in the UK framing, cannot be outsourced to a travel rule vendor — the regulated UK firm owns the outcome. The UK also brought crypto marketing within its financial promotions regime around the same period, so a UK business faces travel rule obligations and the financial promotions regime as parallel duties it must comply with together. Since the travel rule came into force, UK firms have had to comply on every in-scope cryptoasset transfer, and the FCA has been clear that the UK expects registered cryptoasset businesses to treat the travel rule as a live obligation, not a future one.

The EU Regime: TFR 2023/1113, From 30 December 2024

The EU implemented the travel rule through Regulation (EU) 2023/1113, the recast Transfer of Funds Regulation (6). It entered into force on 29 June 2023, and its crypto-asset provisions apply from 30 December 2024 — the same date the CASP authorisation requirements under the MiCA CASP regime took effect. The alignment is deliberate: the EU built its travel rule and its crypto licensing regime to switch on together, so a business authorised as a CASP is bound by the transfer requirements from the same day the licence takes force.

The TFR applies where at least one CASP or intermediary CASP involved in a transfer is established in the EU, and it sets no de minimis threshold for crypto transfers — the full data requirement applies to every transfer of funds in crypto form. The EBA's Travel Rule Guidelines (EBA/GL/2024/11) of 4 July 2024 supply the operational detail, including the self-hosted address ownership test discussed above (7). The EU regime is, on paper, the most demanding of the three regulations for the businesses that must comply with it.

The US Regime: 31 CFR 1010.410 and the 2020 Proposal

The US has had a travel rule for decades. Under the Bank Secrecy Act, 31 CFR 1010.410(f) requires a transmittor's financial institution to include and pass on to the next financial institution specified information about the transmittor and the transaction, for transmittals of USD 3,000 or more (9). That rule is in force as current federal regulation and applies to financial institutions generally, covering their qualifying transactions.

What is not settled is its crypto-specific extension. On 27 October 2020 FinCEN — the Financial Crimes Enforcement Network — and the Federal Reserve Board issued a notice of proposed rulemaking to lower the threshold to USD 250 for transfers that begin or end outside the United States, and to clarify that convertible virtual currency and digital assets fall within the travel rule (8). That proposal has not been finalised. A business assessing US crypto travel rule compliance must treat the USD 250 cross border figure as a proposed amendment, introduced but not adopted, and the USD 3,000 BSA threshold as the operative requirement for its US transactions.

Singapore, through the Monetary Authority of Singapore, was among the early adopters, applying travel rule requirements to its licensed digital payment token service providers. The point of the comparison across these countries is not to catalogue every regime but to show the shape: one FATF standard, many national implementations, different thresholds and different dates in force. A global business must comply with each regime that reaches its transactions, not with a single harmonised rule that does not exist.

How VASPs Satisfy the Rule Without Warehousing Raw Counterparty PII

Travel Rule Solution Providers and Interoperability Protocols

Most businesses do not build travel rule systems themselves. They connect to a travel rule solution — a network run by a specialist provider — and use an interoperability protocol to exchange the required data with the counterparty VASP. Providers such as Notabene, Sumsub, and others operate these networks; competing protocols define the message format and the handshake by which two businesses agree to share information about a transfer and the transactions behind it.

The engineering problem the protocols solve is discovery and delivery: identifying which business controls the beneficiary wallet, establishing a secure channel, and transmitting the originator and beneficiary information in a format the receiving systems can read. This is genuine and necessary work, and the solution providers do it well. Traditional banks manage the analogous problem through correspondent banking relationships built over decades; VASPs are creating the equivalent trust network from a standing start, across jurisdictions that adopted the travel rule at different times. These travel rule solutions process large volumes of transactions, matching the originator and beneficiary information to the underlying crypto transactions as they settle.

Where the Data Actually Needs to Live

The architectural question underneath the protocol choice is where counterparty data lives and for how long. Most travel rule solution stacks move counterparty personal data between platforms — the originator's details are packaged and sent to the beneficiary's business, and the reverse happens in return. Each side then holds a copy of the other side's customer data on its own systems.

That design meets the letter of the travel rule, but it multiplies the number of places raw personal data sits. Every VASP-to-VASP exchange creates another store of counterparty PII on another platform — a larger surface to secure, breach, and account for. The rule requires that the information be transmitted; it does not require that every recipient warehouse it indefinitely. The distinction between transmitting data on transactions and hoarding it is where thoughtful architecture and mere compliance part company.

The Trust Assumption Beneath Every Message

A travel rule message carries a claim: this is the originator, here is the verified identifier. The receiving business acts on that claim — screening the parties, recording the transfer, and deciding whether to proceed and whether to file a report on suspicious transactions. But the message is only as reliable as the identity verification the sending business performed. This is distinct from transaction monitoring, the separate AML discipline of watching flows of funds for suspicious patterns, which tools such as Chainalysis and Elliptic provide.

A travel rule message is not proof of identity. It is a claim about identity — trustworthy only if the underlying customer was verified. The protocol guarantees the message arrived intact. It guarantees nothing about whether the person named in the message is who the sending business says they are. That guarantee, essential to the whole exchange, has to come from somewhere else — from the identity layer beneath the message.

The Identity Layer Beneath the Travel Rule

The Customer Due Diligence Obligation Beneath Every Transfer

Every travel rule message rests on an assumption the travel rule itself does not create: that the customer behind the transfer has already been identified and verified. That assumption is the customer due diligence obligation. FATF Recommendation 10 requires financial institutions, including VASPs, to identify the customer and verify that customer's identity using reliable, independent source documents, data, or information (10). The travel rule transmits the identity; Recommendation 10 establishes it. Recommendation 16 assumes the AML work Recommendation 10 requires has already been done.

Due diligence is not a one-off box-tick. Regulators expect firms to conduct customer due diligence at onboarding and to keep customer information current over the life of the relationship — the expectation examined in ongoing customer due diligence. But the foundational act is verification: establishing, against independent evidence, that the natural person is who they claim to be. Without that verification at the outset — the customer due diligence FATF Recommendation 10 makes foundational — the originator information a travel rule message carries is an unverified assertion dressed as a fact, and no amount of message-level checking can repair a weakness in the identity beneath it.

The Travel Rule Side Verifyo Does Not Cover, and the Identity Side It Does

Here the scope has to be stated plainly. Under FATF Recommendation 16, the crypto travel rule is a VASP-to-VASP data-exchange obligation. Verifyo does not perform travel rule data transmission — that capability is on our roadmap, not live. We do not route originator and beneficiary messages between businesses, and we do not verify counterparties or businesses. For a direct comparison of the two approaches, see how Verifyo compares to Sumsub, a Travel Rule vendor.

For the layer beneath the message — verifying the natural person behind the wallet — this is what we do. Verifyo operates one live tier, Level 1 Standard KYC: identity document verification; sanctions, PEP, adverse-media, criminal, and barred-persons screening; and age attestation. That AML screening is performed at verification time, and the resulting attestation remains valid until its documented expiry — we do not describe it as continuous. Verifyo handles the identity-verification side; transaction monitoring tools such as Chainalysis, Elliptic, and ComplyAdvantage handle the transaction side. The two are complementary layers, not competitors, and a complete AML programme needs both. Every crypto business that moves customer funds runs into the same requirement, and the businesses that treat the identity requirement as seriously as the messaging requirement are the ones that comply in substance rather than in form.

Reusable Zero-Knowledge KYC Attestations and Wallet-Ownership Binding

The mechanism matters. A conventional KYC vendor verifies a customer and then transfers a copy of that customer's documents to each platform that needs it. Verifyo verifies the natural person once and issues a reusable Zero-Knowledge KYC attestation — a cryptographic proof that lets a platform confirm the person's compliance status without receiving their raw personal data. The receiving platform learns that the customer is verified and clear of sanctions; it does not receive a copy of their passport. This selective-disclosure approach follows the W3C Verifiable Credentials Data Model, which supports proving a claim from a credential without revealing the credential itself (12), and it is the Zero-Knowledge KYC architecture we have written about in depth.

The second mechanism speaks directly to the EBA wallet-ownership test. Verifyo performs wallet-ownership binding: a Zero-Knowledge attestation that links a wallet address to a verified identity. Where the EBA requires the originator's CASP to establish that a customer controls a self-hosted address, a wallet-ownership binding provides exactly that link — proof that a specific verified person controls a specific wallet, without exposing the underlying identity documents. The travel rule assumes the receiving business can trust who the counterparty's customer is; a verified, wallet-bound identity is what makes that trust evidenced rather than merely asserted. It closes the identity gap the message layer leaves open, and it does so without adding another store of raw PII to the chain of transactions.

What Compliance Teams Should Do

Map Your Obligation to Your Jurisdictions

The first practical step is jurisdictional. Map where the business is registered, where its customers are, and which regimes bind each transfer. A business established in the EU faces the TFR's zero-threshold requirement; a UK firm works to Part 7A; a US business works to the BSA travel rule and watches the proposed amendments. The obligation is not uniform across countries, and a compliance framework that assumes one global standard will misfire at the borders, especially on cross border transactions between jurisdictions on different timetables. Different jurisdictions set different thresholds, so the same transfer can be an in-scope transaction in one jurisdiction and a below-threshold transaction in another; a business operating across jurisdictions must comply with the required data set that each jurisdiction imposes on the transactions routed through it.

Record keeping supports the map. Firms must be able to show which rule applied to which transfer and what information was collected, verified, and transmitted — the evidence a supervisor asks for when testing whether a business is compliant. To stay compliant across jurisdictions, a business needs the record as much as the control, because the record is what proves the control ran on the relevant transactions. The money laundering risk a regulator cares about is concrete: unverified originators, transfers to sanctioned addresses, and transactions that should have been held. A business that can show it applied the required checks to those transactions, and made a defensible risk decision on each, is a business that can demonstrate it took its money laundering obligations seriously.

Separate the Message Layer From the Identity Layer

The second step is architectural. Treat travel rule messaging and identity verification as two distinct problems, because they are. A travel rule solution provider moves the message; it does not verify the natural person behind it. Buying the first and assuming it delivers the second is the mistake this article set out to name, and it is a common one because the messaging layer is the visible, integration-shaped part of the requirement.

The message layer answers whether the data arrived. The identity layer answers whether the data is true. A business needs both, from providers honest about which problem each one solves. Conflating them leaves the identity assumption unexamined — the gap where AML risk actually sits, and the gap a regulator's questions will find first. Firms that separate the two layers can comply with confidence; firms that blur them are one audit away from discovering the difference.

Treat Verification as Reusable Infrastructure

The third step is to stop paying to re-verify the same people. In the conventional model, every platform runs its own KYC and holds its own copy of every customer's documents — redundant cost and redundant risk. Reusable verification treats identity assurance as shared infrastructure: a person is verified once, and integrating platforms confirm that status without re-collecting the data. This is the model we built Verifyo around, and it is the natural counterpart to a travel rule message that asserts an identity the underlying verification has already established.

The travel rule fixes the message. It does not fix the identity assumption underneath it. A business that has wired up its travel rule solution has solved the transmission problem and left the harder problem — evidencing who the person behind the wallet actually is — for a layer the message protocol was never built to reach. That is the identity gap, and it is where a compliance buyer should look next.

Sources

(1) FATF (Financial Action Task Force). The FATF Recommendations — Recommendation 16 ("Wire transfers") and its Interpretive Note (INR.16). Adopted February 2012; R.16 revised at the June 2025 Plenary. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html

(2) FATF. Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers. October 2021. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html

(3) FATF. Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs. 26 June 2025. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/targeted-update-virtual-assets-vasps-2025.html

(4) UK Government / HM Treasury. The Money Laundering and Terrorist Financing (Amendment) (No. 2) Regulations 2022 (SI 2022/860), inserting Part 7A into the Money Laundering Regulations 2017. Made 21 July 2022; Part 7A in force 1 September 2023. https://www.legislation.gov.uk/uksi/2022/860/regulation/5/made

(5) FCA (Financial Conduct Authority). FCA sets out expectations for UK cryptoasset businesses complying with the Travel Rule. 17 August 2023. https://www.fca.org.uk/news/statements/fca-sets-out-expectations-uk-cryptoasset-businesses-complying-travel-rule

(6) European Union. Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets (recast Transfer of Funds Regulation). Entered into force 29 June 2023; crypto-asset provisions apply from 30 December 2024. https://eur-lex.europa.eu/eli/reg/2023/1113/oj/eng

(7) EBA (European Banking Authority). Guidelines on information requirements in relation to transfers of funds and certain crypto-assets under Regulation (EU) 2023/1113 (EBA/GL/2024/11). 4 July 2024. https://www.eba.europa.eu/sites/default/files/2024-07/6de6e9b9-0ed9-49cd-985d-c0834b5b4356/Travel%20Rule%20Guidelines.pdf

(8) FinCEN & Federal Reserve Board. Threshold for the Requirement To Collect, Retain, and Transmit Information on Funds Transfers … and Clarification … on Transactions Involving Convertible Virtual Currencies and Digital Assets (Notice of Proposed Rulemaking). Federal Register, 27 October 2020. https://www.federalregister.gov/documents/2020/10/27/2020-23756/threshold-for-the-requirement-to-collect-retain-and-transmit-information-on-funds-transfers-and

(9) US Government (eCFR). 31 CFR 1010.410 — Records to be made and retained by financial institutions (including the Travel Rule at 31 CFR 1010.410(f)). Current Code of Federal Regulations. https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/subpart-D/section-1010.410

(10) FATF. The FATF Recommendations — Recommendation 10 (Customer due diligence). Adopted February 2012; current standards. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html

(11) Notabene. What is the Crypto Travel Rule? (Crypto Travel Rule 101). Undated evergreen guide. https://notabene.id/crypto-travel-rule-101/what-is-the-crypto-travel-rule

(12) W3C (World Wide Web Consortium). Verifiable Credentials Data Model 2.0. W3C Recommendation, 15 May 2025. https://www.w3.org/TR/vc-data-model-2.0/