How should VASPs handle Travel Rule compliance when transfers involve unhosted wallets and fragmented jurisdiction rules?

Why fragmented Travel Rule rules force a jurisdiction-first operating model

VASPs cannot treat travel rule compliance as one global workflow with a few local exceptions. When transfers cross borders, the compliance obligation is shaped by the jurisdiction that governs the sender, the recipient, the VASP relationship, and sometimes the settlement leg itself. That means firms need a rules engine, not a single policy memo, to decide what data must be collected, when it must move, and which transfer paths require extra friction.

The practical consequence is that a transfer can be compliant in one market and non-compliant in another even if the underlying blockchain rail is the same. A robust design therefore separates the customer experience from the regulatory decisioning layer, so local thresholds, data fields, retention expectations, and reporting triggers can change without rewriting the whole process.

For financial crime teams, the most important issue is that “Travel Rule compliant” is not a static label, it is a jurisdiction-specific state. FATF Recommendations remain the clearest baseline for virtual asset controls, but implementation still depends on local law, regulator guidance, and the VASP’s exposure footprint.

How unhosted wallets change the compliance and control design

Unhosted wallets change the workflow because there is no counterparty VASP to exchange originator and beneficiary information with on your behalf. The VASP therefore has to decide whether it can proceed, whether additional verification is needed, or whether the transfer should be restricted under local policy. That decision is usually not about the chain itself, it is about whether the firm can establish sufficient comfort over who controls the destination and whether the transaction is consistent with sanctions, AML, and internal risk appetite.

That is why good controls distinguish between wallet identification, counterparty verification, and transfer approval. A wallet address alone is not enough to satisfy due diligence when the jurisdiction expects identity data or when the risk score is elevated. In practice, firms often need documented logic for proof-of-control checks, threshold-based escalation, and exceptions handling, so reviewers can see why a transfer to an unhosted wallet was allowed or blocked.

Where the control environment is weak, the danger is not just missed data exchange. It is also false confidence, because a technically completed transfer can still be operationally non-compliant if the VASP cannot evidence how the recipient wallet was assessed, who approved the payment, and which rule set was applied.

What should sit behind the rule engine, screening, and audit trail

VASP teams should build the Travel Rule process around a small set of durable control objects: jurisdiction mapping, counterparty classification, sanctions and risk screening, exception workflow, and immutable audit evidence. The process should decide whether a transfer is in scope, what data must be transmitted, whether an unhosted wallet check is required, and what to do when a local rule is stricter than the firm’s default policy.

That design works best when it is testable. NIST Cybersecurity Framework 2.0 is useful here because the problem spans governance, protect, detect, and respond functions, not only one compliance control. For the control layer itself, NIST AI Risk Management Framework is not the right lens, but NIST SP 800-53 Rev 5 Security and Privacy Controls supports the access control, audit, and configuration discipline that underpins a defensible workflow.

For cross-border compliance mapping, EU NIS2 Directive is a reminder that resilience, supply-chain discipline, and incident handling can sit alongside financial-crime obligations when regulated digital services are in scope. The useful question for practitioners is whether the transfer workflow can produce evidence quickly enough to satisfy both compliance review and supervisory inquiry.

Risk and Threat Considerations

Fragmented jurisdiction rules create a real exposure because the same transfer path can carry different legal duties depending on where the VASP, customer, or counterparty sits. Unhosted wallets add another layer of risk because they remove a natural trust boundary and make it easier for bad actors to obscure beneficial control, route funds through intermediaries, or force manual workarounds that weaken screening discipline.

Failure mechanism: A firm applies one global travel rule workflow, misses a local threshold or unhosted-wallet requirement, and either under-collects data or transmits it too late for the transfer decision. In parallel, poor wallet classification or weak exception handling can let a high-risk transfer pass with incomplete screening or inadequate evidence.

Impact: The result can be regulatory breach, sanctions exposure, failed auditability, remediation cost, and a higher chance that illicit activity is processed before controls catch up. At scale, the biggest problem is inconsistent treatment across corridors, which creates blind spots that adversaries and compliance failures both exploit.

Practitioner Guidance

What to prioritise: Build the jurisdiction matrix first, then map each corridor to the data fields, thresholds, and wallet-handling rules that actually apply. If the local rule set is unclear or changes frequently, route that corridor into a higher-friction approval path rather than pretending a generic policy is sufficient.

What to verify: The transfer log should show which jurisdictional rule was applied, what data was collected, whether the counterparty was hosted or unhosted, and who approved the exception. If you cannot produce that chain of evidence quickly, the control is not operationally mature yet.

Common mistake: Teams often over-focus on whether data can be technically transmitted and under-focus on whether the firm can prove it chose the correct rule set before settlement. For this topic, timing and evidence are part of compliance, not after-the-fact documentation.

Practitioner takeaway: The safest design is a corridor-specific control model with hard evidence, because Travel Rule compliance fails most often when firms assume one workflow can satisfy every jurisdiction and every wallet type.

Related resources from NHI Mgmt Group

• Why does Travel Rule compliance create operational risk for VASPs handling cross-border transfers?
• Why do Travel Rule obligations become harder to operationalise for VASPs and unhosted wallets?
• How should VASPs embed Travel Rule compliance into transaction workflows?
• How should compliance teams handle Travel Rule obligations across multiple jurisdictions?