Hedera (HBAR) Enterprise Blockchain vs GCC-Specific Compliance Infrastructure

Introduction: The Compliance Mandate That Most Digital Asset Firms Underestimate

The FATF Travel Rule is one of the most consequential and operationally demanding compliance requirements for digital asset businesses worldwide. Originally developed for traditional banking — requiring financial institutions to transmit originator and beneficiary information with wire transfers — the Travel Rule was extended to virtual asset service providers (VASPs) through FATF’s 2019 guidance. Every GCC country that is a FATF member or MENAFATF member must implement Travel Rule requirements for virtual asset transfers, and enforcement is intensifying as jurisdictions finalize their digital asset regulatory frameworks.

The Travel Rule requires that when a virtual asset transfer occurs between two VASPs, the originating VASP must transmit specified originator information (name, account number, address or national identity number, and transaction details) and the benefiting VASP must receive and retain specified beneficiary information. This information must accompany or be immediately available alongside the virtual asset transfer itself — it cannot be stored in a separate database and produced only on request.

For most digital asset businesses, Travel Rule compliance is an afterthought bolted onto existing infrastructure using third-party messaging protocols. This article argues that protocol-level identity verification provides a fundamentally superior approach to Travel Rule compliance — one that eliminates the need for separate messaging overlays and reduces the compliance burden for every participant on the network. Learn more about Travel Rule compliance, identity verification, and VASP requirements.

Why the Travel Rule Is Architecturally Challenging for Public Blockchains

The Travel Rule creates an architectural mismatch with public, permissionless blockchains. Bitcoin, Ethereum, and other public blockchains are designed around pseudonymous addresses. When a transaction occurs on Ethereum, the blockchain records that address 0xABC sent 100 USDC to address 0xDEF. It does not record — and has no mechanism to record — that John Smith at VASP Alpha sent 100 USDC to Jane Doe at VASP Beta. The identity information required by the Travel Rule does not exist on the blockchain.

To comply with the Travel Rule on public blockchains, VASPs must implement separate messaging protocols that transmit identity information alongside (but separate from) the on-chain transaction. Several Travel Rule solutions have emerged — TRISA, OpenVASP, Sygna, Notabene — each providing a messaging layer that enables VASPs to exchange originator and beneficiary information when processing virtual asset transfers. These solutions work, but they introduce several complications.

First, counterparty discovery: before a VASP can transmit Travel Rule information, it must identify which VASP controls the receiving address. On a public blockchain where anyone can create a wallet, determining whether a particular address belongs to a VASP (and if so, which one) requires address attribution databases that are inherently incomplete. Transfers to unhosted wallets (wallets not controlled by any VASP) create a compliance gap that the Travel Rule was not designed to address and that regulators are still developing guidance on.

Second, interoperability: different VASPs may use different Travel Rule messaging protocols, creating a coordination challenge. If VASP Alpha uses TRISA and VASP Beta uses Sygna, the two systems must interoperate for Travel Rule information to flow correctly. Industry efforts to standardize Travel Rule messaging are ongoing but incomplete, and smaller VASPs face integration costs for each protocol they must support.

Third, data synchronization: the Travel Rule information transmitted through the messaging protocol must be linked to the on-chain transaction it accompanies. If the messaging protocol delivers identity information before the on-chain transaction settles, or after it settles, or if the linking mechanism fails, the Travel Rule compliance record is incomplete. Maintaining synchronized records across two independent systems (blockchain and messaging protocol) introduces operational complexity and audit risk.

How Protocol-Level Identity Resolves the Travel Rule

On a blockchain with protocol-level identity verification — where every participant is verified before they can transact and every address is linked to a verified real-world identity — the Travel Rule is satisfied by the architecture itself rather than by a separate compliance overlay.

When every address on the network corresponds to a verified identity, every transaction inherently carries originator and beneficiary information. The blockchain’s own records — showing that verified identity A sent tokens to verified identity B at time T — constitute the Travel Rule compliance record. No separate messaging protocol is needed. No counterparty discovery challenge exists (every address is attributed by definition). No data synchronization problem arises (the identity information and the transaction are recorded in the same system).

This architectural approach provides several advantages beyond simplicity. The compliance record is immutable — it cannot be altered after the fact, providing a permanent audit trail that regulators can trust. The record is complete — every transaction on the network has identity information attached, with no gaps for unattributed addresses. The record is immediate — identity information exists before the transaction executes, not after, because pre-transaction identity verification is a prerequisite for network participation.

For regulators reviewing Travel Rule compliance, protocol-level identity provides a level of assurance that messaging-based solutions cannot match. Instead of verifying that the VASP correctly implemented a messaging protocol, correctly attributed the receiving address, and correctly linked the messaging data to the on-chain transaction, the regulator can verify that the blockchain’s protocol enforces identity verification as a condition of participation. The compliance assurance shifts from the VASP’s operational execution to the infrastructure’s architectural guarantee.

Travel Rule Compliance Across GCC Jurisdictions

Every GCC jurisdiction implementing FATF standards must require Travel Rule compliance for virtual asset transfers. Bahrain’s CBB has been among the most explicit about Travel Rule requirements, including them in its 2019 crypto-asset framework and strengthening them in the 2024 update. The UAE’s federal AML/CFT framework incorporates Travel Rule obligations that apply to VASPs licensed under VARA, DFSA, and FSRA. Saudi Arabia’s eventual digital asset framework will include Travel Rule requirements as part of its FATF/MENAFATF commitments.

The specific implementation varies by jurisdiction — different thresholds for when Travel Rule information must be transmitted, different data fields required, different retention periods for Travel Rule records — but the fundamental requirement is consistent: originator and beneficiary information must accompany virtual asset transfers between VASPs.

For multi-jurisdictional compliance, protocol-level identity provides a significant advantage. Because the identity information is embedded in the protocol itself, the same compliance record serves all jurisdictions. The infrastructure does not need separate Travel Rule implementations for each GCC country — the protocol’s identity layer satisfies the Travel Rule requirements of all participating jurisdictions simultaneously, with jurisdictional configuration only needed for the specific data fields and reporting formats each regulator requires.

The Unhosted Wallet Challenge and Self-Custody

One of the most contentious areas of Travel Rule implementation is the treatment of unhosted wallets — wallets that are controlled directly by individuals rather than by VASPs. When a VASP processes a transfer to an unhosted wallet, the Travel Rule’s requirement to transmit information to the “receiving VASP” cannot be satisfied because there is no receiving VASP.

Different jurisdictions are developing different approaches to unhosted wallet transfers, ranging from outright prohibition (Switzerland’s FINMA approach for transfers above certain thresholds) to enhanced due diligence (requiring the sending VASP to verify the unhosted wallet’s owner through alternative means). The regulatory direction across the GCC appears to favor enhanced due diligence rather than prohibition, consistent with the region’s approach of regulating activity rather than banning technology.

On protocol-level compliant infrastructure, the unhosted wallet challenge is resolved architecturally. If the protocol requires identity verification for all participants, there are no unhosted wallets on the network — every wallet is linked to a verified identity. This eliminates the unhosted wallet compliance gap entirely, providing complete Travel Rule coverage for all transactions on the network.

Sources: FATF Guidance on Virtual Assets and VASPs (2019, updated 2021); CBB Travel Rule requirements; UAE AML/CFT framework; TRISA, OpenVASP, Notabene protocol documentation; MENAFATF mutual evaluations.