Travel Rule compliance is becoming a vendor selection problem

At a glance

What this is: This is a Travel Rule compliance and vendor-selection guide that links global obligations to the capabilities VASPs should evaluate in a solution shortlist.

Why it matters: It matters because IAM and compliance teams need to align identity, data exchange, and governance decisions before implementation choices harden into operational risk.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Sumsub's guide to Travel Rule compliance and vendor selection

Context

The Travel Rule requires virtual asset service providers to collect and transmit originator and beneficiary information for qualifying transfers, which turns compliance into an identity and data-governance problem rather than a purely legal one. For teams building programmes around Travel Rule compliance, the practical challenge is choosing a partner that can support the required data exchange without creating new blind spots in control ownership or auditability.

The guide is structured to help VASPs separate foundational compliance education from solution evaluation. That matters because the same programme decisions that shape Travel Rule reporting also affect how identity, access, and third-party exchange workflows are governed across the wider security stack.

Key questions

Q: How should VASPs choose a Travel Rule compliance solution?

A: VASPs should choose a solution by first mapping their jurisdictional obligations, then testing whether the platform can exchange required counterparty data, preserve evidence, and handle exceptions without manual workarounds. The best-fit product is the one that supports governance and auditability in the markets where the VASP actually operates, not the one with the most features.

Q: Why does Travel Rule compliance create governance risk for crypto firms?

A: Travel Rule compliance creates governance risk because it requires accurate identity data exchange across counterparties, jurisdictions, and internal control owners. If the organisation cannot prove who sent what, when it was sent, and how exceptions were handled, it has a control problem as well as a compliance problem.

Q: What do teams get wrong when evaluating Travel Rule vendors?

A: Teams often over-focus on product demonstrations and under-focus on control evidence. A vendor may appear capable in a demo but still fail to support jurisdictional variation, traceable message handling, and defensible recordkeeping under review.

Q: Who should own Travel Rule compliance decisions?

A: Ownership should sit across compliance, legal, operations, and security rather than inside procurement alone. Travel Rule controls depend on how identity data is handled and proved, so the organisation needs clear control ownership before any implementation choice is finalised.

Technical breakdown

Travel Rule compliance obligations and enforcement landscape

The Travel Rule is a regulated information-sharing requirement, not just a reporting checklist. In practice, VASPs must be able to identify counterparties, transmit required originator and beneficiary data, and preserve evidence that those controls operated as intended across different jurisdictions. FATF guidance matters because local implementations vary, so a control that satisfies one market may not satisfy another. The operational risk is not only non-compliance, but fragmented workflows that create gaps in transaction screening, recordkeeping, and accountability.

Practical implication: map Travel Rule obligations by jurisdiction before selecting a solution, and test whether the control model supports evidence retention and cross-border reporting.

Travel Rule solution and protocol landscape

Travel Rule tooling sits at the intersection of messaging, identity verification, and counterparty data exchange. Different solutions may use different protocols, formats, and trust models, which affects how information moves between VASPs and where responsibility sits when something fails. The important architectural question is whether the solution supports traceable, interoperable exchange without forcing manual exceptions into the workflow. If the protocol layer is brittle, the compliance programme inherits that fragility.

Practical implication: require protocol interoperability and traceable message handling as baseline selection criteria, not optional enhancements.

Vendor evaluation criteria for a compliant shortlist

A serious vendor shortlist should examine whether the solution can support the operating realities of Travel Rule compliance, including workflow friction, jurisdictional variance, and evidence collection. The right evaluation questions are less about feature volume and more about whether the solution lets the compliance team prove what happened, when it happened, and who was responsible. That is the difference between a tool that claims coverage and a programme that can stand up to review.

Practical implication: score vendors on evidence quality, operational fit, and governance clarity, not on interface promises or generic automation claims.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Travel Rule compliance is an identity governance problem before it is a vendor selection problem. The article’s structure shows that the real decision is not which product has the longest feature list, but whether the programme can govern counterparties, data exchange, and accountability at the same time. That is an IAM and compliance design issue, not a procurement exercise. Practitioners should treat the shortlist as a governance test, not a buying event.

The named failure mode here is compliance-by-spreadsheet. When Travel Rule obligations are tracked manually across jurisdictions, the organisation creates a control model that cannot scale with transaction volume or regulatory variation. That failure mode is familiar in identity programmes: the process exists, but the evidence is too fragmented to prove control operation. Practitioners should look for programmes that can maintain audit-grade traceability without stitching together ad hoc workflows.

