Travel Rule Compliance Architecture for VASPs

The Travel Rule is the single most technically demanding piece of AML regulation that a virtual asset service provider (VASP) has to implement. Unlike sanctions screening or transaction monitoring, which run within the firm's perimeter, the Travel Rule is a counterparty protocol: it requires that information about the originator and beneficiary of a virtual asset transfer travels alongside the value, in a standardised format, between two separate VASPs that may have no pre-existing bilateral relationship. Getting this right is a compliance question with an infrastructure answer.

This guide sets out what Travel Rule compliance actually requires, what the technical architecture looks like, what the protocol landscape is in 2026, and how a VASP should design its stack so that Travel Rule enforcement is a property of the infrastructure rather than a fragile policy layer. It is written for heads of compliance, engineers and architects at exchanges, custodians, brokers and wallet providers, and it assumes a reader who already understands the broader KYC and AML infrastructure picture.

The Travel Rule originates in the Financial Action Task Force's (FATF) Recommendation 16, which applies to wire transfers and, since the 2019 updates, to virtual asset transfers between VASPs. The substance is straightforward: the originating institution must transmit specified information about the originator and beneficiary to the beneficiary institution, and the beneficiary institution must make that information available to supervisors on request.

For virtual asset transfers, FATF's interpretive guidance sets the de minimis threshold at USD 1,000 or its local-currency equivalent, below which the information requirements are reduced but do not disappear entirely. National supervisors implement this differently: some require the full data set from any transfer; some align strictly to the USD 1,000 threshold; some have separate thresholds for cross-border and domestic flows. A VASP operating across jurisdictions has to treat the threshold as a configurable parameter per corridor, not as a global constant.

The required data set typically includes the originator's full name, a wallet address or other unique reference, a national identity reference or physical address, and the beneficiary's full name and wallet reference. Some jurisdictions require the originator's date of birth or customer identification number. The substance is that the beneficiary VASP must be able to identify both parties to a transfer and satisfy itself that its counterparty VASP has performed adequate due diligence on the originator.

It is worth dwelling on what the rule does not say. It does not say that every transfer must be pre-cleared by the beneficiary VASP. It does not say that unhosted-wallet transfers are prohibited. It does not say that a failed Travel Rule exchange must block the underlying transfer. Each of those decisions is a policy choice that a VASP makes within its risk appetite and its supervisor's expectations. Conflating "what the rule requires" with "how we've decided to implement it" is a common source of both supervisory pain and commercial self-harm.

The hardest engineering problem in Travel Rule compliance is counterparty discovery. When a customer of VASP A sends a virtual asset transfer to a wallet address, VASP A has to determine whether that wallet is controlled by another VASP (a "hosted wallet") or by a private individual ("unhosted" or "self-custodied"). The answer determines whether Travel Rule data exchange is required, whether a different policy applies, or whether the transfer should be rejected under the firm's internal risk framework.

There is no authoritative global registry of wallet addresses. The counterparty discovery problem is solved approximately, by combining several signals: membership in a Travel Rule protocol's VASP directory, block-explorer attribution data from analytics providers such as Chainalysis, Elliptic or TRM Labs, direct customer declaration ("this address belongs to my account at Exchange X") and prior transfer history. A production system has to combine these signals and produce a confidence score, with a policy that determines what happens at different confidence levels.

The counterparty discovery layer is the component that a VASP should own, even if the verification providers and Travel Rule protocols are external. It is the place where jurisdiction-specific policy, product risk tolerance and commercial considerations converge, and it is the place where supervisors will direct the most pointed questions during inspection.

Several protocols have emerged to solve the data-exchange layer of Travel Rule compliance, each with its own message format, VASP directory, trust model and commercial model.

The Travel Rule Protocol (TRP) from the Travel Rule Protocol working group is an open specification favoured by several institutional VASPs and banks. It defines a message format based on IVMS 101 (the interVASP Messaging Standard that most protocols now reference), with REST-based transport and a decentralised VASP directory model.

Notabene operates a proprietary protocol with its own directory and onboarding process, widely adopted by commercial exchanges. Sumsub offers Travel Rule as an extension of its KYC platform, attractive to firms that already use Sumsub for verification. Veriscope, built by Shyft Network, takes a blockchain-based approach to the VASP directory. OpenVASP is an open specification focused on privacy-preserving message exchange.

No single protocol has universal coverage. A VASP with customers who transact across the full counterparty universe typically needs to integrate at least two protocols, sometimes three, to cover enough of its counterparty flow. That reality drives the architectural decision to build a Travel Rule orchestration layer rather than committing to a single protocol.

The orchestration layer sits between the VASP's transaction processing system and the external Travel Rule protocols. Its responsibilities are:

• Resolving the counterparty VASP from the wallet address, combining signals from protocol directories, analytics providers and internal data;
• Selecting the Travel Rule protocol through which the counterparty is reachable;
• Assembling the required data payload from the firm's KYC records and normalising it into the protocol's message format;
• Initiating the data exchange, handling the counterparty's response (acceptance, rejection, request for additional data) and relaying the outcome to the transaction system;
• Producing an immutable audit trail of the exchange, including the policy version in force at the time, the data transmitted, the counterparty's response and the final disposition;
• Handling the cases that do not fit the happy path: counterparty is not reachable, counterparty declines, counterparty is in a jurisdiction with different requirements, destination is an unhosted wallet.

The orchestration layer should expose a simple API to the rest of the stack. A transaction system should be able to submit a prospective transfer and receive a decision: permitted (data exchanged successfully), permitted-with-conditions (unhosted-wallet path, elevated monitoring), blocked (counterparty non-participating and policy requires hosted-only) or pending (asynchronous counterparty exchange in progress). The complexity of protocol choice, data formatting, directory lookups and retry logic belongs inside the orchestrator, not in the calling code.

