You receive a deposit Travel Rule data exchange transaction when the originating VASP attempts to transfer a virtual asset to a wallet that belongs to your applicant. Such inbound data exchange transactions can be produced by both the Sumsub Travel Rule ecosystem members and the external VASPs. As a beneficiary VASP, upon receiving the data exchange transaction, you will be prompted to either confirm or reject it. If you confirm the inbound data exchange transaction, the originating VASP is expected to submit the blockchain transaction.

Depending on the type of the originating VASP, you could receive a deposit Travel Rule exchange transaction from different protocols:

Sumsub protocol — our own Travel Rule protocol that allows us to process data and confirm data exchange when the originating VASP also belongs to the Sumsub Travel Rule ecosystem.
External protocols — Sumsub uses an external protocol when you receive a Travel Rule data exchange transaction from the VASP that is not part of the Sumsub Travel Rule ecosystem.

How processing of deposit Travel Rule data exchange transactions works

The process of managing deposit Travel Rule data exchange transactions includes the following steps:

Once you receive a new deposit Travel Rule data exchange transaction on behalf of the user, it will appear in the Dashboard. To see the data exchange transaction, go to the Transactions and Travel rule -> Transactions. Here you can also track the data transfer status.
At this stage, your data exchange transaction will get the awaitingCounterparty status.
Sumsub asks you for confirmation of the data exchange transaction details. As a beneficiary VASP, you need to confirm that the wallet address to which the Travel Rule data exchange transaction is addressed belongs to you. It should be done in order to protect Personally Identifiable Information (PII) provided by the originating VASP from being shared with unauthorised entities:
- After you confirm the ownership, you will be able to see all the PII included in the Travel Rule data exchange transaction.
- If the wallet address does not belong to your VASP, you need to mark the ownership status as unconfirmed. You will not be able to see the PII then, and the counterparty VASP will be notified about your response. If you do not confirm the request, Sumsub will decline the data exchange transaction and trigger the following rule: Travel Rule: Wallet does not belong to your organization.
Once you confirm the ownership of the wallet address and view the data exchange transaction details, you have to provide the beneficiary PII stored by your organization for data comparison purposes.
After you have provided the beneficiary PII, Sumsub conducts data cross-validation required by the Travel Rule regulations to ensure that the assets are being sent to the intended beneficiary. You could choose fields for this check in Travel Rule settings:
- The cross-validation is successful if the PII provided by the originator VASP matches the PII stored by the beneficiary VASP. The data transfer will get the completed status.
- The cross-validation is unsuccessful if the PII provided by the originator VASP does not match the PII stored by the beneficiary VASP. The data exchange transaction will get thecounterpartyMismatchedData status.
  Mind that if the applicant profile gets any status other than approved, the Travel Rule data exchange transaction will be declined as well, and the Travel Rule status will be changed to counterpartyVaspGeneralDecline.
If your VASP has confirmed the provided beneficiary PII, the originator VASP can now proceed and send the transaction to the blockchain. Once the transaction is sent, the originating VASP needs to update the blockchain ID to finish the Travel Rule process. After that Travel Rule status will be changed to finished.

🚧
Attention
In case of external protocols, in Step 3: Confirm wallet address ownership and Step 4: Enrich inbound data exchange transaction, you will only need to perform the instructions given in the Automation tips to proceed with the data transfer.
These settings are optional for the Sumsub protocol, but required for the external protocols.

Confirm deposit Travel Rule data exchange transaction

The following is a sequence of steps to be taken to receive and process a deposit Travel Rule data exchange transaction.

Step 1: Integrate webhooks

Based on your settings and data, you might need the following webhooks:

To receive webhooks to your backend, you have to configure it in the Dashboard. For more instructions, see this article.

Step 2: Generate app token

You need to generate an app token to sign your API calls. For more information on how to generate a token, refer to this article.

Step 3: Confirm wallet address ownership

When you receive a deposit Travel Rule data exchange transaction, you may need to confirm wallet ownership before accessing the PII fields.

To do this, subscribe to the applicantKytTxnCreated webhook event.

After receiving the event, retrieve the transaction via this API method and check the needMasking field.

If its value is true, you must confirm ownership. To do so, use this API method to confirm or reject the wallet address ownership.

Request example:

curl -X POST \
  'https://api.sumsub.com/resources/kyt/txns/66cd891eefa135789ce5264f/ownership/confirmed'

