Skip to content

Outgoing transactions (overview)

Understand outgoing Travel Rule obligations and when to use pre- vs post-transaction workflows.

CryptoSwift supports a pre-transaction flow that sends Travel Rule data before broadcast and a post-transaction flow that sends it with a hash as the transfer is broadcast. Choose the timing that meets your applicable requirements and internal controls.

First decide whether the destination belongs to another custodial provider or is customer-controlled. Use your own classification process or optional Wallet Intelligence (KYW). The pre- and post-transaction choices below focus on the custodial Travel Rule messaging path. A self-hosted destination follows your wallet verification strategy; you may also choose to create a Travel Rule message for that transfer. If you do, set blockchainInfo.destinationType to "NON_CUSTODIAL" so CryptoSwift does not search for a beneficiary VASP.

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.

Classify the wallet before choosing the flow

Before choosing a path, classify the destination with your existing process or use Wallet Intelligence (KYW) as an additional signal. Custodial destinations usually continue into VASP-to-VASP Travel Rule messaging; self-hosted or unknown destinations follow your verification or review policy.

Our Recommendation

If you already have KYT, AML, and release controls outside CryptoSwift, the post-transaction flow can add Travel Rule messaging with fewer workflow changes. Your VASP must still meet its applicable timing, data, monitoring, and record-keeping requirements.

At the same time, we recommend evaluating the pre-transaction workflow as well. It is not limited to Travel Rule delivery-based decisioning: it also gives you access to CryptoSwift's Rule Engine, which can be used to automate broader compliance workflows that combine Travel Rule data with your wider transaction decision policies.

What you'll learn

  • 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

Post-transaction vs pre-transaction: how to choose

Post-transaction flow (concurrent messaging)

You submit the Travel Rule payload as the transfer is broadcast and its hash becomes available, without waiting for final settlement. Where the applicable rule requires information in advance of or concurrently with the transfer, your VASP must operate the two submissions accordingly.

Use the post-transaction flow 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.

Pre-transaction flow (decision before settlement)

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 to use Wallet Intelligence (KYW) before message creation to decide whether the destination should be handled as custodial, non-custodial, or unknown.
  • 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.

How CryptoSwift routes outgoing messages

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 recognizes the address, the transaction stays PENDING until you add more context. These analytics calls are disabled in the Sandbox, 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.

Outgoing payments & Travel Rule messages

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

Outgoing payments sequence diagram

Next steps