The Travel Rule is a global anti-money laundering regulation for virtual asset transfers.

It requires businesses on both ends of a transaction to exchange identifying information about the sender (originator) and recipient (beneficiary)of the transfer, such as name and wallet address.

It is the crypto equivalent of the information that has long been required to travel with traditional wire transfers.

The Travel Rule applies to Virtual Asset Service Providers (VASPs), businesses that exchange, transfer, hold, or issue virtual assets. This includes exchanges, custodians, and on/off-ramps.

Depending on the jurisdiction, brokers, certain DeFi platforms, and other intermediaries may also fall in scope. Whether a specific business qualifies as a VASP depends on the local law.

The Travel Rule comes from a global standard set by the FATF, but each jurisdiction writes it into its own law.

The varying details include the transaction threshold at which the Travel Rule applies,the data fields that are required, and the ways unhosted-wallet transfers are treated.

Sumsub lets you configure your setup to match your jurisdiction. So, the requirements that apply depend on where you're licensed. You can find the specific requirements per jurisdiction in the Travel Rule Regulatory Requirements article.

At minimum, most jurisdictions require the originator's and beneficiary's name and the wallet address, plus the transaction details. Stricter jurisdictions require more, such as a physical address or additional identifiers. The exact required fields depend on your jurisdiction.

Refer to the Transactions Operations section and the Travel Rule Regulatory Requirements article for how this maps to what you enter when creating a transaction.

The Sunrise Issue is the gap created when the Travel Rule is in force in some jurisdictions but not yet in others, like sunrise reaching different places at different times.

A Sunrise VASP is a counterparty in a jurisdiction where the rule is not yet live (or is not enforced), so it may not be set up to send or receive Travel Rule data.

You can still transact with one, but you will not always get the data exchange in return, and you will need to handle that under your own risk policy. Refer to the Transactions Operations section for how to handle transactions that arrive without Travel Rule data.

KYC is about verifying your own customer. AML screening checks customers and transactions against sanctions and watchlists. The Travel Rule is the piece that sits between firms: it governs the exchange of sender and recipient information between the two VASPs in a transfer.

They overlap, since Travel Rule data often comes from KYC you have already done (refer to the Integrations section) and you will typically AML-screen the counterparty (refer to the Add-ons section), but the Travel Rule's specific job is the inter-VASP handoff.

When the sides have different regimes, each VASP meets its own jurisdiction's requirements. In most cases the originating VASP simply needs to satisfy the rules that apply to it, and that is what governs what it must collect and send for the transfer.

Both. Sumsub has its own Travel Rule solution built to meet several regulatory requirements, and it also connects to a range of technology partners, so you can use external tools alongside it.

For the data-exchange protocols Sumsub supports, refer to the Protocols article. For the full set of partners, refer to the Travel Rule homepage. For how the partner integrations work in practice, refer to the Integrations section.

You join by signing the Travel Rule ecosystem agreement. You can do this through the registration form or as part of the Due Diligence questionnaire.

If you are already a Sumsub client, you can indicate interest by speaking to your CSM at [email protected].

Once you are in, and properly onboarded, you can exchange Travel Rule data with other VASPs in the Ecosystem.

Our pricing is flexible and based on volumes. For more information and quotes, reach out to your Customer Success Managerat [email protected].

VASPs can join the Sumsub Ecosystem by signing the Travel Rule ecosystem agreement either via the registration form, Due Diligence questionnaire, or via the agreement included in your service contract or supplemental agreement.

Our pricing is flexible and based on volumes. For more information and quotes, reach out to your Customer Success Manager at [email protected].

The solution works for a wide range of business types, including exchanges, custodians, traditional banks, OTCs, on and off-ramps, neobanks, digital asset groups, and foundations.

Each setup is configured to your specific use case and jurisdiction. If you have a specific case you need clarity on, reach out to our support team or your Customer Success Manager at [email protected].

Sumsub connects to several Travel Rule protocols (such as the Sumsub protocol, GTR, TRP, CODE, and Sygna Bridge), which let you exchange data with a large number of VASPs, including Bitpanda, Kucoin, Coinpass, OKX, Bybit, and Binance, among many others. To check a specific VASP, look it up on the Travel Rule homepage, where you can see whether it is covered and which method Sumsub uses to communicate with it.

The recommended way to integrate is through the SDK or API. The built-in integration wizard walks you through the setup step by step, including joining the Ecosystem, configuring your rules and thresholds for your jurisdiction, and testing in the sandbox before going live. Refer to our Set-up guide for the full walkthrough.

