Travel Rule, End-to-End: Sending Originator/Beneficiary Data in 4 Steps

This is part 1 of our "Tools for Compliance" series. The companion piece, The Travel Rule for Virtual Assets: Implementation Guide, covers the regulatory framework. This one is operational: what happens, in order, when a CASP processes a transfer that is subject to Travel Rule obligations — and what BlockchainAnalysis does at each step.

Travel Rule compliance fails not because CASPs do not know the rule. It fails at the operational seams. A withdrawal request arrives. The compliance system has 30 seconds to determine: is the destination a VASP, an unhosted wallet, or something else? Which protocol does the counterparty speak? What data fields do they require for this jurisdiction? Is the beneficiary sanctioned? If the wallet is unhosted, has ownership been proved? Every one of these is a place where the workflow can stall.

Below is the four-step workflow that needs to execute, deterministically, on every covered transfer. Each step has a regulatory hook, a data requirement, and a failure mode that auditors look for.

Step 1 — Counterparty Classification

Before any Travel Rule message is constructed, the system must answer a single question: what is the destination address? Three possibilities, three different workflows.

• VASP-controlled address — transmit IVMS101 to the counterparty CASP via the agreed protocol
• Unhosted (self-custodied) wallet — collect beneficiary data from the customer; verify ownership if the transfer exceeds EUR 1,000 (EU TFR Art. 14b)
• Other regulated entity (bank, payment institution) — apply the equivalent funds-transfer regulation, which may not be IVMS101

Misclassifying a VASP address as unhosted means failing to send Travel Rule data. Misclassifying an unhosted wallet as a VASP means sending PII into a void — or worse, to the wrong party. This is the single highest-leverage decision in the workflow, and it cannot rely on customer self-declaration.

How BA does it. The destination address is resolved against our entity database (1B+ labelled addresses across 80+ chains). A hit on a known CASP returns the operating entity, the supported Travel Rule protocols (TRISA, Notabene, Sygna, OpenVASP), and the jurisdiction-specific data fields the counterparty expects. A miss is flagged as candidate-unhosted and routed to Step 2 with ownership-verification requirements pre-attached.

Step 2 — Data Collection and Verification

Once the counterparty is classified, the system assembles the originator and beneficiary records. Under EU TFR (Regulation 2023/1113) and FATF Recommendation 16, the required originator fields are:

• Name (legal name of the natural person or legal entity)
• Distributed ledger address used for the transfer (or wallet identifier where addresses are not used)
• Account number, if a customer account is used to process the transfer
• One of: residential address, official personal document number, customer identification number, or date and place of birth

Beneficiary fields are the symmetric subset (name, address, account number). For transfers to or from unhosted wallets above EUR 1,000, the CASP must additionally verify that the customer controls the unhosted wallet. Acceptable methods include cryptographic signature of a challenge message, micro-deposit verification, or other equivalent technical means.

How BA does it. Originator data is pulled from the CASP's existing KYC profile through the BA Compliance integration — no re-collection, no parallel data store. Beneficiary data, where supplied by the customer, is normalised into the IVMS101 schema. For unhosted-wallet ownership verification, BA issues a challenge message that the customer signs in their wallet; the signature is stored in the audit trail with the transfer record.

Step 3 — Transmission

The Travel Rule message must reach the counterparty CASP before, simultaneously, or immediately after the on-chain transfer (EU TFR Art. 14(1)). In practice, "before" is the operationally safe choice: it lets the beneficiary CASP screen the incoming PII against its own sanctions and risk lists before the on-chain transaction settles, which is what the regulation contemplates.

The transmission step has three subroutines:

1. Protocol selection — the counterparty may speak TRISA, Notabene, Sygna, OpenVASP, or a proprietary API. The originator picks the protocol the counterparty accepts.
2. Envelope construction — the IVMS101 payload is serialised into the chosen protocol's message format and encrypted to the counterparty's public key.
3. Acknowledgement — the counterparty returns a positive, negative, or pending response. A negative response (sanctioned beneficiary, missing required field, refusal) is a stop signal: the on-chain transfer must not proceed.

How BA does it. BA Compliance maintains active connections to the major Travel Rule networks and routes each outbound message via the counterparty's preferred protocol. Acknowledgement state is reflected back to the CASP's transfer-approval workflow: a pending response holds the transfer in a queue; a negative response cancels it and writes a documented reason to the audit log.

Step 4 — Inbound Reception and Verification

Steps 1–3 describe the originator side. The mirror obligations on the beneficiary side are equally important and equally enforced. As the receiving CASP, the workflow is:

• Receive the incoming Travel Rule message from the counterparty (via TRISA, Notabene, Sygna, OpenVASP, etc.)
• Validate that all required fields are present and well-formed
• Screen the originator (name, address) against the CASP's sanctions and PEP lists
• Cross-check the incoming wallet address against the CASP's on-chain risk database
• If the inbound transfer is to an unhosted wallet, collect beneficiary data from the customer and verify ownership (mirror of Step 2)
• Either credit the customer's account or hold the funds pending further investigation, depending on the screening outcome

Under EU TFR Art. 16, the beneficiary CASP must have procedures for handling transfers with missing or incomplete information — including rejection, return, suspension, or requesting completion. The procedure must be risk-based, documented, and consistent across customers.

How BA does it. Inbound messages land in a queue tied to the beneficiary's account. The originator's name is screened against the same sanctions and PEP databases used at onboarding (OFAC SDN, EU Consolidated, UN Security Council, UK HMT, Swiss SECO), and the inbound wallet address is screened against the BA risk graph for exposure to mixers, darknet markets, ransomware addresses, and other high-risk entities. The screening result is delivered to the compliance team as a single decision payload — not a stack of dashboards to consult one at a time.

What Auditors Will Ask For

When an NCA or external auditor reviews a Travel Rule programme, the questions are not about the rule. They are about evidence. A defensible programme produces:

• A counterparty classification trail for every outbound transfer (VASP / unhosted / other), with the attribution source and confidence level
• The exact IVMS101 payload transmitted, the transmission protocol used, and the counterparty's acknowledgement
• For unhosted-wallet transfers above EUR 1,000, the ownership-verification artefact (signed challenge, micro-deposit confirmation)
• For inbound transfers, the screening result on the originator and the action taken (credited, held, rejected, returned)
• For sunrise/incompatible-counterparty cases, the documented attempt and the risk-based decision (proceed with mitigation, hold, reject)
• Five years of the above, retrievable per AMLR Art. 77

The shape of that evidence is what separates a Travel Rule programme that passes inspection from one that does not. The rule itself is short. The audit trail is everything.

Next in the series: Tools for Compliance #2 — Real-Time Sanctions Screening for CASPs, where we walk through what to check at every deposit, withdrawal, and inter-account transfer, and how the same workflow extends to wallet-monitoring alerts.