VASPs should prioritise interoperability once Travel Rule enforcement is broad enough that counterparties are generally willing to exchange information. At that point, the main obstacle is no longer whether the other side must comply, but whether systems can talk to each other. The practical goal is to reduce friction in PII exchange across networks, not just satisfy local compliance rules.
When interoperability should outrank Sunrise remediation
VASPs should shift emphasis from Sunrise once Travel Rule compliance is no longer the main blocker and counterparties are generally prepared to exchange data. At that point, the harder problem is operational interoperability: whether different networks, schemas, and implementations can exchange PII reliably without adding manual handling or creating inconsistent data flows.
That transition matters because Sunrise is a compliance coordination problem, while interoperability is a scaling problem. If most relevant counterparties are already on board, further work on local enforcement yields diminishing returns compared with improving message compatibility, routing, and data-handling consistency across protocol registries and identifier coordination.
The practical threshold is not perfect global compliance. It is whether the network environment has reached the point where friction in exchanging information is now the dominant source of delay, failed transfers, or repeated manual intervention. Once that happens, improving interoperability usually delivers more operational value than treating Sunrise as the first-order constraint.
What changes once Sunrise is no longer the main constraint
When the Sunrise problem is still unresolved, the main question is whether counterparties will exchange Travel Rule data at all. When that phase has mostly passed, the question becomes whether those exchanges are dependable across different vendors, jurisdictions, and message formats. The priority shifts from persuading participants to comply toward making compliant exchanges actually work at scale.
That usually means focusing on the quality of the interoperability layer: schema alignment, transport compatibility, addressability of counterparties, and the handling of partial or inconsistent data. It also means reducing the number of bespoke workflows that create operational drag and increase the chance of dropped, delayed, or misrouted information.
For VASPs, this is often the point where a standards-based approach becomes more valuable than a local-policy approach. Broader operational consistency matters more than narrowly satisfying one venue’s interpretation of the rule, because the business risk moves to failed exchange, poor user experience, and uneven control execution across counterparties.
How to judge that the priority has shifted
The best indicator is observed behaviour in the market, not the rule text alone. If most counterparties already have a practical willingness to share the required information, and the recurring failures are now technical or process-related, then interoperability has become the binding constraint.
Another useful signal is whether your team spends more time reconciling message formats and exception handling than onboarding unwilling counterparties. If the operational workload is dominated by translation, routing, and exception resolution, Sunrise has become less important than end-to-end interoperability design.
That does not mean compliance can be ignored. It means compliance is increasingly a baseline condition, while interoperability is the lever that improves throughput, reduces manual review, and lowers friction for every counterparty connection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Interoperable Travel Rule exchange depends on reliable identity and access handling between counterparties. |
| Recommendation — Standardise counterpart identity and access controls so exchanged Travel Rule data can be trusted across networks. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | Cross-network protocol interoperability often depends on shared service and transport environments. |
| Recommendation — Review shared-service and platform controls that affect secure cross-organisation data exchange. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Interoperability hinges on stable, well-managed network and protocol pathways between participants. |
| Recommendation — Manage network and protocol paths to reduce interoperability failures and exception handling. | ||
Practitioner Guidance
What to prioritise: Prioritise interoperability when counterparties already show routine willingness to exchange Travel Rule data, and Sunrise is no longer the main barrier to participation. At that stage, the differentiator is reliable cross-network execution, not basic rule acceptance.
What to verify: Verify that your highest-volume counterparties can exchange the required fields without manual rework, repeated format translation, or exception-heavy fallback paths. If interoperability failures are recurring at the message layer, treat that as the real bottleneck.
Decision rule: If the main failure mode is “we cannot get the other side to comply,” keep Sunrise reduction and counterpart onboarding high on the agenda. If the main failure mode is “we both comply, but the systems do not interoperate cleanly,” move priority to protocol compatibility, message quality, and routing consistency.
Practitioner takeaway: Sunrise is the gating problem early on, but once counterparties are generally ready to exchange data, interoperability becomes the constraint that determines whether Travel Rule compliance works in practice or only on paper.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- How should security teams prioritise NHI remediation in cloud environments?
- When does a machine identity become a compliance problem?
- What problem does ownership attribution solve for service accounts and API keys?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