Blockchain transactions do not reveal who controls the wallet on the other side, so attribution is needed to get it identified.

VASP attribution is the process Sumsub uses to find the VASP that controls a given wallet address on behalf of its user. It works through blockchain analytics providers (refer to the Integrations section) and is supported by an internal Wallet Address Book.

VASPs are encouraged to securely add their own clients' wallet addresses to the Address Book to make identification more reliable. If no controlling VASP is found, the wallet is treated as unhosted (refer to the Add-ons section).

The VASP network is the full set of VASPs Sumsub has detected and mapped. It includes both reachable VASPs, which you can exchange Travel Rule data with through a shared protocol, and VASPs that are not currently reachable, which Sumsub has identified but cannot yet exchange data with.

The network is what attribution checks a wallet against, and it is the basis for the VASP Score (see below) and for whether a counterparty is reachable. New VASPs are added to the network weekly.

VASP Score is a general indicator of how safe it may be to work with a given VASP. It is most useful when a live Travel Rule data exchange is not possible, for example when a VASP is not connected to a shared protocol, since it gives you a read on the counterparty even without a direct exchange.

For how the score is calculated, refer to the VASP scoring article.

The VASP list covers all the VASPs Sumsub has detected, not only the ones connected to a protocol. So, a VASP can appear on the list and still be unreachable, usually because it is not on the Sumsub's protocol or any other supported protocol (refer to the Interoperability section).

The supported protocols for each VASP are displayed next to its name in the VASP list, so you can see how a given VASP can be reached. The list is also retrievable via API for existing customers, using the get available VASPs endpoint.

There are two possible scenarios.

An unreachable VASP is not connected to any of Sumsub's supported protocols, so the data cannot be sent to it, and no response can come back. If an email exists for that VASP, Sumsub contacts them through the Email Notification Tool, which invites them to join the Ecosystem. Reaching out this way does not change the VASP's Travel Rule status.

An unresponsive VASP is one you can reach but that doesn't reply to the data-exchange request. How you handle this is governed by your own risk policy. Common options are to hold or decline the transaction, or to stop transacting with that counterparty.

Each VASP has a response-rate status that tells you how reliably it replies to incoming Travel Rule transactions:

Responsive means the VASP responds to at least 10% of incoming transactions.

Unresponsive means it responds to fewer than 10%.

In evaluation means there is not enough information to determine a rate. This typically applies to VASPs that are still integrating or not yet live.

Sumsub offers a range of reports. You can export data for an individual transaction, a group of transactions, or as regulatory reports for audits and filings.

You can create a transaction through API, in the Dashboard, or by CSV upload, depending on how much you want to automate.

The two main flows are outbound (initiating the data exchange before a withdrawal) and inbound (initiating the data exchange after a deposit).

For more information, refer to the following articles: Submit Travel Rule transactions via API, Before withdrawal: initiate outbound data exchange, After deposit: create incoming data exchange.

For most jurisdictions the core required fields are the full name, wallet address, and transaction details, for both the originator and the beneficiary.

Stricter jurisdictions require more, such as a physical address or additional identifiers (for example, certain VARA requirements). The fields that apply to you are listed in the Regulatory Requirements article.

The key point about beneficiary data: you have to collect it from your own user before creating the transaction. Sumsub does not know or auto-fill the counterparty beneficiary's details, so if your jurisdiction requires the beneficiary's name and address, you need to request that from your user and enter it.

If you already use Sumsub for KYC, some originator fields can be pulled from your applicant's existing profile (refer to the Integrations section). If you do not use Sumsub for KYC, you need to create the transaction with the necessary applicant information yourself.

Not as a per-transaction choice. What happens is that Sumsub only attempts to communicate the data exchange when the transaction amount is above the threshold specified in your settings. You configure that threshold to match your jurisdiction's requirements (see the Travel Rule regulatory requirements section

We recommend still creating such transactions in your Sumsub Dashboard as these data points are useful in a broader transaction monitoring context.

Transactions created that fall below the threshold will have a Not Applicable travel rule status assigned to them.

Cumulative tracking isn't automatic. To track transactions that add up toward a limit value, rather than a single transaction crossing it, you create a custom rule that aggregates against that threshold. For more information, refer to the Create custom rules article.

You manage rules in the Dashboard. Rules let you act on the data points returned during a transaction, such as risk signals or screening results, to automate decisions. For more information, refer to the following articles: Create custom rules and Manage rules.

