Incoming transfers without Travel Rule data

When an on-chain deposit arrives without accessible Travel Rule data, you still need to meet record-keeping obligations and make a risk-based release decision. The preferred path is to backfill the missing data and keep the record updated as more details arrive. Claims are available as an extra compliance layer when you need a formal request to the originator VASP, but they can be slow because they often require manual responses.

Backfilling creates a compliant record even if the originator VASP cannot push a message. Start with the data you already have, then enrich it.

Ask the receiving customer for the originator name and VASP, or any available details, before releasing funds. An example implementation could look like this:

1. Ask the beneficiary for the originator name and the originator VASP name.
2. Use CryptoSwift's Entities API endpoint to build an autocomplete for the exchange name, with a fallback to plain text.
3. Collect the user-provided data and create an INCOMING Travel Rule message with the CryptoSwift API.

In short, as a VASP you are creating an incoming Travel Rule message for yourself using the backfilled information provided by your user (the beneficiary).

curl --request POST 'https://api-dev.cryptoswift.eu/transactions' \
  --header 'x-api-key: $API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "direction": "INCOMING",
    "asset": "ETH",
    "amount": "0.45",
    "blockchainInfo": {
      "blockchain": "Ethereum",
      "transactionHash": "0x1cf...3aa",
      "origin": "0xOriginator",
      "destination": "0xCustodyVault"
    },
    "vaspInfo": {
      "originatorVaspName": "VASP disclosed by customer"
    }
    "beneficiary": {
      "type": "NATURAL",
      "name": "Local Customer",
      "accountNumber": "wallet-0912"
    },
    "originator": {
      "type": "NATURAL",
      "name": "Name disclosed by customer"
    }
  }'

You can also store partial data without the beneficiary section or originatorVaspName if needed.

• Update the record later with PATCH /transactions/{id} when more data becomes available.

Use your AML policy and risk thresholds to decide when to release funds for the incoming transaction:

• Release funds immediately after on-chain confirmations for low-risk transactions.
• Hold funds until backfill is complete for higher-risk transactions or when required by policy.

Document the condition matrix, including amount thresholds and origin risk scores, in your transaction monitoring system.

If you need a formal request to the originator VASP, file a Claim. This is best suited for investigations or cases that are not time sensitive because most Claims require manual VASP responses.

When creating a Claim, you are stating that you have an incoming on-chain crypto transaction, you do not have Travel Rule data available for it, and you want CryptoSwift to find the originating VASP, request the missing Travel Rule data, and forward it to you.

curl --request POST 'https://api-dev.cryptoswift.eu/claims' \
  --header 'x-api-key: $API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "asset": "BTC",
    "blockchainInfo": {
      "blockchain": "Bitcoin",
      "transactionHash": "f4184fc5964...",
      "origin": "bc1qh...",
      "destination": "bc1qy..."
    },
    "vaspInfo": {
      "originatorVaspName": "InternationalExchange"
    }
  }'

1. After you create a Claim, we check our internal database for records that match the provided data (transaction hash, origin wallet, VASP info). If we find a match, we contact the originator VASP automatically and request the missing information.
2. If we do not find any records, we use blockchain analytics tools with the provided origin wallet address to identify the originator VASP and reach out to them automatically.
3. The originator VASP can then either forward the missing data to us so we can make it available to you via the API, or create an account and forward the data to you automatically.
4. For a successful Claim, the Travel Rule information appears as a standard INCOMING Travel Rule message. The Claim status is updated to CONFIRMED automatically, and the payload includes a reference to the Travel Rule transaction ID.

Please be aware that keeping your customer's incoming transactions on hold while waiting for Claims data might not be suitable, because response speed depends on the originating VASP and can take multiple days. Claims are best suited for investigations or high value, high risk transactions. In other cases, backfilling is often the better option.

For endpoint details, see the Claims API. For a broader view of missing data handling, see Missing or incomplete Travel Rule data.

• Incoming transactions
• Improving data quality
• Webhooks