How CryptoSwift works

CryptoSwift provides the Travel Rule messaging and verification layer, while your team retains ownership of policies, approvals, customer decisions, and risk thresholds. This page explains the handoffs so compliance, product, and engineering teams can align on who does what before integration work starts.

Use it as a lightweight operating-model primer before diving into detailed workflows and data-handling guidance.

CryptoSwift is a third-party service that operates separately from the blockchain. You continue to make on-chain transactions as before, independently of the Travel Rule service. In parallel with the on-chain transaction, Travel Rule messages are created using the CryptoSwift API, stored, and forwarded to the beneficiary VASP.

As the originating VASP, you need to:

• Collect required Travel Rule data from your customers.
• Create Travel Rule messages using the CryptoSwift API or Dashboard before or at the time of making a crypto payment.

As the beneficiary VASP, you need to:

• Accept incoming Travel Rule messages and respond to them.
• Optional: backfill missing Travel Rule data when Travel Rule messages are missing for incoming on-chain transactions.

• Message exchange - CryptoSwift transports Travel Rule messages to counterparties, tracks delivery statuses, and stores an audit-ready trail of what was sent and when.
• Verification workflows - For self-hosted wallets, CryptoSwift runs ownership checks or collects evidence you can review.
• Operational visibility - The Client Dashboard and APIs expose incoming messages, status updates, and manual review queues.

• Policy decisions - Risk thresholds, approval requirements, and when to pause or reject transfers.
• Data collection - How your product gathers the required originator and beneficiary information from customers.
• Customer communication - Follow-ups, remediation requests, and disclosures for missing or incorrect data.

1. Customer intent captured - Product flow collects withdrawal or deposit details plus required identity data.
2. Compliance checks applied - Screening, risk scoring, and wallet-type decisions determine next steps.
3. CryptoSwift message delivery - You send the Travel Rule payload; CryptoSwift routes it and returns a status.
4. Counterparty response - Status updates arrive asynchronously; your team reviews and logs outcomes.
5. Record-keeping - Evidence, decision notes, and message logs are stored for audits.

• Compliance leaders who must sign off on procedures and retention policies.
• Product owners who design customer-facing flows and approval steps.
• Engineering teams who translate policy decisions into integrations and status updates.

• Designing your operations
• End-to-end Travel Rule lifecycle
• Required Travel Rule data