Skip to content

Improving Data Quality

Introduction

You can help improve Travel Rule message delivery rates by ensuring you provide accurate and complete data—especially additional data points whenever possible. Travel Rule message delivery relies on wallet address databases to identify the Virtual Asset Service Provider (VASP) behind a wallet address. However, these databases are inherently incomplete, meaning some transactions will inevitably be undeliverable.

This will remain the case until 100% of VASPs implement the Travel Rule for all transactions and all Travel Rule networks become fully interconnected—a scenario that may still take years to realize.

To mitigate these challenges today, our clients can contribute extra data that significantly improves message delivery outcomes.

Wallet Type

One of the most valuable data points for improving delivery rates—or avoiding unnecessary deliveries—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 VASP behind the address, so no message needs to be sent.

When you indicate the wallet type as NON_CUSTODIAL, we can automatically mark the message as confirmed in our system—saving time and reducing noise.

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 our Self-Hosted Wallet Verification Guide.

Beneficiary VASP Name

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:

1. Entities Endpoint

We offer a Find Entities endpoint to help identify VASPs:
👉 Entities API

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"
}
...

2. Blockchain Analytics Tools

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.

Add Your Own Wallets

To improve Travel Rule message delivery for your incoming crypto transactions, ensure your internal wallet list is up to date.

You can manage this list through:

Keeping your wallet data current helps our platform recognize your addresses and ensures smoother communication between VASPs.

Claiming Incoming Transactions Without Travel Rule Data (Coming Soon)

One common issue for VASPs is that, while they have implemented the Travel Rule for outgoing transactions, they often do not receive Travel Rule messages for most of their incoming crypto transactions.

This happens primarily because:

  • Many VASPs have not yet implemented the Travel Rule.
  • There are still interoperability issues between Travel Rule networks.

To help address this, we’ve introduced a "claim transaction" endpoint.

Use Case

You’ve received an incoming crypto payment, but there is no associated Travel Rule data available for it.

In such cases, you can use the Claim Transaction API endpoint and submit a request with details like the following:

{
  "asset": "BTC",
  "blockchainInfo": {
    "transactionHash": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16",
    "origin": "0xb794f5ea0ba39494ce839613fffba74279579268",
    "destination": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F"
  },
  "vaspInfo": {
    "originatorVaspName": "SwiftExchange"
  }
}

👉 Claim Transaction API endpoint

By submitting a claim, you are asserting that:

  • You received a crypto payment (in this case, BTC) from the specified origin address to your destination address.
  • You do not currently have Travel Rule data for this transaction.
  • You confirm that:
    • You are the beneficiary of the transaction (based on the transaction hash).
    • You control the destination wallet.

What Happens After You Submit a Claim?

  1. Initial Check:
    CryptoSwift will search its internal database to check if Travel Rule data already exists for the given transaction hash.

    For example, it may have been undelivered if your wallet wasn’t yet added to your internal wallet list or wasn’t detected via our blockchain analytics tools.

  2. If Travel Rule Data Is Found:

    • It will be forwarded to you as an incoming Travel Rule message.
    • If you’ve configured a webhook, your backend will be notified automatically.
  3. If Travel Rule Data Is Not Found:

    • We’ll use internal blockchain analytics tools to try and identify the originator VASP behind the sending wallet.
    • If identified, we will contact them to:
      • Provide the missing Travel Rule data via our API, or
      • Claim their account (if they’re not yet verified).
  4. Ongoing Monitoring:

    • All claims are stored and monitored.
    • If a new outgoing Travel Rule message later appears that matches the claimed transaction hash, we will automatically forward the message to you.

Next steps