Travel Rule Compliance Architecture for Virtual Asset Transfers
Making Sure the Data Travels With the Transfer
The travel rule sounds like a messaging problem and is really a counterparty problem. Sending originator and beneficiary information alongside a transfer is straightforward once you know who the counterparty is, which protocol they use, and whether they will accept the data. None of those three is discoverable from a ledger address, and all three vary by jurisdiction, provider, and sometimes by transaction.
That is why travel rule compliance VASP programmes spend most of their effort on discovery, exception handling, and policy rather than on the message format. The rule is clear. The environment it operates in is not.
What does the rule actually require?
That required information accompanies transfers, that missing information is detected, and that procedures exist to handle it.
The EBA's Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under Regulation (EU) 2023/1113, applicable from 30 December 2024 with a compliance deadline of 27 November 2024, specify what payment service providers, crypto-asset service providers, and their intermediaries should do. The guidelines instruct providers to detect missing or incomplete information accompanying a transfer and to establish procedures to manage a transfer that lacks the required information. The specific data elements and thresholds sit in the guidelines themselves, so confirm the current detail with your compliance function per jurisdiction rather than relying on a summary.
Why is detection the operative obligation?
Because you control what you send and not what arrives.
Sending information is an engineering task with a known answer. Receiving it is not, since the counterparty may use a different protocol, may send partial data, may send nothing, or may not be a regulated provider at all. The obligation therefore lands on your ability to notice the gap and act on it consistently, which makes the detection and exception path the core of the build rather than a fallback.
Can your platform tell you today how many inbound transfers arrived without complete information?
Talk to Digiqt about travel rule detection and exception design
What makes this harder than payment messaging?
No shared rail, no directory, ambiguous counterparties, and personal data crossing borders.
| Difficulty | Why it bites |
|---|---|
| No universal messaging rail | Several competing protocols, none universal |
| No authoritative provider directory | Determining who controls an address is inference, not lookup |
| Jurisdictional asymmetry | Your obligation exists where the counterparty's may not |
| Unhosted wallets | No counterparty provider to exchange data with |
| Address reuse and attribution | An address may serve many customers or none |
| Irreversibility | A transfer sent cannot be recalled if data is refused |
| Data protection | Transmitting identifying data to third parties across borders |
| Screening timing | Lists change continuously, transfers settle in minutes |
Why is counterparty identification the core unsolved problem?
Because a ledger address carries no information about who controls it.
Determining whether a destination belongs to a regulated provider, and if so which one and how to reach them, is inference from attribution data, provider directories of varying completeness, and analytics. That inference can be wrong in both directions: treating a provider address as unhosted means failing to send required information, and treating an unhosted address as a provider means expecting an exchange that never happens. Build the attribution capability deliberately, record the basis of each determination, and monitor accuracy, because this is the input every downstream decision depends on.
What is the sunrise issue?
Counterparties whose jurisdictions have not implemented the rule, or implemented it differently.
Your obligation applies regardless of whether the receiving provider has an equivalent one, which produces transfers where you must send information the counterparty cannot receive or will not acknowledge. Policy has to state what you do in that case: proceed with records, apply enhanced monitoring, restrict transfer types, or decline. Make it a written risk-based position approved by compliance rather than a decision made per transaction by an operations analyst, because consistency is what an examiner will test.
What does the architecture look like?
Seven components, with discovery and exception handling doing most of the work.
| Component | Responsibility |
|---|---|
| Transfer initiation | Capture required data before the transfer is submitted |
| Counterparty discovery | Determine destination type and provider, with recorded basis |
| Data exchange | Send and receive required information over supported protocols |
| Validation | Check completeness and plausibility of received data |
| Screening | Screen parties and addresses against current lists |
| Decision and routing | Proceed, hold, request, reject, or return per policy |
| Records and reporting | Retain what was sent, received, decided, and why |
Where should the exchange happen relative to the transfer?
Before settlement wherever possible, because a settled transfer cannot be undone.
If you send the asset and then discover the counterparty will not accept or provide the required data, you have an irreversible transfer and a compliance gap with no remedy. Exchange first, confirm the counterparty is willing and able, then transfer. That sequencing costs latency and occasionally loses a transaction, and it is the only order that keeps the control meaningful. Where operational reality forces post-transfer exchange for some flows, document the risk acceptance explicitly and monitor those flows separately.
How should unhosted wallets be handled?
Risk-based, with verification of customer control where required and honest limits on what can be verified.
Transfers to and from wallets not held by a provider have no counterparty to exchange data with, so the obligation shifts toward verifying that your customer controls the wallet where that is required, applying checks proportionate to risk, and keeping records of what was verified and how. Be realistic about the limits: proving control is possible through signing or micro-transaction methods, and proving who is behind an address is generally not. Set thresholds and enhanced measures by risk rather than treating all such transfers identically, and record the rationale so the approach is defensible as a policy rather than as a series of judgments.
Is your unhosted wallet approach a written risk-based policy or a set of case-by-case decisions?
Talk to Digiqt about unhosted wallet policy and verification
How do you handle missing or incomplete information?
With a written policy applied consistently, and escalation for the cases it does not cover.
| Situation | Typical response |
|---|---|
| Inbound transfer with no information | Hold pending request, per policy and risk |
| Inbound with partial information | Request the missing elements, decide on response |
| Counterparty refuses to provide | Decline future transfers, consider restricting the relationship |
| Repeated deficiencies from one counterparty | Relationship-level action rather than per-transaction |
| Outbound where counterparty cannot receive | Policy decision, recorded, with monitoring |
| Screening hit on either party | Freeze and escalate rather than proceed |
The requirement is consistency. Two analysts facing the same facts should reach the same decision, which means the policy has to be specific enough to apply and the platform has to record which rule drove each outcome. Relationship-level action deserves emphasis: a counterparty that repeatedly sends incomplete data is a relationship problem rather than a queue of individual exceptions, and treating it transaction by transaction guarantees the problem persists.
How does screening fit?
Screen both parties and the addresses, against current lists, at the moment of transfer.
Names, addresses, and where available additional identifiers all need screening, and the lists change continuously, so screening at onboarding is insufficient for transfers occurring later. Index lists locally for speed, screen at transfer, and route hits to a staffed queue with a clearance target, since a transfer held indefinitely is its own failure. Address-level screening and on-chain analytics add a dimension conventional payment screening lacks, and both produce false positives that need an adjudication process rather than automatic blocking. The distinction between screening in the window and clearing what it produces is the same one described in this guide to sanctions screening and unpayable claims.
What data protection constraints apply?
Transmission of personal data to third parties, frequently across borders, with minimisation obligations.
The travel rule requires sending identifying information about your customer to another provider, which is a disclosure of personal data and often a cross-border transfer. That creates obligations that sit awkwardly alongside the compliance obligation: send what is required and no more, ensure a lawful basis and transfer mechanism, inform customers that their data will be shared, retain only as long as needed, and protect the data in transit and at rest. Over-disclosure is a real risk, since sending extra fields feels safer from an AML perspective and is a breach exposure from a privacy perspective. The multi-jurisdiction dimension is covered in this guide to privacy compliance across jurisdictions, and the identity data foundations in digital onboarding and KYC automation.
How do you handle protocol interoperability?
By supporting more than one and abstracting the difference internally.
Several protocols exist for exchanging this information and no single one has universal adoption, so a platform serving a wide counterparty base will support several. Abstract them: one internal representation of a transfer's required information, with adapters per protocol handling format, transport, and acknowledgement semantics. That keeps protocol change contained and lets you add a counterparty's preferred mechanism without touching the core, which is the same adapter discipline that governs payment rail integration. Then monitor per-protocol success rates, because they differ and the differences tell you where to invest.
How should delivery be sequenced?
Policy first, then outbound, then discovery, then inbound handling, then relationship management.
| Phase | Duration | Deliverable |
|---|---|---|
| Policy and risk framework | 1 to 2 months | Written positions on sunrise, unhosted wallets, missing data, thresholds |
| Outbound information capture and send | 2 to 3 months | Required data captured, sent over at least one protocol |
| Counterparty discovery | 2 to 3 months | Attribution capability with recorded basis and accuracy monitoring |
| Inbound validation and exception handling | 2 to 3 months | Detection, hold, request, decision, records |
| Screening integration | 1 to 2 months | Party and address screening at transfer with adjudication queue |
| Protocol abstraction | 2 months | Multiple protocols behind one internal model |
| Counterparty relationship management | Ongoing | Scorecards, escalation, restriction decisions |
Policy before engineering is the sequencing that matters, because the platform enforces whatever the policy says and building first produces a system that encodes decisions nobody approved. Where transfers involve bank-issued tokens, the controls interact with the design in tokenised deposits and stablecoin infrastructure, and the FSB's stablecoin recommendations expect comprehensive risk management including anti-money laundering and counter-terrorist financing measures as part of the arrangement.
Which metrics matter?
Outbound completeness, inbound completeness by counterparty, discovery accuracy, exception clearance time, and screening performance.
Report outbound completeness, meaning transfers sent with all required information, which should be effectively total. Track inbound completeness by counterparty, since that scorecard is what drives relationship decisions. Measure discovery accuracy, including cases where a destination was misclassified, because that error propagates into every downstream control. Report exception clearance time and volume by category, with ageing, as held transfers are customer-affecting. Track screening hit rates and adjudication time separately from screening latency. And measure protocol success rates per counterparty, which reveals where technical integration rather than policy is the blocker. Where intelligence about counterparties can be shared lawfully between institutions, the mechanics resemble those in federated fraud intelligence sharing.
The travel rule is unusual in that the messaging is the simple part and the environment is the hard part. A platform that discovers counterparties reliably, exchanges data before settlement, applies a written policy consistently to missing information, and sends no more personal data than required will satisfy the obligation. One built around a single protocol and an optimistic assumption about counterparties will spend its life in exception handling.
Frequently Asked Questions
What does the travel rule require?
That required originator and beneficiary information accompanies a transfer, that missing or incomplete information is detected, and that procedures exist to manage transfers lacking it.
Why is detection the operative obligation?
Because you control your own outbound data and not what arrives. The EBA guidelines focus on detecting missing or incomplete information and having procedures to handle it.
What is the sunrise issue?
Counterparties in jurisdictions where the rule is not yet in force, or not enforced the same way, so your obligations exist while theirs may not. Policy has to cover that asymmetry.
Why is counterparty identification the hard problem?
Because a ledger address does not announce which provider controls it, so you must determine whether the destination is a regulated provider, an unhosted wallet, or something else.
How should unhosted wallets be handled?
With a risk-based approach: verification of customer control where required, additional checks proportionate to risk, and records of what was verified and how.
What should happen when information is missing?
Follow a written policy: hold, request, reject, or return, decided by risk rather than case by case, with escalation and a recorded rationale for every decision.
Why is sending more data than required a risk?
Because you are transmitting personal data to a third party, often across borders. Over-disclosure is a data protection issue even when it feels safer for compliance.
Where should the information exchange happen?
Before the transfer settles wherever possible, since an irreversible transfer to a counterparty who then refuses the data leaves no remedy.
