Skip to content

Visualising Travel Rule flows

Intro

The following diagrams illustrate how CryptoSwift Travel Rule messaging integrates with existing payment processes. Our objective is to ensure that compliance requirements slot into day-to-day operations without slowing customers down. These visuals highlight the post-transaction workflow as the default, with optional pivots to the pre-transaction workflow when you need upfront confirmation.

CryptoSwift high level overview

How CryptoSwift routes outgoing messages

Understanding our routing logic helps operations teams decide which data to collect before approving a withdrawal. Every outgoing Travel Rule message moves through the following decision tree:

  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.

Outgoing payments & Travel Rule messages

The following outlines the sequence of actions related to Travel Rule and outgoing payments for CryptoSwift clients as the originator VASP. Note that the diagram is simplified and does not include all actions related to crypto payments (e.g. various actions related to incoming payments on the beneficiary VASP side). It mainly focuses on the Travel Rule, the actions and sequences surrounding it.

Outgoing payments sequence diagram

Incoming payments & Travel Rule messages

For CryptoSwift clients as the beneficiary VASP, the sequence is illustrated below. Please note, that for incoming Travel Rule messages, initiating and forwarding the message via a Travel Rule service provider is the originator VASP’s responsibility. Currently there is no mechanism that could ensure that all originator VASP’s send out the Travel Rule data with each transaction.

Incoming payments sequence diagram

Next steps