You might need to send an inbound Travel Rule data exchange transaction when you receive a blockchain transaction as a VASP, and the corresponding Travel Rule data exchange transaction has never been delivered. There are two possible cases when you may not get the inbound Travel Rule data exchange transaction:

• A technical issue, bug, etc.
• The originator operates in another jurisdiction that does not require sending Travel Rule data exchange transactions.

Creating an inbound Travel Rule data exchange transaction by yourself allows you to meet regulatory requirements and reduce associated risks. In this case, VASPs become part of the after-on-chain verification process. You will act as a beneficiary, whereas the counterparty will act as the originator.

How creating of inbound Travel Rule data exchange transaction works

The process of creating inbound Travel Rule data exchange transaction consists of the following:

1. You install the rules that initiate the Travel Rule checks and let you act on the results.
2. Then you send a Travel Rule data exchange transaction with all its details, including:
   • Information about the originator and the originating VASP.
   • Information about the expected beneficiary and, if known, the beneficiary VASP.
   • Blockchain transaction ID.
3. Once the settings are adjusted and all the data is sent, Sumsub processes the Travel Rule data exchange transaction and performs the originating VASP attribution:
   • VASP is identified and reachable — the originating VASP is available in the Sumsub network, they will get notified about your Travel Rule data exchange transaction.
   • VASP is not identified or not reachable — Sumsub will not be able to reach the originating VASP.
4. You can track the data transfer status in the Transactions and Travel Rule -> Transactions section to see the status of your Travel Rule data exchange transaction.
5. If the originating VASP has been identified, they will be expected to provide the beneficiary data. The Travel Rule data exchange transaction gets the awaitingCounterparty status.
6. Once the beneficiary data has been provided by the originating VASP, Sumsub cross-check this data with the data collected for the beneficiary earlier during identity verification. This will be done automatically and may cause a few scenarios:
   • Data match — data provided by the originator matches the beneficiary data collected previously. The Travel Rule data exchange transaction gets completed and obtains the corresponding status — completed.
   • Data mismatch or other issues — data provided by the originator does not match the beneficiary data collected previously or there were some other issues identified. The Travel Rule data exchange transaction gets rejected and its status changes to counterpartyMismatchedData or counterpartyVaspGeneralDecline.

Create inbound Travel Rule data exchange transaction

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

Step 1: Enable required rules

To apply the Travel Rule solution to inbound data exchange transaction, do the following:

1. In the Dashboard, open the Rules Library.
2. Select the Travel Rule bundle and install the rules.

We recommend installing all the rules available in the bundle, as it is the quickest and easiest way to cover all of the check steps.

📘

Note

The rules you install remain in Test mode until you activate them.

Step 2: Set up timeout timers

You can set a timeout for the response and manage it accordingly if the response is not provided with the specified time:

1. In the Dashboard, open the Transactions and Travel Rule section, go to Settings, and choose Confirmation Timeout.
2. To set up the desired conditions for the data exchange transaction, select the threshold and how to treat the data.
3. To apply the set parameters, click Save.

Step 3: Generate app token

Once you have installed and enabled the rules, you will 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 4: Send Travel Rule message

After completing the setup of the desired conditions and generating the token, you will be able to submit a Travel Rule data exchange transaction.

To submit the Travel Rule data exchange transaction, use this API method, as the following example demonstrates:

{
  "txnId": "ip76jt0bs5qtdyddtoc2g",
  "type": "travelRule",
  "applicant": {
    "type": "individual",
    "externalUserId": "gca9xsk3l4o9e3ozs3tk2c",
    "nameType": "birthName",
    "dob": "1992-05-08",
    "placeOfBirth": "Paris, France",
    "address": {
      "country": "FRA",
      "town": "Paris",
      "postCode": "75001",
      "street": "Rue de Rivoli",
      "subStreet": "1"
    },
    "idDoc": {
      "number": "FR42234089",
      "country": "FRA",
      "idDocType": "PASSPORT",
      "registrationAuthority": "Ille-de-France 01"
    },
    "residenceCountry": "FRA",
    "paymentMethod": {
      "type": "account"
    },
    "firstName": "",
    "lastName": "",
    "institutionInfo": {}
  },
  "counterparty": {
    "externalUserId": "",
    "paymentMethod": {
      "accountId": "bc1q080rkmk3kj86pxvf5nkxecdrw6nrx3zzy9xl7q",
      "type": ""
    },
    "type": "individual"
  },
  "info": {
    "direction": "in",
    "amount": 0.01,
    "currencyCode": "BTC",
    "type": "",
    "paymentTxnId ": "blockchain id"
  },
  "props": {
    "customProperty": "Custom value that can be used in rules",
    "dailyOutLimit": "10000"
  },
  "txnDate": "2025-01-31 10:53:17+0000"
}

