Frequently asked questions

Below are answers to the questions we hear most often from engineering and compliance teams integrating CryptoSwift. Each answer links to the detailed guide so you can move from overview to implementation fast.

CryptoSwift is a Travel Rule compliance platform that combines a developer-friendly API with an operations-ready Client Dashboard. You can automate the end-to-end lifecycle of Travel Rule messages, while operations teams rely on the dashboard for manual reviews and low-volume workflows.

CryptoSwift is built to satisfy the FATF Travel Rule, EU MiCA Transfer of Funds Regulation, and other global Travel Rule frameworks. The platform uses the open-source STRIP JSON messaging standard to keep integrations simple and compatible with regulatory data requirements.

Use the Quickstart to create a test account and retrieve your API key. CryptoSwift provides separate Test and Production environments with different base URLs and keys. Details and URLs are listed in Test Environment.

Every request to the CryptoSwift API must include your environment-specific secret in the x-api-key header. Requests missing the header—or using the wrong key for the environment—return 401 Unauthorized. See Getting started for example calls.

No. Provide the beneficiary VASP name, email, or other contact details and CryptoSwift will deliver the Travel Rule payload, even if the counterparty has not yet joined the CryptoSwift network.

Minimum required data includes originator/beneficiary identifiers, transaction details (asset, amount, blockchain data), and wallet type. The plain-language overview is in Required Travel Rule data; for field names and payload structure, see the Travel Rule data model.

Use the post-transaction flow if you can send Travel Rule data after the on-chain transfer completes. Use the pre-transaction flow if you need counterparty confirmation before broadcasting on-chain, and then patch the hash later. See Outgoing transactions and the pre-transaction workflow for guidance.

Incoming messages are stored automatically and can be delivered via webhooks or polled from the API. To confirm or decline an incoming message, update its status via the Transactions API. See Incoming transactions.

PII is only exposed once the destination wallet is confirmed. Until blockchainInfo.isDestinationConfirmed is true, incoming payloads only show high-level participant types. See PII data handling and Confirming wallets to access PII.

Backfill missing data where possible, and use Claims when you need a formal request to the originator VASP. For step-by-step guidance, see Incoming transfers without Travel Rule data and Missing or incomplete Travel Rule data.

Wallet type must be collected from the customer and stored with the transaction; it cannot be derived reliably from the address alone. See Custodial vs self-hosted wallets and Self-hosted wallet strategy.

CryptoSwift supports cryptographic signatures, micro-transaction (Satoshi Test), screenshot uploads, and self-declaration flows for wallet ownership checks. You can implement the flows with the Wallet Verification Widget or integrate directly with the Wallet Verification API.

Register a webhook URL to receive JSON payloads for Travel Rule transactions and self-hosted wallet verification events. Verify authenticity with the CryptoSwift-Signature header as outlined in Webhook signatures. Setup steps are covered in Webhooks.

The sandbox includes predefined wallets and a simulator endpoint that lets you trigger DELIVERED, CONFIRMED, or DECLINED updates without on-chain activity. Follow Testing webhook notifications and ensure you are using the Test Environment.

Treat declines as offline compliance workflows: pause the transfer, collect missing data, document the rationale, and decide whether to cancel, resubmit, or proceed under exception. See Transaction declined or disputed.

Not immediately. The Client Dashboard lets teams send Travel Rule messages, review incoming data, manage wallets, and monitor webhooks without building custom screens. You can migrate functionality into your own product over time while keeping the dashboard for fallbacks.

Provide high-quality metadata whenever possible:

• Specify whether the destination wallet is CUSTODIAL or NON_CUSTODIAL in blockchainInfo.
• Include the beneficiary VASP name (and email) using the Entities endpoint or data from your blockchain analytics tools.
• Keep your own wallet list current via the Wallets API or dashboard so incoming transfers are recognised immediately. See Improving data quality for additional guidance.

Download the CryptoSwift compliance package for audit evidence, policies, and security documentation. See CryptoSwift Compliance Documentation.

Yes. Our engineering team routinely supports customers with solution design, implementation reviews, and custom integration questions. Contact us to discuss how we can help.