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. If you want CryptoSwift to automate pre-transaction decisions, continue with the Rule Engine.

• 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 want the fastest implementation path with minimal workflow changes.
• You prioritise fast withdrawals and can handle asynchronous counterparty responses.
• Counterparty acknowledgements are rare or delayed.
• You already manage AML, KYT, or release controls elsewhere and only need to add Travel Rule messaging.

You send the Travel Rule message first and make a decision before releasing funds. That decision can use more than just a counterparty confirmation. It may combine the Travel Rule Risk Score, transaction amount, beneficiary VASP, wallet context, and Rule Engine policies.

Use pre-transaction when:

• Your policy requires a decision before settlement for specific risk tiers.
• You want to avoid post-settlement rejections or disputes.
• You want CryptoSwift to automate proceed, wait, review, or block outcomes before funds move.

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 DECLINED 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/DECLINED 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
• Rule Engine
• Incoming transactions workflow