Sumsub Travel Rule solution requires multistep setup alongside handling unhosted wallets, and aligning internal workflows with regulatory requirements. This guide outlines the key stages for successful implementation and operation within the Sumsub platform including managing transactions and special cases.

Follow the steps below to ensure Travel Rule compliance while maintaining a smooth user experience.

Join the Sumsub Travel Rule ecosystem

To join the Sumsub Travel Rule network:

1. Submit the VASP onboarding questionnaire. Fill out Sumsub VASP onboarding form to register your organization as a Virtual Asset Service Provider.
2. Pass the VASP due diligence review. The Sumsub compliance team will review your corporate details, UBO structure, and shareholders. This due diligence review usually takes a few business days.

🚧

Important

The first two steps must be completed and approved. Until your organization is fully approved, Sumsub cannot reliably process outgoing or incoming Travel Rule transactions on your behalf. In practice, you will not be in compliance with Travel Rule obligations until you finish this onboarding process.

3. To fully ensure the delivery of inbound Travel Rule data exchange transaction, explicitly import wallet addresses of your applicants into the Wallet Address Book, and submit identifiable user information such as the applicant ID or another unique identifier.
4. Additionally, make sure to have communicated in advance with which of the known protocols that we have interoperability with you will be interacting, as well as setting up the email address where you will be copied when we reach out to a VASP on your behalf.

Enable Travel Rule

The following is a sequence of steps to be taken to enable Travel Rule solution.

Activate the Travel Rule feature

In the Dashboard, install the Travel Rule rules bundle and any region-specific rules required for your jurisdiction from the Rules Library. These pre-built rules implement the necessary checks and workflows for Travel Rule compliance.

For example, a rule covering the FATF threshold (special handling for transfers above 1,000 EUR) may be needed if your jurisdiction requires it. You can find country-specific requirements here. Make sure all relevant rules are installed in Active mode.

Configure Travel Rule settings

Open the Transactions and Travel Rule settings in the Dashboard to tailor the solution to your needs. Notably, set the Confirmation Timeout, which indicates the waiting period for the counterparty VASP data response. See this article for the general Travel Rule settings description.

For example, you might set a 1-minute timeout for Travel Rule confirmation. If no response is received within that time, Sumsub can automatically trigger a fallback procedure or mark the transaction as failed, depending on your configuration.

Enable unhosted wallet verification

This step is optional. If you allow transfers to or from unhosted wallets, enable the Unhosted Wallet Verification feature. With this feature enabled, Sumsub can prompt users to prove they control a personal wallet. For example, they can do it by signing a message with the wallet private key or by submitting a self-declaration form. This ensures that even when the counterparty is not a VASP, the owner identity is verified.

📘

Note

If you do not enable this, you may permit high-risk, unverified transfers, which is not advisable under most Travel Rule regimes. For detailed instructions on enabling this feature, see this article.

Outbound data exchange transactions

When one of your users attempts to make an outbound transfer from your platform, Sumsub Travel Rule workflow engages before the blockchain transaction is executed.

The system exchanges the required originator and beneficiary identity data with the beneficiary VASP to ensure the transfer meets Travel Rule requirements. During this process, the outgoing transaction remains in a pending state with the Awaiting User status until the beneficiary side confirms the information or until the Confirmation Timeout elapses.

Possible outcomes for an outbound transaction

Depending on the beneficiary VASP response, the Travel Rule data exchange transaction may result in one of the following outcomes. Check out the data transfer statuses here.

Data match

The beneficiary VASP confirmed that all provided data matches their records. The transaction will get the Completed status. At this point, the Travel Rule check is satisfied and you may proceed to broadcast the crypto transaction on-chain.

Data mismatch

The beneficiary VASP reports that the information does not match their records. The transaction will get the Counterparty mismatched personal data status, and the Travel Rule check will be considered failed.

Do not send the funds. Investigate and correct any data discrepancies, then once again submit the transaction only after the information is correct.

📘

Note

Sumsub automatically declines transactions with mismatched data to maintain compliance records. There is no override for a mismatch.

Unreachable VASP or no response

If the beneficiary VASP cannot be reached via any Travel Rule protocol or does not respond within the allotted time, the transaction will get the Counterparty VASP not found or Expired status.

In this case, Sumsub triggers a fallback procedure. Your user will be prompted to manually provide the beneficiary information via a self-declaration form. This allows you to collect the required data directly from the sender:

• If the user provides the information, you can fulfil the Travel Rule requirements manually.
• If your user does not provide the information, the transaction will be marked as failed.

You can configure in your settings whether to allow a self-declaration fallback or to automatically cancel the transfer when no VASP response is received.

Counterparty decline

The beneficiary VASP explicitly declines to proceed with the transaction. The transaction will get the Counterparty VASP general decline status, indicating the beneficiary institution refused the Travel Rule data exchange.

