Create and process inbound transactions

Learn how to send inbound Travel Rule transactions via API.

This page explains the process of VASP identification and describes how to create inbound Travel Rule transactions.

How it works

For inbound transactions, the process of VASP identification includes the following steps:

  1. Your VASP receives a deposit transaction in their wallet on behalf of their user.
  2. The customer VASP sends Sumsub a JSON transaction with all its details.
  3. Sumsub checks if the recipient VASP is a member of the Sumsub’s ecosystem. If yes, the transaction is supposed to be accompanied with a Travel Rule transaction in your Sumsub dashboard.
  4. The sender VASP receives a notification via the webhook and in the dashboard to confirm the transaction details, such as the wallet address, counterparty name, and relevant PII.
  5. Upon confirmation, Sumsub exposes the PII of the wallet and applies the Travel Rule rules depending on the recipient's VASP settings (you will have to query the transaction with the transaction ID to get the full details via the API).
  6. Sumsub checks the beneficiary information for AML hits (against AML lists, sanctions databases, etc.) based on the response. Applicable rules include:
    • Not enough beneficiary information
    • Travel Rule: Counterparty AML Screening
    • Travel Rule: Counterparty AML Screening - True Positive Hit
    • Travel Rule: Counterparty AML Screening - Hits to review
  7. The transaction is approved, rejected, or put on hold based on the rules you applied and the target VASP’s response. Applicable rules include:
    • Travel Rule: Pending counterparty VASP action
    • Travel Rule: Counterparty customer name mismatch
    • Travel Rule: Customer name mismatch
    • Travel Rule: Wallet does not belong to the counterparty VASP
    • Travel Rule: Counterparty VASP confirmed data mismatch
    • Travel Rule: Counterparty VASP did not respond
  8. In case the Travel Rule transaction in your Sumsub dashboard does not accompany the transaction, Sumsub performs target VASP attribution and identifies if the recipient VASP is on the Sumsub-supported network. Such a transaction will already have a Travel Rule transaction status like Counterparty VASP not found or Counterparty VASP not reachable.
  9. Based on the relevant rules, VASP can decide how to treat the transaction. Applicable rules include (you can also set up custom rules in line with your compliance requirements to screen these transactions and take a risk-based approach where permissible):
    • Travel Rule: Counterparty VASP not found
    • Travel Rule: Sunrise VASP (Jurisdiction)
    • Travel Rule: VASP Screening (Due Diligence Status)
  10. The transaction is approved, rejected, or put on hold based on the rules you applied and the target VASP’s response.
  11. A respective alert is sent to your VASP’s compliance team.

📘

Note

Unhosted wallet verification may not be applicable to inbound transactions. Consider having your users declare that this is an unhosted wallet before sending them a verification link.

Get started

To create an inbound transaction:

  1. In the Dashboard, open the Rules Library page, 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. Mind that rules you install remain in Test mode until you activate them.
  2. Generate an APP token, as described in this article.
  3. Send a single transaction or upload transactions in bulk having the type field set to travelRule. See Request examples for references. Once the transaction is created, you will receive the applicantKytTxnAwaitingUser webhook.
  4. Enrich the transaction with the Travel Rule data, as described in this article.
  5. Move the transaction, as described in this article.
  6. Check the transaction status. You will receive one of the following webhooks, depending on the triggered rules:
  7. Update the transaction with the blockchain hash once it is fully confirmed on your side.
  8. Add a tag to the transaction if needed.
  9. Wait for the applicantKytTxnDataChanged webhook.