You receive an inbound 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, Sumsub processes inbound Travel Rule data exchange transactions in accordance with the following 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.
• CODE and GTR protocols — we use these protocols when you receive an inbound Travel Rule data exchange transaction from the VASP that is not part of the Sumsub Travel Rule ecosystem.

🚧

Attention

In case of the CODE and GTR protocols, in Step 4: Confirm wallet address ownership and Step 5: Enrich inbound message, you will only need to perform the instructions given in the Automation tips to proceed with the data transfer.

How processing of inbound Travel Rule data exchange transactions works

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

1. Once you receive a new inbound 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.

2. Sumsub asks you for the 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. At this stage, the wallet address ownership will get the confirmed status.
   • If the walled 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 organisation.
3. Once you confirm the ownership of the wallet address and get to see the data exchange transaction details, you have to provide the beneficiary PII stored by your organization for data comparison purposes.
4. 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:
   • 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 do not match the PII stored by the beneficiary VASP. The data exchange transaction will get the counterpartyMismatchedData 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.
5. If the beneficiary 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.

Confirm inbound Travel Rule data exchange transaction

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

Step 1: Receive inbound data exchange transaction

When you receive an inbound data exchange transaction, Sumsub will send you the applicantKytOnHold webhook to notify you about the new Travel Rule data exchange transaction pending your action:

{
  "applicantId": "634829375766b80001a40152",
  "applicantType": "individual",
  "correlationId": "98d4dac61c977c1b3f81d6ab78d29c3c",
  "sandboxMode": false,
  "externalUserId": "customExternalUserId",
  "type": "applicantKytOnHold",
  "reviewStatus": "onHold",
  "createdAt": "2025-01-30 11:41:55+0000",
  "createdAtMs": "2025-01-30 11:41:55+0000",
  "clientId": "coolClientId",
  "kytTxnId": "64a7dc05fbf57c624afcb72d",
  "kytDataTxnId": "b4xdq4qjh5qpo06r8cpunc",
  "kytTxnType": "travelRule"
}

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: Retrieve message data

After generating the token, you need to retrieve the data exchange transaction details in which you can see the wallet address. To do so, use this API method:

curl -X GET \
  'https://api.sumsub.com/resources/kyt/txns/id/one'

Step 4: Confirm wallet address ownership

For the secure exchange of the PII, you need to confirm that the beneficiary wallet address belongs to your applicant. To do so, use this API method to confirm or reject the wallet address ownership:

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'

📘

Automation

You can automate the confirmation process by importing your wallet addresses to Sumsub Wallet Address Book and setting confirmation mode. To implement this, in the Dashboard, go to the Transactions and Travel Rule section, open Settings, and select General.

This setting is optional for the Sumsub protocol, but required for the CODE and GTR protocols.

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

Step 5: Enrich inbound data exchange transaction

Enriching an inbound data exchange transaction allows you to do the following:

• Confirm that the wallet owner is registered at your platform.
• Provide required beneficiary PII.

At this stage, two scenarios are possible, depending on whether the applicant profile exists or not.

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" }'

📘

Automation

If you provide the wallet address as the payment method via this API method, the PII extraction from the applicant profile will be performed automatically.

This setting is optional for the Sumsub protocol, but required for the CODE and GTR protocols.

cURL

curl -X POST
     'https://api.sumsub.com/resources/applicants/6756c06e40c2f83feed050ef/payments'
     -H 'content-type: application/json'
     -d '{
          "externalId": "your_id_for_this_payment_method",
          "data": {
                 "type": "cryptoWallet",
                 "accountIdentifier": "your_crypto_wallet_address",
                 "memo": "...",
                 "currencyCode": "crypto_currency_code",
                 "cryptoChain": "crypto_chain"
            }
          }'

Non-existing 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"
            }
         }'

Step 6: Receive webhook

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:

{
  "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 do not match the PII stored by the beneficiary VASP, both VASPs will be notified about the outcome with the applicantKytTxnRejected webhook:

{
  "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"
}

After the data exchange, the data transfer status will be changed to completed. The originating VASP is then 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.