Improving Data Quality

You can improve Travel Rule message delivery rates by providing accurate, complete information, especially additional context whenever you have it. Travel Rule routing still depends on wallet address databases, which remain incomplete until 100% of VASPs implement the Travel Rule for all transactions and all networks interconnect. Until then, well-structured payloads are the fastest way to avoid delays.

If you want to see how CryptoSwift routes outgoing messages step by step, review the outgoing transactions overview before diving into the data tactics below.

For outgoing Travel Rule messages, one of the most valuable data points for improving delivery rates (and avoiding unnecessary delivery attempts) is the wallet type.

• If the wallet is managed by a VASP (CUSTODIAL), we must deliver the Travel Rule message to the beneficiary VASP.
• If it's a self-hosted wallet (NON_CUSTODIAL), there is no beneficiary VASP behind the address. You may still choose to create a Travel Rule message for that transfer.

If you create a message for an outgoing transfer to a self-hosted wallet, set blockchainInfo.destinationType to "NON_CUSTODIAL". This tells CryptoSwift what kind of message it is, so we do not search for a beneficiary VASP behind the address or leave the message pending for counterparty discovery.

To specify the wallet type, include the following when making the Create Transaction API call:

...
"blockchainInfo": {
  ...
  "destinationType": "NON_CUSTODIAL"
}
...

Providing this data is essential because it's not possible to determine whether a wallet is custodial or non-custodial based solely on the address. Without this information, many self-hosted wallet transactions may remain pending unnecessarily.

Need help verifying customer self-hosted wallets? Check out self-hosted wallet verification.

Another important data point is the beneficiary VASP name, which helps us better route and deliver Travel Rule messages.

There are two main ways you can gather and provide this information:

The VASP Directory is available in the Client Dashboard and through the Entities API. It can help identify a beneficiary VASP when the customer knows where they are sending funds.

You can use this endpoint to implement an autocomplete feature in your transaction screen UI, allowing users to select the beneficiary VASP from a dropdown list. Once selected, include the VASP name when making the Create Transaction API call under the vaspInfo section:

...
"vaspInfo": {
  "beneficiaryVaspName": "SwiftExchange"
}
...

If you're using blockchain analytics tools to perform AML screening, you may already receive VASP name suggestions for wallet addresses. Where available, please pass this data along in your outgoing Travel Rule messages. It significantly enhances message delivery success.

You can choose to:

• Use the VASP name provided by your user
• Override it with analytics tool data when available

Include the data in the same place when making the Create Transaction API call:

...
"vaspInfo": {
  "beneficiaryVaspName": "SwiftExchange"
}
...

Note: We do not rely solely on this data, and no PII is shared with the beneficiary VASP until they confirm ownership of the wallet address. This design helps prevent false positives.

When creating an outgoing Travel Rule transaction, make sure to provide the correct blockchain name (under blockchainInfo). You can fetch the supported Blockchain list from the CryptoSwift API.

For supported EU countries, GET /utils/checkTIN checks the structure of a natural person's Tax Identification Number using the European Commission validation service.

curl --get 'https://api-dev.cryptoswift.eu/utils/checkTIN?country=EE&tin=37605030299' \
  --header "X-Api-Key: $API_KEY"

country is a two-letter ISO 3166-1 alpha-2 code. The response contains structureValid, syntaxValid, and syntaxUnavailable together with an upstream error flag.

This check validates format and, where the national authority supplies an algorithm, internal syntax. It does not prove a person's identity, confirm that the TIN exists or was allocated, or validate legal-entity TIN formats. Treat it as an input-quality check rather than KYC evidence.

• Outgoing transactions overview
• Incoming transactions workflow
• Webhooks

• Required Travel Rule data
• PII data handling