curl -X POST \
  'https://api.sumsub.com/resources/kyt/txns/66cd891eefa135789ce5264f/ownership/unconfirmed'

Mind that travelRuleInfo.status still has the unconfirmedOwnership value even if you confirm transaction ownership. To finalize the confirmation process correctly, enrich the data exchange transaction with the required Travel Rule data.

📘
Automation
To enable automated wallet-ownership confirmation:

Import your wallet addresses into the Wallet Address Book.

In the Dashboard, navigate to the Transactions and travel rule section and open Travel Rule settings.

In the Automated Wallet Ownership and Applicant Data Confirmation field, select either Automated validation or Simplified validation.

This setting is optional for the Sumsub protocol, but required for the external protocols.

Step 4: Enrich deposit data exchange transaction

After the previous step, or immediately if it was skipped by automation, you may need to confirm the applicant data. In this case, you will receive the applicantKytOnHold webhook.

Retrieve the transaction and inspect the travelRuleInfo.needApplicantOwnershipConfirmation field. If its value is true, applicant data confirmation is required. You can proceed with one of the following ways:

Existing applicant profile

If the beneficiary already has an existing applicant profile, you can assign the data exchange transaction to the applicant. All required PII will be automatically extracted from the applicant profile. To do so, use this API method:

curl -X POST \
     'https://api.sumsub.com/resources/kyt/txns/test_txn_id/travelRuleOwnership' \
     -H 'content-type: application/json' \
     -d '{ "applicantId": "67a0ec0b9aa095000000000f" }'

📘
Note
You may also encounter a case where an applicant has already been found based on the data provided in the transaction, and you simply need to confirm this applicant in the same way.

Non-existent applicant profile

If the beneficiary does not have an applicant profile, you must enrich the Travel Rule data exchange transaction using this API method as the following example demonstrates:

curl -X POST \
     'https://api.sumsub.com/resources/kyt/txns/test_txn_id/travelRuleOwnership' \
     -H 'content-type: application/json' \
     -d '{
            "applicantParticipant": {
              "fullName": "John Doe",
              "externalUserId": "external_user_id",
              "type": "individual"
            }
         }'

📘
Automation

To automate data enrichment for deposit transactions:

Import payment methods to applicants using this API method.

Request examples:

curl -X POST
     'https://api.sumsub.com/resources/applicants/6756c06e40c2f83feed050ef/payments'
     -H 'content-type: application/json'
     -d '{
            "externalId": "id_from_your_system",
            "data": {
              "type": "bankCard",
              "fullName": "John Doe",
              "accountIdentifier": "12345678*4321",
              "validUntil": "2030-12-01"
            }
          }'

curl -X POST
     'https://api.sumsub.com/resources/applicants/6756c06e40c2f83feed050ef/payments'
     -H 'content-type: application/json'
     -d '{
            "externalId": "id_from_your_system",
            "data": {
              "type": "bankAccount",
              "fullName": "John Doe",
              "accountIdentifier": "DE75512108001245126199"
            },
            "institutionInfo": {
              "name": "Deutsche Bank",
              "code": "DEUTDEFFXXX",
              "address": {
                "country": "DEU"
                },
              "issuer": {
                "type": "license"
              }
						}
         }'

curl -X POST
     'https://api.sumsub.com/resources/applicants/6756c06e40c2f83feed050ef/payments'
     -H 'content-type: application/json'
     -d '{
            "externalId": "id_from_your_system",
            "data": {
              "type": "eWallet",
              "subType": "PayPal",
              "accountIdentifier": "A0AAAAA00AAAA"
            }
          }'

curl -X POST
     'https://api.sumsub.com/resources/applicants/6756c06e40c2f83feed050ef/payments'
     -H 'content-type: application/json'
     -d '{
            "externalId": "id_from_your_system",
            "data": {
              "type": "cryptoWallet",
              "cryptoChain": "XRP",
              "currencyCode": "USDT",
              "accountIdentifier": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
              "memo": "12345678"
            },
            "institutionInfo": {
              "issuer": {
                "type": "license"
              }
            }
          }'

curl -X POST
     'https://api.sumsub.com/resources/applicants/6756c06e40c2f83feed050ef/payments'
     -H 'content-type: application/json'
     -d '{
            "externalId": "id_from_your_system",
            "data": {
              "type": "other",
              "subType": "your_domain_specific_type",
              "accountIdentifier": "ABC123"
            }
          }'

