Documentation
API ReferenceChangelogFAQDashboard

Transaction scenarios

See how Travel Rule transactions are processed and what data is involved.

The following are the main cases of how Travel Rule transactions are processed for virtual asset service providers (VASPs) who must comply with the Financial Action Task Force (FATF) regulations and Recommendation 16 requirements:

Transaction data

To create a transaction and send virtual assets, you need to collect and provide the transaction details as described in the table below.

📘

Note

Mind that the set of data differs, depending on the jurisdiction requirements of a certain country.

DataAPI representationDescription
crypto addresscounterparty.PaymentMethod.AccountId
counterparty.PaymentMethod.type		Beneficiary crypto wallet address. The type is expected to be crypto.
If you have the applicant address, populate the applicant.PaymentMethod.* fields.
originatorInfoapplicantId in the request string
or applicant.* element.		If you already have an applicant who passed KYC, you can use the associated applicantId and our system will use the required fields from it. If the applicant is not present, you can specify their name and the required data in the transaction.
originatorVaspauthWe determine the originator VASP based on your authentication token and then populate that information from your settings. It is possible to represent another VASP if you are the custodial business. For more information, contact our support.
expected beneficiary infocounterparty.fullNameThe full name of the participant.
expected beneficiary VASP (optional)counterparty.InstitutionInfo.InternalIdIf the originator has provided the information about the beneficiary VASP, you can choose that VASP from our directory manually: /resources/vasps/-
currencyinfo.currencyCodeCurrency code (USD, GBP, BTC, etc).
chain + token (optional)info.cryptoChainCrypto chain name. Mandatory for crypto tokens only. Specifies the network name to which the token at currencyCode belongs. Empty for native tokens (e.g. for BTC, ETH). For more information, see chain codes.
amountinfo.AmountAmount of sent funds.

Successful outbound transaction

This case describes the scenario when:

  • You are a VASP, a Sumsub client and the originator of the Travel Rule transaction.
  • Your end user is registered as an applicant in the Sumsub system and wants to send a virtual asset to a beneficiary with the known name and crypto address.

Once the data is collected, you can proceed to the transaction creation:

  1. You create a transaction with the following API method providing the collected data.
POST /resources/applicants/{applicantId}/kyt/txns/-/data
  1. Upon receiving the request, Sumsub creates an internal transaction for you and performs the AML screening for both the originator and the beneficiary:
    • If the AML screening indicates no match found, the transaction gets the Approved status.
    • If the results of the AML screening are negative (potential matches are found in watchlists), the transaction status changes to Requires action, and you receive a webhook following the status change. If you want to approve the transaction, your compliance officer should confirm it manually.
  2. If there is no information about the beneficiary VASP, Sumsub uses different blockchain analysis tools or the known/previously added addresses to obtain the information. The following procedure depends on the result:
    • The counterparty VASP is not found. Sumsub marks the wallet as Undiscovered and checks the rules for undiscovered wallets. You receive the applicantKytTxnApproved webhook in case the set rules allow that.
    • The counterparty VASP is found but it is not a Sumsub client. Sumsub attempts to acquire information from the counterparty, or re-scores the transaction by timeout. In this case, the applicantKytOnHold webhook is sent to you.
  3. If the counterparty is known or found and it is a Sumsub client, Sumsub:
    • Creates a transaction with partial information (address, amount, currency and the originator) for the beneficiary VASP.
    • Sends the beneficiary VASP a webhook, informing that a transaction has been created for them, and requires them to confirm that the transaction belongs to their VASP.
  4. The beneficiary VASP confirms that the transaction address is owned by them with the following API method.
POST /{txnId}/ownershipConfirmation
  1. After the beneficiary VASP confirms the transaction address, Sumsub sends them a complete set of data regarding the transaction, and requires them to provide beneficiary details to proceed with the Travel Rule transaction.
  2. Beneficiary VASP provides the beneficiary information or sends the applicant ID for Sumsub to extract the data from the profile.
