Outgoing transactions (overview)

Outgoing Travel Rule obligations can be met either concurrently with settlement or before you broadcast funds. CryptoSwift supports both patterns so you can align with internal policies, customer experience goals, and counterparty expectations.

Use this page to frame the two approaches, then choose the detailed workflow that matches your risk posture: post-transaction or pre-transaction.

• Why outgoing flows split into post-transaction and pre-transaction variants
• The policy considerations that influence each approach
• How to select the right pattern for each withdrawal type

You submit the Travel Rule payload at the same time you broadcast the on-chain transfer. This is the most common model because it minimises customer friction while still complying with Travel Rule obligations to send data "in advance of, or simultaneously with" the transfer.

Use post-transaction when:

• You prioritise fast withdrawals and can handle asynchronous counterparty responses.
• Counterparty acknowledgements are rare or delayed.
• You can manage exceptions through monitoring and follow-up.

You send the Travel Rule message first and wait for a counterparty response before releasing funds. This is best for higher-risk transfers, corridors with strict requirements, or counterparties who expect explicit approval.

Use pre-transaction when:

• Your policy requires confirmation before settlement for specific risk tiers.
• You want to avoid post-settlement rejections or disputes.
• You already have strong counterparty engagement or bilateral agreements.

Both models can coexist. Many teams default to post-transaction and switch to pre-transaction only for high-risk cases or jurisdictions with stricter expectations.

Understanding the routing logic helps operations teams decide which data to collect before approving a withdrawal.

1. Known tenant address - We first search the internal wallet registry. If the destination matches a CryptoSwift tenant wallet, the message is delivered instantly (DELIVERED in the Create Transaction response), and subsequent CONFIRMED or REJECTED updates reach you via webhook or polling.
2. Partner network match - When the address is not in our registry, we query connected Travel Rule networks. A positive match delivers the message in the same way, triggering the usual status updates from the counterparty.
3. Named beneficiary VASP - If partner networks return no results but you provide vaspInfo.beneficiaryVaspName, we match or create the beneficiary entity and deliver the message immediately. Existing tenants - or newly invited VASPs once they claim access - send their CONFIRMED/REJECTED decision through the same channels.
4. Analytics-assisted lookup - Without a beneficiary name we run blockchain analytics to identify the VASP. Matches loop back to step 3. If no provider recognises the address, the transaction stays PENDING until you add more context. In the sandbox environment these analytics calls are disabled, so unnamed addresses remain PENDING by design.

For sandbox testing you can request a list of known addresses from us, or create a second tenant account, populate My wallets, and exchange Travel Rule messages between the two without broadcasting testnet transfers. The Travel Rule payload operates independently from on-chain settlement.

The sequence below highlights the Travel Rule actions surrounding outgoing payments for CryptoSwift clients as the originator VASP.

• Outgoing: Post-transaction workflow
• Outgoing: Pre-transaction workflow
• Incoming transactions workflow