Travel Rule implementation accelerates the convergence of compliance, identity, and third-party risk management. VASPs do not get to isolate the rule inside a single team because the operational controls depend on data governance, counterparty assurance, and exception handling. This makes the category similar to other identity-adjacent governance problems where the real question is not coverage, but who owns the control when the process crosses organisational boundaries. Practitioners should align ownership before tool selection hardens the operating model.

Protocol interoperability debt: the hidden governance cost is not only whether a solution works today, but whether it can keep exchanging required identity data as jurisdictions and counterparties diverge. A shortlist that ignores interoperability creates future remediation work disguised as implementation speed. Practitioners should evaluate whether the programme is buying compliance capacity or future exception handling.

Travel Rule programmes will increasingly be judged on provability, not intention. Regulators and auditors care less about whether a team has a policy document and more about whether the data path, retention path, and responsibility chain can be demonstrated after the fact. That shifts the market toward controls that are operationally legible. Practitioners should expect evidence quality to become a selection differentiator.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That operational gap is why teams should also review the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs when third-party data exchange becomes part of the control model.

What this signals

Travel Rule programmes will increasingly be judged by whether they can prove control operation across counterparties, not by whether they can produce a policy document. That shifts selection criteria toward traceability, retention, and exception handling, especially where multiple jurisdictions create overlapping reporting obligations.

Compliance-by-spreadsheet: this is the hidden programme failure where requirements are tracked manually, evidence is scattered, and control ownership disappears between legal, compliance, and operations. Once that pattern takes hold, remediation becomes more expensive than selecting a better operating model up front.

Teams that already struggle with third-party identity exposure should treat Travel Rule implementation as a broader governance signal. The same control habits that fail for supplier access usually fail for regulated data exchange, so the programme needs one accountable owner for evidence, one for workflow, and one for escalation.

For practitioners

• Map jurisdiction-by-jurisdiction obligations first Build a matrix of Travel Rule requirements by market, including data fields, transfer thresholds, retention expectations, and counterparties. Use that matrix to determine which workflows the solution must support before procurement begins.
• Test protocol interoperability against real counterparties Validate whether the shortlisted solution can exchange required Travel Rule data cleanly across the specific VASPs and rails you use, including exception handling and message traceability. Do not rely on a generic compatibility claim.
• Demand audit-grade evidence paths Require the programme to show who approved the transfer, what data was transmitted, where it was retained, and how exceptions were resolved. If those facts cannot be reconstructed quickly, the compliance control is too weak for review.
• Separate compliance ownership from procurement ownership Assign clear control owners for policy, data exchange, recordkeeping, and third-party oversight before the vendor is selected. That prevents the chosen tool from becoming the de facto owner of an ungoverned process.

Key takeaways

• Travel Rule compliance is not only a legal question. It is a governance and identity-data problem that demands traceable control ownership.
• The strongest selection criterion is not feature count but whether the solution can prove who exchanged what, when, and under which jurisdictional rules.
• Teams that rely on manual tracking or fragmented evidence will struggle to sustain compliant operations as regulatory scope expands.

Key terms

• Travel Rule: A regulatory requirement in virtual asset transfers that obligates service providers to exchange specified originator and beneficiary information. In practice, it is a governance control over who sends which identity data, when, and under what jurisdictional rules, with evidence requirements attached.
• Virtual Asset Service Provider: A business that facilitates the exchange, transfer, custody, or administration of virtual assets on behalf of others. For compliance teams, the VASP is the accountable operating entity that must implement identity, data-sharing, and recordkeeping controls for regulated transfers.
• Audit-Grade Traceability: The ability to reconstruct a control decision, its inputs, and its outcome after the fact. In Travel Rule programmes, this means proving which data was exchanged, which policy applied, and who owned the exception or approval path.
• Counterparty Data Exchange: The controlled transmission of identity information between regulated parties during a transaction. It is not just messaging, because the exchange has to remain accurate, timely, and attributable enough to satisfy compliance, audit, and operational review.

Deepen your knowledge

Travel Rule compliance, identity-data governance, and third-party control ownership are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a regulated exchange programme from a similar starting point, it is worth exploring.

This post draws on content published by Sumsub: a guide to Travel Rule compliance and vendor selection. Read the original.