Skip to content

End-to-end Travel Rule lifecycle

A high-level narrative of the Travel Rule message lifecycle from intent to record-keeping.

This overview follows a Travel Rule message from customer intent through message exchange, synchronous decisioning, counterparty response, and record-keeping. It is designed as a shared map for compliance, operations, and engineering teams.

From here, jump into the detailed outgoing transactions overview, the incoming transactions workflow, and the Rule Engine.

What you'll learn

  • The typical lifecycle from intent and withdrawal to Travel Rule messaging
  • How the synchronous response becomes the first decision point
  • How counterparty responses lead to confirmation or decline
  • Where record-keeping and evidence capture fit into the flow

Status lifecycle

The initial outgoing Travel Rule submission is synchronous: you get an immediate response to your Create Transaction call. Counterparty responses are asynchronous and arrive later via webhooks or polling.

The synchronous response is the first decision point

For post-transaction workflows, the synchronous response confirms that the Travel Rule message has been created after the blockchain transfer already exists. For pre-transaction workflows, the same response becomes an immediate decision point before funds move.

Depending on your setup, the synchronous response can provide:

  • Travel Rule message status
  • counterparty routing or delivery context
  • Travel Rule Risk Score
  • Rule Engine decision outcome

Use that response to decide whether to:

  • proceed immediately
  • wait for a defined period
  • send the transaction for review
  • block the transaction

If you configure the Rule Engine, CryptoSwift evaluates those policies as part of message creation and returns the outcome in the same decision window. Even when the synchronous response is enough to continue, you must still process later asynchronous updates because the counterparty response and final lifecycle state can change afterwards.

How to interpret statuses

  • PENDING - The message has been created but is waiting for routing context or additional data, as CryptoSwift has been unable to identify the beneficiary VASP. This is common when the beneficiary wallet address is unknown to CryptoSwift at submission time.
  • DELIVERED - The message reached the counterparty VASP. From here, a response is expected asynchronously.
  • CONFIRMED / DECLINED - The counterparty (or you, for inbound messages) has reviewed and approved or declined the Travel Rule data.
  • FAILED - The message could not be processed due to a system error. Indicates an internal issue within CryptoSwift that needs to be resolved by the CryptoSwift team.

Operational expectations

  • Sync - The initial outgoing response is synchronous and should be treated as a decision point. In addition to PENDING or DELIVERED, your integration may use returned routing, risk, and workflow outcomes to decide what happens next.
  • Async - CONFIRMED or DECLINED arrives later via webhook or polling. If the initial response is PENDING, a DELIVERED status update can arrive asynchronously once routing is resolved.
  • Incoming responsibilities - When you receive a Travel Rule message, the initial status of the message will be DELIVERED. Make sure to update the status in CryptoSwift so the originator VASP receives an outcome and your audit trail stays complete.

Next steps