End-to-end Travel Rule lifecycle

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.

• The typical lifecycle from intent and withdrawal to Travel Rule messaging
• How the synchronous response becomes the first decision point
• How counterparty status updates support two-way communication
• 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.

For normal Travel Rule message exchange, the API owns the initial status:

• When you create an OUTGOING Travel Rule message, CryptoSwift sets the initial status automatically.
• When you receive an INCOMING Travel Rule message from another VASP, CryptoSwift also sets the initial status automatically.

After the message exists, the relevant counterparty can update the status to communicate the workflow outcome:

• Outgoing pre-transaction flow - The originator VASP can update its OUTGOING message to CANCELLED when it decides not to broadcast the on-chain transaction, or add the transactionHash when it proceeds with the payment.
• Incoming response flow - The beneficiary VASP can update its INCOMING message to CONFIRMED or DECLINED when responding to the incoming Travel Rule message.

These status updates are reflected back to the counterparty, so both VASPs see the same outcome and can keep their internal holds, release decisions, and audit records aligned.

When the originator VASP adds a transaction hash in a pre-transaction flow, treat that update as the originator's approval to proceed. The on-chain payment has been executed, the Travel Rule record is linked to settlement, and no further sender-side status update is expected. In a post-transaction flow, the transaction hash is already present at creation time, so the originator side is effectively send-and-forget and cannot later cancel the message. The beneficiary VASP can still respond with CONFIRMED or DECLINED if their workflow requires it.

The exception is local backfill. If you create an INCOMING Travel Rule message for yourself because the originator did not send one, you can choose the status during creation or update it later. This is a record-keeping workflow for your own books, not a message received from the originator VASP.

The sequence diagrams below show how status and settlement updates move between the originator VASP, beneficiary VASP, and CryptoSwift.

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 and cancel the transaction before settlement

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.

• 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 beneficiary VASP reviewed an INCOMING message and confirmed or declined the Travel Rule data. For DECLINED, statusReasoning is required.
• CANCELLED - The originator VASP cancelled an OUTGOING pre-transaction flow before broadcasting the on-chain payment. This is a terminal compliance-logged state and requires a non-empty statusReasoning.
• 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 - 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, DECLINED, or CANCELLED 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 is set by CryptoSwift. Make sure to update the status to CONFIRMED or DECLINED so the originator VASP receives an outcome and your audit trail stays complete.
• Backfilled incoming records - When you create an INCOMING message for yourself, you may set the status during creation or update it later because the record represents your own backfilled evidence, not a counterparty-delivered Travel Rule message.

• Outgoing transactions overview
• Travel Rule Risk Score
• Rule Engine
• Incoming transactions workflow
• Required Travel Rule data