This outcome also means the compliance check failed. Your team should notify the user that the recipient institution declined the transaction. The user might need to choose a different recipient or have the beneficiary resolve issues on their side. Sumsub will log the transaction as declined by counterparty in this scenario.

Inbound data exchange transactions

When an external user from another platform is sending funds to your platform, your user becomes the beneficiary of a crypto transfer. In this scenario, the originating VASP initiates a Travel Rule data request to your side via Sumsub.

As the beneficiary VASP, you should provide or confirm your user identity information for the originator to verify.

Usually, you will already have the beneficiary user verified KYC details on file. Sumsub will either automatically use the existing profile data or prompt your compliance team to input or confirm the details, depending on your configuration.

📘

Note

You can decide in your settings whether data is auto-filled or if manual confirmation is required for each inbound request. See this article for more information.

Possible outcomes for an inbound transaction

After you submit the beneficiary personal identifying information, Sumsub compares it with the data provided by the originating VASP. Find the possible outcomes below.

Data match

If the data you provide matches what the originator provided, you confirm the match in Sumsub. The Travel Rule check is successful. Sumsub sends a confirmation back to the originating side, and the originator transaction should get the Completed status, allowing them to proceed with sending the funds.

From your perspective, the incoming transfer is now approved pending the actual on-chain settlement.

Data mismatch

If the information you have on your user does not match the originator data, you should reject or fail the data confirmation in Sumsub. This will send a mismatch notification to the originator.

On their side, the transaction will get the Counterparty mismatched personal data status, alerting them that your institution found a discrepancy. The Travel Rule exchange is considered failed due to the mismatch, and you should not credit the incoming funds to the user account.

Investigate the cause of the mismatch — it could be a mistake or a sign of potential fraud. Typically, the originator will need to cancel or hold the transfer on their end until the information is corrected. A new Travel Rule data exchange with corrected details would be required.

General decline

Even if the data technically matches, you have the option to decline the incoming transaction for other reasons. In Sumsub, you can send a general decline message instead of a confirmation. This will terminate the Travel Rule exchange. On the originator side, they will get the Counterparty declines the transaction status, indicating that your institution chose not to accept the transfer.

Use this option judiciously — for example, if the sender or funds are flagged by sanctions or other compliance checks beyond the Travel Rule scope. Ensure you have an internal process for when to issue such a decline and how to communicate the decision. The funds should not be accepted into the user account in this case.

❗️

Important

As the beneficiary VASP, you cannot override a failed Travel Rule check. If there is a mismatch or if you issue a decline, Sumsub will mark the transaction as failed or non-compliant. The crypto transfer should not be completed outside the system in these cases, as doing so would violate Travel Rule obligations.

Inbound data exchange transaction (no prior creation)

In some cases, you might detect an incoming on-chain crypto transfer to your platform wallet, but no corresponding Travel Rule transaction was received from the originator. This can happen if the sending institution has not implemented Travel Rule support or failed to send the data. To remain compliant, you must manually initiate a Travel Rule data exchange on your side.

The following is a sequence of steps to be taken to create the inbound Travel Rule data exchange transaction.

Step 1: Check for existing transactions

Creating an inbound data exchange transaction implies that such transaction should have been created, but due to technical or jurisdictional issues, it was not. However, we recommend checking for any existing transactions to avoid duplication before initiating a new inbound Travel Rule data exchange transaction.

Use this API method to verify whether a transaction with similar parameters — such as specific crypto hash and sender wallet — has already been created.

Step 2: Identify the incoming transfer

Since no automated Travel Rule data exchange took place, this incoming transfer currently lacks the required compliance information. The funds should be placed on hold until you can obtain and verify the originator details.

Step 3: Collect originator information manually

Gather as much information as possible about the sender of the funds. Your goal is to assemble enough data to satisfy regulatory requirements for the Travel Rule and to perform a proper compliance check. Typically, you will need:

• Originator full name. Often obtained from your user who knows who sent them the funds.
• Originator wallet address. This can be retrieved from the blockchain transaction details (the address that sent the crypto).
• Additional details. For instance, the originator VASP or exchange (if known), the transaction amount, and any reference info.

Step 4: Create inbound Travel Rule data exchange transaction

After collecting the originator details, initiate a new Travel Rule data exchange via Sumsub, as if you are the originator VASP for this one transaction:

• Use the Dashboard or this API method.
• Specify your user as the receiving party, and input all the collected originator information into the form or API request.
• Submit the Travel Rule data exchange transaction.

Step 5: Sumsub attempts VASP attribution

Once you submit the manual Travel Rule request, Sumsub will try to perform a counterparty VASP attribution:

• The system will attempt to identify the originating VASP associated with the sender wallet address using internal databases and network intelligence.
• If an originating VASP is found, Sumsub will forward the Travel Rule data request to that institution, asking them to confirm the originator information you provided.

