Interoperability and Trust: The Travel Rule in Institutional Crypto

THE SUMSUBER: Today, we sit down with Kirill Bondarenko, a Product Manager at Sumsub, and Pavle Krivokuća, a Product Manager at Fireblocks, to discuss how Travel Rule affects the institutional marketplace.Thank you both for taking the time to talk with us.

Let’s start with some macro context: As regulatory frameworks for digital assets become more concrete and harmonized globally, how has the Travel Rule evolved from a compliance checkbox into core market infrastructure for institutional players?

KIRILL: Retail crypto could operate for years without a strong transaction infrastructure because most flows were simple, with users depositing to exchanges or withdrawing to personal wallets.

Institutional markets work differently. Institutions are not just moving funds between wallets; they are also interacting with counterparties, often across jurisdictions.

Once transactions become counterparty interactions rather than simple wallet transfers, identity exchange becomes a necessary part of the transaction itself.

Before value moves, institutions need to know who the counterparty is, whether the transfer is permissible, and whether the process is auditable. That’s where the Travel Rule starts to function less like a regulatory checkbox and more like transaction infrastructure. In many ways, it is becoming the identity layer of institutional crypto transfers.

PAVLE: The regulatory bar was low, enforcement was inconsistent, and the counterparty ecosystem wasn't mature enough to make it meaningful anyway.

What's shifted is a combination of regulatory convergence and changing customer expectations. With things like MiCA, FATF pressure, the UAE tightening up, regulators are no longer just writing guidance; they're examining. That alone forces VASPs to take it more seriously.

But the more interesting signal, from where I sit, is the institutional customer base itself. When a bank's digital assets desk or a fund custodian moves assets across the network, they expect the compliance handshake between counterparties to be reliable and documented—not a best-effort side process.

THE SUMSUBER: We’ve seen institutional transaction flows differ fundamentally from retail flows, involving custodians, counterparties, tokenized assets, and cross-border settlement. Can you explain what changes in Travel Rule implementation when you move from retail flows to institutional flows?

PAVLE: The Retail Travel Rule is a straightforward process: the customer sends it to another VASP, and you collect and transmit the necessary information. However, institutional flows complicate matters, as the initiating legal entity may not be the beneficial owner. Tokenized assets bring additional compliance needs, and cross-border settlements can lead to conflicting regulatory expectations.

In practice, this means you need a clear separation between wallet addresses and the legal entities behind them. You need the ability to resolve who the counterparty is deterministically before a transaction is created, rather than inferring it from the address alone. You also need policy flexibility to automatically apply different Travel Rule requirements based on counterparty jurisdiction, asset type, and transaction size, without manual intervention for every case.

KIRILL: To add onto that, I think the biggest shift is that Travel Rule stops being a point check around individual transfers and becomes part of an institutional operating model. Travel Rule implementation in that context is fairly linear—identify the sender, collect beneficiary data, and exchange it with the receiving VASP.

Institutional flows are complex, often involving custodians, brokers, various trading venues, and internal asset movements. Implementing the Travel Rule requires scalable automation and reliability. Institutions need dependable counterparty discovery, automated routing to the correct communication channels, and effective handling of issues like unreachable VASPs, mismatched beneficiary data, or unsupported protocols.

THE SUMSUBER: That makes sense. How should institutions think about integrating AML, transaction monitoring, and Travel Rule into a single transaction lifecycle rather than treating them as separate compliance steps?

KIRILL: Operationally, institutions are answering a single question: Should this transaction happen or not?

Travel Rule, AML, and TM simply evaluate that decision from different perspectives. The Travel Rule ensures that the required identity data can be exchanged with the counterparty. AML evaluates the parties involved in the transfer. TM assesses the wallet's risk profile and transaction history. In many organizations, these checks still exist as separate workflows owned by different teams, which slows decision-making and fragments accountability.

A more mature approach is to treat them as inputs to a single transaction decision engine, where identity verification, wallet risk analysis, and Travel Rule data exchange contribute to a unified outcome. This is also the direction the industry is moving toward. Platforms like Sumsub bring AML screening, transaction monitoring, and Travel Rule infrastructure into a single transaction lifecycle. These systems operate together, and compliance becomes a scalable decision layer rather than a fragmented operational process.

PAVLE: Historically, these steps came in as separate vendor relationships, managed by separate teams, with separate data pipelines. It’s why institutions ended up with a compliance stack that was never designed to work together.

The consequences are manual reconciliation that should be automated, and transaction lifecycles with hard stops where an analyst is waiting on a KYT score before Travel Rule data is transmitted.

What I'd push back on slightly is the idea that integration alone solves the problem. Even when you bring these into a single workflow, you still need configurable policy logic to determine how each signal is weighted—whether a high-risk KYT score should block a transaction outright, trigger a manual review, or simply be flagged post-settlement. That calibration is highly institution-specific. A bank's tokenization desk has a very different risk appetite than a crypto-native OTC desk.