📘

Note

• The info.direction field of your transaction should contain the in value.
• The blockchain ID should be included in the following field — info.paymentTxnId.

Step 5: Receive webhook

If the originating VASP responds automatically, this step is not relevant.

Once you have sent the Travel Rule data exchange transaction, Sumsub will process it and you will receive a weebhook. The webhook indicates the status of the data exchange transaction after checking the transfer against the installed rules.

If the originating VASP is available in the Sumsub network, they will get notified about your Travel Rule data exchange transaction. If any action is required from their side, the Travel Rule data exchange transaction status will change to awaitingCounterparty, and you will receive the applicantKyKytAwaingUser webhook:

{
  "applicantId": "6447b564728bf40939a7664f",
  "applicantType": "individual",
  "correlationId": "7310f3ffddbff223cdf10221cdf12064",
  "sandboxMode": false,
  "externalUserId": "customExternalUserId",
  "type": "applicantKytTxnAwaitingUser",
  "reviewStatus": "awaitingUser",
  "createdAt": "2023-12-11 10:41:54+0000",
  "createdAtMs": "2023-12-11 10:41:54.431",
  "clientId": "coolClientId",
  "kytTxnId": "6576e772b2f80732714d1de0",
  "kytDataTxnId": "m26m980m9jd7pozq72se4",
  "kytTxnType": "travelRule"
}

Occasionally, it may happen that Sumsub will not be able to reach the originating VASP. The Travel Rule data exchange transaction status may change to counterpartyVaspNotFound or counterpartyVaspNotReachable, depending on the scenario. In this case, you will receive the applicantKytTxnRejected webhook:

{
  "applicantId": "634829375766b80001a40152",
  "applicantType": "individual",
  "correlationId": "0f5a7c828bab750775564534fc0470a8",
  "sandboxMode": false,
  "externalUserId": "customExternalUserId",
  "type": "applicantKytTxnRejected",
  "reviewResult": {
    "reviewAnswer": "RED",
    "reviewRejectType": "FINAL"
  },
  "reviewStatus": "completed",
  "createdAt": "2024-04-24 11:15:09+0000",
  "createdAtMs": "2024-04-24 11:15:09.446",
  "clientId": "coolClientId",
  "kytTxnId": "64a7dc05fbf57c624afcb72d",
  "kytDataTxnId": "j8bqz29yn491vksi9qfydw",
  "kytTxnType": "travelRule"
}

Step 6: Review counterparty VASP response

Once the beneficiary data is provided by the originating VASP, it will be cross-checked with the data you collected for the beneficiary earlier as part of the KYC process. This will be done automatically based on the applicant data you provided in your initial API call.

If the data provided by the originator matches your KYC data, then the Travel Rule data exchange transaction will get completed and the Travel Rule status will be changed to completed.

You 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": "2024-04-24 11:15:09+0000",
  "createdAtMs": "2024-04-24 11:15:09.446",
  "clientId": "coolClientId",
  "kytTxnId": "64a7dc05fbf57c624afcb72d",
  "kytDataTxnId": "uauu08x44xexbohyh4lkp9",
  "kytTxnType": "travelRule"
}

If the data provided by the originator does not match your KYC data, or there were some other issues identified, then the Travel Rule data exchange transaction will get rejected. The Travel Rule status will be changed to counterpartyMismatchedData or counterpartyVaspGeneralDecline.

You 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": "2024-04-24 11:15:09+0000",
  "createdAtMs": "2024-04-24 11:15:09.446",
  "clientId": "coolClientId",
  "kytTxnId": "64a7dc05fbf57c624afcb72d",
  "kytDataTxnId": "j8bqz29yn491vksi9qfydw",
  "kytTxnType": "travelRule"
}