PATCH /resources/kyt/txns/{txnId}/data/applicant
  1. Sumsub re-checks the received data. If the obtained information is correct, Sumsub sends the applicantKytTxnApproved webhook to both the originator (you) and the beneficiary.
  2. You make a financial transaction within the blockchain.
  3. To enrich the information regarding the Travel Rule transaction (if reconciliation is required), send another request to Sumsub providing the financial transactionId (crypto transaction hash from the blockchain).
PATCH /resources/kyt/txns/{txnId}/data/info
  1. The beneficiary VASP receives the applicantKytTxnDataChanged webhook from Sumsub, because the beneficiary VASP needs to enrich the information regarding the Travel Rule transaction as well.
  2. Sumsub receives the reconciliation data from the beneficiary VASP.

Inbound transaction

This case describes the scenario when:

  • You are a VASP, a Sumsub client and the beneficiary of the Travel Rule transaction.
  • The transaction information comes to Sumsub from the originator.

To handle an inbound transaction:

  1. Once the transaction is created:
    • We send you an applicantKytTxnOnHold webhook.
    • We expect you to confirm that the transaction address belongs to your VASP.
  2. If the transaction address is owned by your VASP, you confirm the request with the following method.
POST /{txnId}/ownershipConfirmation

📘

Note

If you do not confirm the request, Sumsub declines the transaction, and sets the error message: address does not belong to this VASP.

  1. After you confirm the transaction address, Sumsub sends you a complete set of data regarding the transaction, and requires you to provide the beneficiary details to proceed with the Travel Rule transaction.
  2. You provide the beneficiary information or send Sumsub the applicant ID to extract the data from the profile.
PATCH /resources/kyt/txns/{txnId}/data/applicant
  1. Sumsub re-checks the received data:
    • If the obtained information is correct, Sumsub sends the applicantKytTxnApproved webhook to both the originator and the beneficiary (you) of the transaction.
    • If not, Sumsub sends the applicantKytTxnRejected webhook instead.
  2. The originator VASP makes the financial transaction within the blockchain.
  3. To enrich the information regarding the Travel Rule transaction (if reconciliation is required), the originator VASP may send another request to Sumsub, providing the financial transactionId (crypto transaction hash from the blockchain).
PATCH /resources/kyt/txns/{txnId}/data/info
  1. You receive the applicantKytTxnDataChanged webhook from Sumsub, because you need to enrich the information regarding the Travel Rule transaction as well.
  2. You send Sumsub the final data that includes the current transaction hash by the following method.

Inbound Transaction when Travel Rule information comes from another source

This case describes the scenario when:

  • You are a VASP, a Sumsub client and the beneficiary of the Travel Rule transaction.
  • You receive the transaction information (via email or any other source) from the originator who is not a Sumsub client and who intended to make a Travel Rule transaction outside the Sumsub system.

To handle an inbound transaction when the Travel Rule information comes from another source:

  1. You create a transaction with the following API method submitting the received originator data and your own data as a beneficiary.
POST /resources/applicants/{applicantId}/kyt/txns/-/data
  1. Upon receiving the request, Sumsub creates an internal transaction for you and performs the AML screening for both the originator and the beneficiary:
    • If the AML screening indicates no match found, the transaction gets the Approved status.
    • If the results of the AML screening are negative (matches are found in watchlists), the transaction status changes to Declined or Requires action, and you receive a webhook following the status change.

📘

Note

If you want to approve the Required action transaction, your compliance officer should confirm it manually.

Unhosted wallet verification

This case describes the scenario when:

  • You are a VASP, a Sumsub client and the originator of the Travel Rule transaction.
  • You are making the transaction and marking the beneficiary wallet as Unhosted (no expected beneficiary ID specified).

To handle a transaction for an unhosted wallet:

  1. You create a transaction with the following API method providing the collected data and marking the beneficiary wallet as Unhosted (paymentMethod.Type: "unhostedWallet").