This is where an orchestration layer for compliance becomes relevant. It’s a way for institutions to define, version, and automate their own logic across the full lifecycle. The compliance outcome of a transaction should be deterministic and auditable, not dependent on which analyst happened to be on shift.

THE SUMSUBER: Interoperability is often cited as one of the biggest challenges in Travel Rule implementation. In an institutional context—especially with tokenized assets—what does true interoperability actually require?

KIRILL: Truth be told, many discussions about interoperability focus only on protocols, but protocol support is only one layer of the problem. True interoperability has several components.

First, protocol interoperability—the ability to communicate across multiple Travel Rule networks.

Second, counterparty discovery—reliably identifying which institution controls a wallet address.

Third, data interoperability—ensuring both sides interpret and validate exchanged information consistently.

Fourth, operational interoperability—predictable workflows when issues occur, such as timeouts, mismatches, or retries.

In practice, the industry often focuses heavily on the first layer while underestimating the others. For institutions handling large volumes, the main need is reliable operations. They must be confident that identity exchanges will work, even when different networks are used or when data inconsistencies occur. This is also where the ecosystem still faces structural challenges. Many Travel Rule implementations are built around closed networks, which can limit reach and fragment the market. While these networks can work well internally, institutional transactions often span multiple platforms and service providers.

True interoperability will likely require the ecosystem to move beyond isolated networks toward more open connectivity between systems.

PAVLE: The protocol layer gets most of the attention. However, it's downstream of a more basic problem: before you can exchange Travel Rule data with a counterparty, you need to reliably identify that counterparty. By that, I don’t mean just their name and jurisdiction, but their supported protocols and their jurisdictional configuration. That discovery process is still fragmented in practice, and in too many cases, still partly manual.

The address registry concept is central here because it enables mapping counterparty addresses to verified VASP identities at scale, so counterparty identification becomes a lookup rather than a manual process. Counterparty discovery is an area we're actively working on at Fireblocks. Until that layer is reliable and broadly adopted, true institutional-grade interoperability will remain out of reach regardless of which messaging protocol you're on. To address these interoperability gaps, the industry is increasingly focusing on solutions such as VASP attribution and jurisdictional rule bundles in order to reliably identify counterparties and automatically apply the correct regulatory requirements across markets.

For tokenized assets, there's an additional dimension that isn't fully resolved yet: compliance metadata ideally needs to travel with the asset, not just along with the transaction. A tokenized fund unit or bond has compliance attributes (such as transfer restrictions, investor eligibility, and AML status) that every participant in the settlement chain needs to be able to read and act on. That's a different interoperability challenge from VASP-to-VASP message exchange, and one that the industry hasn't addressed at scale yet.

THE SUMSUBER: Thank you for your insights! Finally, many institutions hesitate not because of the regulation itself, but because of operational uncertainty. Where do you see the biggest pain points today in institutional Travel Rule adoption, and how are those evolving?

KIRILL: Institutions worry about edge cases: counterparties on different protocols, unreachable VASPs, mismatched beneficiary data, unknown wallets, or jurisdiction-specific requirements. Most implementations can send a Travel Rule message. The real challenge begins with how the system behaves when something breaks.

What happens if the counterparty cannot be reached?
What if the wallet attribution is incorrect?
What if the beneficiary data does not match?

Because of this, the next stage of Travel Rule infrastructure is less about connectivity and more about operational reliability, including clear transaction states, deterministic rules, fallback communication channels, and predictable exception handling. Once that layer matures, institutions will increasingly treat the Travel Rule not as a regulatory burden but as dependable transaction infrastructure.

PAVLE: Yes, considering all that, the hesitation makes sense. If you can't reliably determine which protocol a counterparty supports, or what the current Travel Rule threshold is in a given jurisdiction, and getting it wrong means a regulator flags you for a compliance failure during an examination.

A few pain points come up consistently in conversations with our customers.

One is regulatory interpretation divergence. FATF guidance is global but non-binding, and national implementations vary significantly. Requirements in Singapore differ from those in Germany and the UAE. Institutions operating in multiple jurisdictions need tools that manage this complexity without overburdening compliance teams to track every change manually.

The other is Exchange and CeFi flows. Many institutions use exchanges to settle transactions, manage funds, and hedge risks. However, following the Travel Rule has been tough because exchanges combine client funds into shared wallets. This makes it hard to attach individual beneficiary information. The regulation mainly focuses on transfers between people rather than flows from institutions to exchanges. At Fireblocks, we have addressed this issue by providing Travel Rule support that helps institutions comply with how exchanges operate, demonstrating strong demand from our institutional customers.

Finally, there are counterparty coverage gaps. When a counterparty isn't reachable through any Travel Rule network you're connected to, the fallback is often still manual. That's operationally fine at low volumes, but it doesn't scale. Coverage is improving for sure, but unevenly across regions.

The positive trend is that the larger platforms are treating Travel Rule infrastructure as a competitive priority rather than a pure cost center. When that mindset shifts, the ecosystem matures faster.