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

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

Creating an inbound Travel Rule message 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 messages works

The process of creating inbound Travel Rule messages 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 message with all its data, 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 message 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 Message.
   • 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 message.
5. If the originating VASP has been identified, they will be expected to provide the beneficiary data. The Travel Rule message gets the awaitingCounterpety 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 message 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 message gets rejected and its status changes to counterpartyMismatchedData or counterpartyVaspGeneralDecline.

Create inbound Travel Rule message

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

Step 1: Enable required rules

To apply the Travel Rule solution to inbound messages, 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 message, 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 send a Travel Rule message.

To submit the Travel Rule message, 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 message, Sumsub will process it and you will receive a weebhook. The webhook indicates the status of the message 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 message. If any action is required from their side, the Travel Rule message 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 message 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 message 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 message 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"
}