POST /resources/applicants/{applicantId}/kyt/txns/-/data
  1. Sumsub attempts to locate the beneficiary VASP, marks the wallet as Undiscovered and checks the rules for Unhosted wallets.
  2. You receive a webhook:
    • applicantKytTxnApproved — if the rules for unhosted wallets allow the transaction.
    • applicantKytTxnRejected — if the rules for unhosted wallets forbid the transaction.

Non-Travel Rule eligible wallet transaction

This case describes the scenario when:

  • You are a VASP, a Sumsub client and the originator of the Travel Rule transaction.
  • You are making a transaction and marking the beneficiary wallet as non-travel rule eligible, or this fact is revealed during the checks by Sumsub.

To handle a non-Travel Rule eligible wallet transaction:

  1. You create a transaction with the following API method providing the collected data and marking the beneficiary wallet as non-travel rule eligible (if you are aware of the fact).
POST /resources/applicants/{applicantId}/kyt/txns/-/data
  1. Sumsub checks the rules for Non-travel rule eligible wallets.
  2. You receive a webhook:
    • applicantKytTxnApproved (by default) — if the rules for non-travel rule eligible wallets allow the transaction.
    • applicantKytTxnRejected — if the rules for non-travel rule eligible wallets forbid the transaction.

Unsuccessful outbound transaction

This case describes the scenario when:

  • You are a VASP, a Sumsub client and the originator of the Travel Rule transaction.
  • Your end user is registered as an applicant in the Sumsub system and wants to send a virtual asset to a beneficiary with the known name and crypto address.

To handle an unsuccessful outbound transaction:

  1. You create a transaction with the following API method providing the collected data.
POST /resources/applicants/{applicantId}/kyt/txns/-/data
  1. Upon receiving the request, Sumsub creates an internal transaction for you and performs the AML screening for both the originator and the beneficiary.
    • If matches are found in watchlists.
      • The transaction status changes to Declined.
      • You receive a webhook following the status change.
      • If this is the case, the scenario ends.
    • If potential matches are found in watchlists.
      • The transaction status changes to Requires action.
      • You receive a webhook following the status change.
      • If you want to approve this transaction, your compliance officer should confirm it manually. In this case the scenario goes on.
  2. If there is no information about the beneficiary VASP, Sumsub uses different blockchain analysis tools or the known/previously added addresses to obtain that information. The following procedure depends on the result:
    • The counterparty VASP is not found.
      • Sumsub marks the wallet as Undiscovered and checks the rules for Undiscovered wallets.
      • You receive the applicantKytTxnRejected webhook in case the set rules forbid that.
      • If this is the case, the scenario ends.
    • The counterparty VASP is found, but it is not a Sumsub client.
      • Sumsub attempts to acquire information from the counterparty, or re-scores the transaction by timeout.
      • In this case, the applicantKytOnHold webhook is sent to you.
  3. If the counterparty is known or found and it is a Sumsub client, Sumsub:
    • Creates a transaction with partial information (address, amount, currency and the originator) for the beneficiary VASP.
    • Sends the beneficiary VASP a webhook, informing that a transaction has been created for them and requires them to confirm that the transaction belongs to their VASP.
  4. The following scenario depends on:
    • If the beneficiary VASP does not confirm the transaction address is owned by them, the transaction is declined. Sumsub sets the error message: address doesn’t belong to this VASP. If this is the case, the scenario ends.
    • If the beneficiary VASP confirms that the transaction address is owned by them, the scenario goes on. Confirmation should be done with the following patch: POST /{txnId}/ownershipConfirmation.
  5. If the beneficiary VASP confirms the transaction address, Sumsub sends them a complete set of data regarding the transaction, and requires them to provide the beneficiary details to proceed with the Travel Rule transaction.
  6. Beneficiary VASP provides the beneficiary information or sends the applicant ID for Sumsub to extract the data from the profile.
PATCH /resources/kyt/txns/{txnId}/data/applicant
  1. Sumsub re-checks the received data. If the obtained information is incorrect, Sumsub sends the applicantKytTxnRejected webhook to both the originator (you) and the beneficiary. The scenario ends.

Updated about 1 month ago