Incoming transactions workflow

When counterparty VASPs send Travel Rule messages through CryptoSwift, you receive the data in real time. This page explains how notifications arrive, how Personally Identifiable Information (PII) becomes visible, and which operational steps keep investigations on track when information is incomplete.

1. Travel Rule message ingested - As soon as an originator VASP submits data that matches one of your confirmed wallets, we create an INCOMING transaction.
2. Delivery channel - You can consume updates through the CryptoSwift Client Dashboard, via webhooks, or by polling the Transactions API. Use webhook signatures to verify authenticity.
3. PII visibility - Sensitive fields unlock only after the destination wallet is confirmed in your "My Wallets" list (your custodial wallets used for deposits). This can be done with a single "Confirm" button click in our Client Dashboard or automated via the API. Review the disclosure logic in PII data handling to align with your privacy policies.

The sequence below illustrates the actions around inbound Travel Rule messages for CryptoSwift clients acting as the beneficiary VASP.

This diagram represents a scenario where the originator VASP uses the post-transaction flow, meaning you as the beneficiary VASP may receive the on-chain transaction before receiving the Travel Rule data. The originator might instead implement a pre-transaction flow where they send the Travel Rule message before the on-chain transfer and only send funds once a CONFIRMED status update is received from you. This is why it is important to respond to incoming Travel Rule messages.

Initially, you might have many incoming transactions without any Travel Rule data, even after the transaction arrives. Even so, it is important that each VASP using CryptoSwift sets up their systems to respond to messages. Only this way can the ecosystem move toward a fully functioning pre-transaction approach, step by step.

Keep your CryptoSwift wallet list aligned with the addresses you operate. Confirm ownership whenever a new custodial wallet appears so inbound Travel Rule messages map cleanly to your customer accounts and expose PII without delays. See here for more details.

Configure a central webhook endpoint (or monitoring queue) that forwards Travel Rule updates to the teams responsible for transaction monitoring. Make sure payloads reach both compliance analysts and any downstream case-management systems.

Define risk-based criteria (amount thresholds, risk scores, customer tiering) that determine whether funds move immediately after blockchain settlement or remain on hold pending additional checks. Document the playbook so analysts know when to pause payouts, request more data, or escalate to manual review.

When the originator VASP fails to provide Travel Rule data, you have two options:

• Backfill internally - Collect details from your customer or external sources and store them with the incoming transaction record so your audit trail stays complete.
• Submit a claim - Use the Claim Transaction endpoint to alert CryptoSwift about the blockchain transfer. We search for existing data, contact the originator VASP when necessary, and forward any recovered payloads back to you.

Read more about the technical integration for both scenarios.

Track whether analysts confirm, decline, or keep transactions pending. Update statuses in CryptoSwift so the originator VASP receives clear feedback and your own ledgers stay reconciled.

• Reconcile blockchain transactions against Travel Rule payloads regularly to detect any missing messages.
• Share this workflow with AML and customer-support teams so everyone understands what happens when additional information is requested from customers.

• PII data handling
• Improving data quality
• Webhooks

• End-to-end Travel Rule lifecycle
• Missing or incomplete Travel Rule data
• CryptoSwift Compliance Documentation