In the Dashboard, navigate to the Transactions and travel rule section and open Travel Rule settings.
In the Automated Wallet Ownership and Applicant Data Confirmation field, select Automated validation.

This setting is optional for the Sumsub protocol, but required for the external protocols.

Step 5: Receive webhooks

If the PII provided by you matches the PII stored by the beneficiary VASP, both VASPs will be notified about the outcome with the applicantKytTxnApproved webhook and the data transfer status will be changed to completed:

{
  "applicantId": "634829375766b80001a40152",
  "applicantType": "individual",
  "correlationId": "f24f6616020245053139a6537303a251",
  "sandboxMode": false,
  "externalUserId": "customExternalUserId",
  "type": "applicantKytTxnApproved",
  "reviewResult": {
    "reviewAnswer": "GREEN"
  },
  "reviewStatus": "completed",
  "createdAt": "2025-01-30 11:41:55+0000",
  "createdAtMs": "2025-01-30 11:41:55+0000",
  "clientId": "coolClientId",
  "kytTxnId": "64a7dc05fbf57c624afcb72d",
  "kytDataTxnId": "b4xdq4qjh5qpo06r8cpunc",
  "kytTxnType": "travelRule"
}

If the PII provided by you does not match the PII stored by the beneficiary VASP, your VASPs will be notified about the outcome with the applicantKytTxnRejected webhook and the data transfer status will be changed to counterpartyMismatchedData:

{
  "applicantId": "634829375766b80001a40152",
  "applicantType": "individual",
  "correlationId": "0f5a7c828bab750775564534fc0470a8",
  "sandboxMode": false,
  "externalUserId": "customExternalUserId",
  "type": "applicantKytTxnRejected",
  "reviewResult": {
    "reviewAnswer": "RED",
    "reviewRejectType": "FINAL"
  },
  "reviewStatus": "completed",
  "createdAt": "2025-01-30 11:41:55+0000",
  "createdAtMs": "2025-01-30 11:41:55+0000",
  "clientId": "coolClientId",
  "kytTxnId": "64a7dc05fbf57c624afcb72d",
  "kytDataTxnId": "b4xdq4qjh5qpo06r8cpunc",
  "kytTxnType": "travelRule"
}

Travel Rule data exchange transaction status update

After the successful Travel Rule data exchange, the originating VASP is expected to send the transaction to the blockchain and update the blockchain transaction ID in the Travel Rule data exchange transaction. Once the blockchain transaction ID has been successfully updated, the Travel Rule data exchange transaction status will be changed to finished indicating the closing of the transaction.

Your VASP will be notified about that with applicantKytTxnDataChanged webhook:

{
  "applicantId": "6447b564728bf40939a7664f",
  "applicantType": "individual",
  "correlationId": "fb36d7a2f2e1ac15773ec9a56f999dde",
  "sandboxMode": false,
  "externalUserId": "customExternalUserId",
  "type": "applicantKytTxnDataChanged",
  "reviewResult": {
    "reviewAnswer": "GREEN"
  },
  "reviewStatus": "completed",
  "createdAt": "2024-01-24 07:38:34+0000",
  "createdAtMs": "2024-01-24 07:38:34.994",
  "clientId": "coolClientId",
  "kytTxnId": "6576e772b2f80732714d1de0",
  "kytDataTxnId": "m26m980m9jd7pozq72se4",
  "kytTxnType": "finance"
}

Receive deposit Travel Rule data exchange transaction

How processing of deposit Travel Rule data exchange transactions works

🚧
Attention

Confirm deposit Travel Rule data exchange transaction

Step 1: Integrate webhooks

Step 2: Generate app token

Step 3: Confirm wallet address ownership

📘
Automation

Step 4: Enrich deposit data exchange transaction

Existing applicant profile

📘
Note

Non-existent applicant profile

📘
Automation

Step 5: Receive webhooks

Travel Rule data exchange transaction status update

How processing of deposit Travel Rule data exchange transactions works

🚧Attention

Confirm deposit Travel Rule data exchange transaction

Step 1: Integrate webhooks

Step 2: Generate app token

Step 3: Confirm wallet address ownership

📘Automation

Step 4: Enrich deposit data exchange transaction

Existing applicant profile

📘Note

Non-existent applicant profile

📘Automation

Step 5: Receive webhooks

Travel Rule data exchange transaction status update

🚧
Attention

📘
Automation

📘
Note

📘
Automation