Notifications
Clear all
Topic starter
10/06/2026 10:31 pm
TL;DR: The real shift is that Travel Rule implementation is becoming an operational identity problem, not just a compliance project, as SumSub’s Travel Rule Self-Service aims to let small and medium VASPs move to compliant crypto transfers faster with preset configurations, SDK-based flows, built-in compliance logic, and access to a network of over 2,100 VASPs, while claiming up to 35% lower user drop-off.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- Already trusted by 1,000 crypto companies, Sumsub continues to expand its Travel Rule capabilities.
- The Travel Rule SDK can reduce user drop-offs by up to 35%.
Questions worth separating out
A: Use preset workflows only after mapping them to your own policy and jurisdiction requirements.
Q: Why does Travel Rule compliance become harder as VASP networks grow?
A: Because the control problem shifts from a single implementation to many counterparties, each with different onboarding, data-sharing, and verification requirements.
Q: What do security and compliance teams get wrong about self-service transfer setup?
A: They often assume that faster setup means lower risk.
Practitioner guidance
- Define a Travel Rule control owner Assign a named owner for transfer policy, exception review, and evidence retention so compliance decisions are not scattered across product, legal, and operations teams.
- Validate preset compliance logic before production Test the default workflow against your jurisdiction mix, counterparty types, and internal policy baseline before allowing live transfers.
- Track counterparties as governed identities Maintain a record of which virtual asset service providers can receive data, what was shared, and under which transfer conditions.
What's in the full announcement
Sumsub's full post covers the operational detail this post intentionally leaves for the source:
- Preset configuration examples for moving from setup to the first compliant transfer without custom engineering.
- How the SDK-based flow is intended to fit into existing platform infrastructure and compliance operations.
- The claimed 35% drop-off reduction and how the Travel Rule SDK is positioned to affect user experience.
- Access to the network of more than 2,100 VASPs and what that means for cross-platform transfer coverage.
👉 Read Sumsub's announcement on Travel Rule self-service for VASPs →
Travel Rule self-service for VASPs: what changes for compliance teams?
Explore further
11/06/2026 2:35 am
Travel Rule implementation is becoming an identity governance problem, not just a compliance project. The moment a platform shifts from bespoke integration to self-service transfer setup, the centre of gravity moves from engineering effort to control design. The real question is no longer whether the transfer can be enabled quickly, but whether the identity, counterparty, and evidence layers remain defensible across jurisdictions. Practitioners should treat the compliance workflow as governed infrastructure, not a one-time deployment task.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% confirmed and 26% suspected.
A question worth separating out:
Q: Who is accountable when a regulated transfer workflow fails audit review?
A: Accountability should rest with the team that owns policy, configuration, and exception handling, not with the onboarding flow alone. If the compliance path is embedded in software, that software still needs human governance. Regulators will expect evidence that the platform knew what rules were in force and could show how the transfer was approved.
👉 Read our full editorial: Travel Rule self-service changes the compliance model for VASPs