Step 6: Manage the outcomes of the manual request

The manual Travel Rule transaction can have several outcomes, each requiring specific action.

VASP found and data matches

The identified originating VASP responds and confirms that the sender data matches their records. The transaction will get the Completed status. You can now safely credit the funds to your user account, since Travel Rule compliance has been achieved.

VASP found but data mismatch

The originating VASP is identified and responds, but indicates the data you provided does not match their records. The transaction will get the Counterparty mismatched personal data status:

• Do not credit the funds to the user. Treat this like any mismatch scenario: investigate the discrepancy by contacting the originator VASP or your user to obtain correct information.
• The transfer should remain on hold. If the issue can be resolved, you will need initiate a new Travel Rule request with corrected data or consider returning the funds to the sender.

VASP not found or no response

Sumsub cannot find any associated VASP for the originator address, or the identified VASP did not respond within your Confirmation Timeout. In this case, the transaction will get the Counterparty VASP not found or Expired status:

• Do not credit the funds. Follow your internal policy for unverified incoming transfers.
• You should return the funds to the sender wallet (since compliance requirements cannot be met).
• You can also contact your user to let them know you cannot accept the deposit without proper sender information.

General decline

In some instances, even if the data appears to match or no issues are reported, you might choose to decline the transaction due to your own compliance policies. In such case, you should mark the manual Travel Rule transaction as declined. The transaction will get the Counterparty declines the transaction status.

📘

Note

You should communicate this outcome as needed (for instance, inform your user that you cannot credit the deposit due to compliance reasons) and handle the funds according to your procedures.

Unhosted wallets

Unhosted or personal wallets are cryptocurrency wallets not managed by any exchange or VASP (for example, a user private wallet app or hardware wallet). Travel Rule requirements still apply to transfers involving unhosted wallets, but compliance must be handled differently since there is no counterpart compliance team on the other side.

📘

Note

Remember to inform your users upfront about this procedure. For example, in your UI or support materials, note that withdrawals to personal wallets over a certain amount will require a wallet ownership verification step. This helps manage customer expectations so they are not caught by surprise by the additional requirement for large transfers.

When your user sends crypto to a personal wallet:

1. You, as the originating VASP, are responsible for collecting the beneficiary identifying information. At minimum the beneficiary name and the destination wallet address. These details should be obtained from the user during the transfer process.
2. If the transfer amount surpasses the Travel Rule threshold, additional obligations might be triggered under the regulatory requirements of numerous jurisdictions. Sumsub solution will automatically include an Unhosted Wallet Verification step for such high-value transfers provided you have enabled this feature.
3. During unhosted wallet verification, the user will be asked to prove they control the destination wallet. Depending on your configuration, Sumsub can prompt the user to, for example, sign a message with the wallet private key or upload a screenshot from their wallet application.

Make sure the Unhosted Wallet Verification feature is enabled and properly configured in your Sumsub settings. You can define the conditions under which it triggers:

• Typically you would enable it for larger transfers to personal wallets (above the regulatory threshold), while allowing smaller withdrawals to proceed without added friction.
• Once enabled, Sumsub will automatically enforce this check only when applicable. This will not affect daily small transfers to personal wallets.

Verification outcome

Unhosted wallet verification may result in two possible outcomes:

• If the user successfully confirms ownership of the personal wallet within the allotted time, the Travel Rule check is satisfied, and you can proceed to send the crypto to that address.
• If the user fails or refuses to verify their wallet, the transaction will be marked as unverified or non-compliant. In such a case, you should not complete the transfer unless the verification is completed. Follow your compliance policy — you may cancel the withdrawal or require the user to use a hosted wallet instead.

Monitor the process

All outbound and inbound Travel Rule data exchange transactions along with their statuses can be monitored in real time in the Dashboard. To do that, open Transactions in the Transactions and Travel Rule section. Your compliance team can see a list of transfers with status labels such as Awaiting User, On hold, Completed, or various types of decline.

Sumsub provides clear descriptions for each status. This is useful to ensure the visibility of the entire process. For instance, if a user contacts support asking why their crypto transfer has not gone through, your team can check its status in the Dashboard and determine whether it is waiting on Travel Rule information, pending action from the user, or was blocked for compliance reasons.

Best practices

We recommend establishing internal procedures for handling Travel Rule delays or rejections before they happen. Decide in advance how your team will respond if a transaction is flagged or fails. Key questions to consider include the following.

By defining these processes ahead of time, your support and operations teams will know exactly how to handle situations when Sumsub flags a transaction.

Remember, Sumsub Travel Rule solution is highly configurable to match your risk appetite – you decide on timeouts, whether to use fallback procedures, what data to share, etc. Leverage that flexibility to strike the right balance between compliance and user experience. With the above guidelines in place, you can confidently navigate Travel Rule requirements while keeping your crypto business secure and compliant.