Bridge's Travel Rule platform implements this orchestration layer natively, with pluggable protocol backends, normalised IVMS 101 payloads and configurable counterparty policies per jurisdiction.

The orchestration layer described above sits off-chain. It runs inside the VASP's infrastructure, makes a decision, and then instructs the transaction system to submit or withhold the on-chain transfer. There is a small but real gap between the compliance decision and the on-chain action: a race condition, a bug, a manual override or an insider threat could produce an on-chain transfer that the compliance layer did not authorise.

For most regulated VASPs, that gap is managed through internal controls. For VASPs operating on programmable chains, it can be closed at the protocol level. Solana's Token-2022 standard introduces transfer hooks — smart-contract callbacks that run as part of a token transfer — which make it possible for a token issuer or a custodian to require that a compliance evidence reference be present on the transfer itself. A transfer that is not accompanied by a verified Travel Rule evidence token is rejected by the protocol, not just by the VASP's compliance layer.

Corda, similarly, supports compliance-aware flows in which a transfer cannot be notarised unless the participants have exchanged the required regulatory evidence as part of the flow. For VASPs operating on permissioned infrastructure, this is a natural pattern; for VASPs on public chains, Token-2022 hooks are the closest equivalent.

On-protocol enforcement does not replace the orchestration layer — the data exchange still has to happen off-chain — but it closes the last gap between compliance decision and on-chain action, which is the gap that incident post-mortems most often find open. We explore this pattern further in our compliance-native financial API guide.

Not every transfer can be matched to a hosted counterparty VASP that participates in a Travel Rule protocol. A significant share of transfers goes to unhosted wallets — customer self-custody, hardware wallets, DeFi contracts — and a further share goes to hosted wallets at VASPs that have not joined a protocol or that are in a jurisdiction without equivalent Travel Rule obligations. The firm's policy for these cases determines both the customer experience and the supervisory profile.

The permissive extreme — allow all transfers, apply enhanced monitoring to non-Travel-Rule destinations — maximises customer experience but produces a risk concentration that supervisors will not accept for higher-risk corridors or higher-volume customers. The restrictive extreme — block all transfers that cannot complete a Travel Rule exchange — is compliant but hostile to the substantial share of the customer base that uses self-custody. The middle path, which most mature VASPs adopt, is to permit unhosted-wallet transfers under tier-based limits, with enhanced monitoring, customer attestation of destination ownership, and counterparty risk scoring.

Some jurisdictions have introduced specific rules for unhosted-wallet transfers. The European Union's Transfer of Funds Regulation requires attestation and risk-based controls for transfers to and from unhosted wallets above defined thresholds. Firms operating across multiple jurisdictions need to treat unhosted-wallet policy as a configurable parameter, not as a single global rule.

Every Travel Rule exchange, every policy decision and every exception should produce an auditable event. The events should be immutable, timestamped, linked to the specific customer, transfer and policy version in force, and stored in a system that a supervisor can inspect without depending on the real-time operation of the transaction system.

The level of detail that a supervisor will expect varies by jurisdiction, but the minimum is: what data was transmitted, to which counterparty, through which protocol, with what response, resulting in what action. For blocked transfers, the reason code; for permitted transfers with conditions, the specific conditions applied; for exceptions handled by analyst review, the analyst's identity, the time taken, the decision and the supporting rationale.

A firm that can produce this detail on demand, for any transfer in its history, has the kind of audit trail that supports both routine supervisory engagement and incident response. A firm that cannot will find the gap revealed at the worst possible time.

Several operational patterns separate VASPs that run Travel Rule compliance well from those that struggle.

First, Travel Rule performance has to be engineered into the transfer latency budget. A Travel Rule exchange that takes thirty seconds to complete while a customer waits at checkout is a customer experience problem; a system that attempts to submit transfers asynchronously before the exchange completes is a compliance problem. The correct design is usually to pre-resolve the counterparty and pre-authorise the exchange at the point where the customer enters the destination address, not at the point where the transfer is submitted. This pushes the latency into the UX flow at a point where the customer expects some friction and takes it out of the critical path at submission.

Second, counterparty onboarding is a VASP-side process, not a protocol-side process. Even after a counterparty appears in a Travel Rule directory, the firm's compliance team should review it before permitting automated data exchange. The review looks at the counterparty's licensing, jurisdiction, ownership and supervisory profile. The outcome is a counterparty status — approved, approved-with-conditions, rejected — that the orchestration layer enforces.

Third, Travel Rule protocols are still evolving. Message formats change, directories grow and contract, jurisdictions add or modify requirements. A Travel Rule stack that treats the protocol integrations as stable APIs will break; one that treats them as subject to change produces sustained reliability.

For VASPs operating under Pakistan's Virtual Assets Act 2026, Travel Rule obligations apply from the point of PVARA authorisation. The specific threshold implementation and data set requirements are subject to PVARA's rulebook and are likely to track the FATF standard of USD 1,000 or the PKR equivalent, with full IVMS 101-aligned data. Firms preparing for PVARA authorisation should plan Travel Rule integration as part of the technology file rather than as a post-authorisation project, because a PVARA reviewer will expect the Travel Rule architecture, counterparty policy and audit trail to be evidenced at submission. Our PVARA licensing guide covers the broader application context.

Bridge operates an orchestration-first Travel Rule platform with pluggable protocol support, counterparty policy management and audit-grade reporting. To discuss integrating Travel Rule into your VASP stack, reach out through our contact page or review our broader identity infrastructure.