You can also use Summy AI to describe the rules you want to create in plain language.

Every transaction has an Events section that shows the Travel Rule process step by step, with detailed statuses for each stage. The Travel Rule status is visible on the transaction itself, along with the counterparty VASP name, the PII, and the transaction details. These can be exported in a transaction report.

For the full set of Travel Rule transaction statuses and what each one means, refer to the Statuses, lifecycle, and outcomes article.

It affects only the Travel Rule status, not the movement of funds. Marking a transaction as rejected in Sumsub sets its Travel Rule outcome. It does not block, reverse, or release the actual on-chain deposit or withdrawal on your platform.

Sumsub tracks and records the Travel Rule check; acting on the underlying funds is something you do in your own system, based on that outcome. As a VASP, the actual movement of funds is handled on your side, based on the feedback received from Sumsub.

Re-initiating works the same way creating a new transaction does. Once you have the information you need, create a new Travel Rule transaction as described at the beginning of the section.

For more information, refer to the following articles: Submit Travel Rule transactions via API, Before withdrawal: initiate outbound data exchange, After deposit: create incoming data exchange.

You can see all transactions for a given user in the Transactions tab of the dedicated applicant profile.

Sumsub sends webhooks at each stage of transaction processing, so you can track status changes as they happen. To get the full transaction details behind a webhook, you then call the transaction endpoint.

You can also watch for specific data points in the response and act on them in your rules. For the webhook reference, refer to the Transaction monitoring webhooks article, and for the endpoint details, refer to the Get transaction endpoint article.

Depending on your settings, Sumsub automatically processes a repeat transaction once there has already been a completed Travel Rule data exchange involving that counterparty wallet address, so you do not have to repeat the exchange each time.

You can not test on production, as this involves exchanging real PII with other VASPs for real underlying transactions, so the majority of testing is expected to be done in the Sandbox. Follow the steps listed in the Test data exchange guide to run a test exchange end to end.

This is the case where you receive a deposit that did not come with a preceding Travel Rule data exchange request from the sending side. When this happens, request the sender information from your own user, then create an incoming data exchange following the After deposit: create incoming data exchange guide.

Inbound Travel Rule transactions that other VASPs send to you are not billed. Your role is to respond automatically with the required information. You are only charged for transactions you originate, so in cases described above, you will be the originating VASP.

Sumsub supports five blockchain analytics providers: Chainalysis, Crystal, Merkle Science, TRM Labs, and Elliptic. There's no default; you choose which provider to use.

Providers connect in one of two ways. Native means Sumsub provides the integration directly. BYOK (Bring Your Own Key) means you plug in your own API key from a provider you already have a contract with and get that product's functionality surfaced in the Sumsub Dashboard.

Crystal and Merkle Science are available both ways. Chainalysis, TRM Labs, and Elliptic are BYOK only.

Not every provider covers every function. All five can be used for wallet screening and transaction screening. For VASP attribution, you can use Chainalysis, Crystal, Merkle Science, and Elliptic; TRM Labs is not used for attribution.

Nothing changes in the results. BYOK and native return the same screening output. The main difference is that BYOK gives you access to that provider's own extended dashboard for investigation, mapping, and similar tasks, which every provider offers alongside the results returned into Sumsub.

Yes. Sumsub can pull the required fields from your applicants' existing profiles and use them when processing your Travel Rule transactions, so you do not collect the same originator information twice. This covers your own users' data only; you still have to provide the counterparty beneficiary information, which Sumsub does not hold (refer to the Transactions Operations section).

It is a common setup. If your user data lives elsewhere, you provide the necessary applicant information yourself when creating each Travel Rule transaction (refer to the Transactions Operations section). Nothing about the Travel Rule solution requires you to also run KYC or KYB through Sumsub.

No. Switching providers is a Dashboard change, not an integration rebuild. You re-point your rules to the new provider, and the rule logic you've already configured carries over. You do not have to reconfigure each rule from scratch.

A protocol is a Travel Rule service provider that carries out the secure exchange of transaction information required by regulators. It is the channel the data actually travels through between two VASPs.

Travel Rule data is personal information, so protocols transmit it end to end encrypted, and both the originator and beneficiary details are protected in transit and readable only by the intended counterparty.

Sumsub connects to several protocols, including the Sumsub protocol, GTR, TRP, CODE, and Sygna Bridge. For more information about each protocol's encryption and how it works, refer to the Protocols overview.

