A Travel Rule transaction can be described in two different ways:

Travel Rule status — shows what is happening inside the Travel Rule data exchange flow itself.
Review outcome — shows what your rules and compliance logic decided to do with the transaction. For example, approved, rejected, or put on hold.

These are related, but they are not the same thing. For example, a transaction can reach completed as a Travel Rule status. Your rules can still decide whether the transaction should be approved, rejected, or held for review.

Travel Rule transaction lifecycle

In a typical Travel Rule flow, statuses move through the following stages:

Created and routed — the transaction is created and Sumsub starts VASP attribution and counterparty routing.
Waiting for counterparty or beneficiary action — depending on the flow, the transaction may be put on hold until:
- Counterparty VASP respond
- Wallet ownership confirmation
- Applicant or beneficiary data confirmation
Resolved — the transaction is completed, rejected, or expired.
Closed — if the on-chain transaction is later linked to the Travel Rule transaction, the final state becomes finished. If the transfer is intentionally abandoned, the transaction may become cancelled.

Travel Rule transaction statuses

The following is a list of possible statuses you can get during the VASP data exchange.

UI status	API status	Typical flow	Description
Awaiting counterparty	`awaitingCounterparty`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange	The counterparty was successfully identified, and the data request exchange has been sent. Wait for the counterparty response.
On hold	`onHold`	Respond to incoming transfer requests	For inbound messages, wallet ownership has been confirmed. Review the transaction and complete the required enrichment or confirmation step.
Completed	`completed`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange Respond to incoming transfer requests	Data exchange completed. If your rules approve the transfer, proceed with the next operational step.
Finished	`finished`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange Respond to incoming transfer requests	The blockchain transaction ID was added to a previously completed Travel Rule transaction. Treat the Travel Rule flow as closed.
Cancelled	`cancelled`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange Respond to incoming transfer requests	The sender decided not to proceed with the blockchain transfer after the Travel Rule exchange, either manually or based on rules. Treat the Travel Rule flow as closed without an on-chain transfer.
Counterparty mismatched personal data	`counterpartyMismatchedData`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange Respond to incoming transfer requests	The counterparty cross-checked the data and reported a mismatch. Reject or manually review the case.
No VASP - assumed unhosted wallet	`counterpartyVaspNotFound`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange	The counterparty VASP could not be identified, or the destination is treated as an unhosted wallet. Follow your unhosted-wallet or fallback handling flow.
Counterparty VASP not reachable	`counterpartyVaspNotReachable`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange	The counterparty VASP was identified but cannot be reached through a supported protocol. Apply your fallback handling and rule logic.
Expired	`expired`	Before Withdrawal: Initiate outbound data exchange	The counterparty was identified and contacted, but no response was received within the configured confirmation timeout. Apply your timeout handling rules.
Unconfirmed ownership	`unconfirmedOwnership`	Respond to incoming transfer requests	The wallet address was declared not to belong to the expected VASP or organization. Treat the request as declined and do not continue the flow.
Counterparty declines the transaction	`counterpartyVaspGeneralDecline`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange Respond to incoming transfer requests	The counterparty declined the transaction during the Travel Rule exchange. This is especially common with connected external protocols. Treat the request as declined and follow your review process.
Not enough counterparty data	`notEnoughCounterpartyData`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange	The system does not have enough information about the second side of the transaction to continue the data exchange normally. Collect more counterparty information or follow your fallback logic.
Not applicable	`notApplicable`	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange Respond to incoming transfer requests	Travel Rule exchange was intentionally skipped based on your configuration. Continue with your configured non-Travel Rule path.
Unknown	N/A	Before Withdrawal: Initiate outbound data exchange After Deposit: Create incoming data exchange Respond to incoming transfer requests	The Travel Rule request exists, but the required Travel Rule rule is missing or not active. Install the required rule and move it from Test mode to Active mode.

When notApplicable is expected

The notApplicable status does not mean an error. It means Travel Rule was intentionally not applied because your configuration says that the transaction does not require a Travel Rule exchange.

Typical reasons include:

Transaction amount is below the configured threshold.
Counterparty is classified as a non-VASP entity.
Another configuration rule explicitly skips the Travel Rule workflow.

When finished and cancelled appear

Both statuses are terminal states.

Use finished when:

Travel Rule data exchange has already reached completed.
Blockchain transaction was actually submitted.
Blockchain transaction ID was added to the Travel Rule record.

Use cancelled when:

Travel Rule result already exists.
Sender decides not to continue with the blockchain transfer.
Transaction is intentionally abandoned before the blockchain transfer is completed.