End-to-end Travel Rule lifecycle

This overview follows a Travel Rule message from customer intent through message exchange, 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 and the incoming transactions workflow.

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

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.

• PENDING - The message has been accepted but is waiting for routing context or additional data. 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.

• Sync - Only the initial PENDING or DELIVERED response for outgoing Travel Rule messages is synchronous.
• 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.

• Outgoing transactions overview
• Incoming transactions workflow
• Required Travel Rule data