An interoperability issue happens when two VASPs are on different data-exchange protocols that don't talk to each other.

Even when both sides are willing to exchange Travel Rule data, a protocol mismatch can prevent the required information from being shared. Sumsub's connection to multiple protocols is what reduces these issues, since it can exchange data across more than one rather than being tied to a single channel.

Sumsub has done the groundwork of integrating with multiple protocols, and it uses a smart routing system to decide which one to use for a given exchange.

The choice is based on the VASP attribution results (see the Due Diligence section) and historical Travel Rule data, so the exchange is routed over the protocol most likely to reach that counterparty. Where no shared protocol is available, Sumsub falls back to the Email Notification Tool to reach the counterparty instead.

Sumsub is asset-agnostic for Travel Rule purposes. Even if an asset is not on any predefined list, you can still add it in the transaction payload and process a Travel Rule exchange for it.

You just need to specify the amount in a default currency (such as USD, EUR, or GBP), which matters if you have rules that act on a transaction value in a specific currency. In other words, an asset not appearing in a list does not prevent you from doing the Travel Rule data exchange for it.

These are two separate layers.

Travel Rule support is asset-agnostic: the data exchange works regardless of the asset.

Screening support (wallet and transaction screening) depends on the blockchain analytics providers, since screening is performed on their side. Coverage therefore varies by provider and by asset. If none of your providers covers a given asset, screening for that transaction is skipped or limited.

The absence of screening coverage for an asset does not make the Travel Rule fail. The Travel Rule exchange still completes. You simply may not get blockchain risk data back for that particular asset, and any rules that depend on that risk data will act on it. You should account for such situations in your risk policy when handling the assets your providers do not cover.

Travel Rule exchane requires no special configuration: add the asset to the payload and provide the amount in your default currency.

For screening, whether you get risk data depends on your providers' coverage of that asset. The predefined list is expanding continuously, so provider-backed screening coverage grows over time, but you are not blocked from transacting on an unsupported asset in the meantime.

Beyond the core Travel Rule data exchange, Sumsub offers several add-on capabilities you can layer on: AML Screening, Custom rules, Crypto transaction monitoring, and Unhosted Wallet Verification, each described below. Additional add-on methods such as Case Management and Payment methods check are also available.

AML Screening is an add-on that screens counterparty names against sanctions lists, watchlists, and adverse-media databases using specific providers, so a data exchange is not the only check applied to a transaction.

Results surface as risk factors you can act on in your rules, and a match is raised as an alert against the transaction for review (see the Transactions an operations section).

Custom rules let you define your own decision logic on top of the built-in rulesets, acting on the data points returned during a transaction (risk signals, screening results, thresholds, and so on). They also determine how you handle cases the standard rules do not cover, such as tracking cumulative transaction values toward a limit (refer to the Transactions Operations section).

You manage and build rules in the Dashboard. For more information, refer to the Create custom rules article.

Crypto transaction monitoring screens transactions and wallet addresses for blockchain risk, as an added compliance layer on top of the Travel Rule exchange.

It runs through the blockchain analytics providers you've connected (see the Integrations section), and the risk signals it returns appear in the transaction's case details, where the exact labels depend on the provider.

A risk-based approach is not a single product you switch on. It is the outcome you get by combining the pieces described above to match your risk policy: AML screening to catch sanctioned or high-risk counterparties, crypto transaction monitoring for blockchain risk, and custom rules to decide what happens automatically when a given risk signal appears.

You tune those together so that transactions are held, escalated, or allowed according to the risk level you're willing to accept.

Crypto transaction monitoring

Unhosted Wallet Verification confirms that your user actually controls an unhosted (self-custody) wallet involved in a transaction, which several jurisdictions require before a transfer to or from such a wallet.

It supports more than one verification method, including the Satoshi test (a small on-chain proof of control).

For the supported verification methods, asset coverage, and setup steps, refer to the Unhosted Wallet Verification article. For unsupported assets on an unhosted wallet, see the asset-agnostic handling in the Asset support section.

Sumsub acts as a data processor for the Travel Rule data you exchange, handling it on your behalf and under your instructions rather than for its own purposes.

Your data is transmitted between VASPs over encrypted, secure channels (see the Interoperability section), so originator and beneficiary details are protected in transit and readable only by the intended counterparty.

Sumsub maintains a range of security and compliance certifications. For the full, current list, along with the supporting documentation, refer to the Sumsub Trust Center.

Travel Rule data is typically retained for the duration of your contract, or until deletion is requested.