Skip to content

Pre-transaction Travel Rule workflows

Some tenants prefer to obtain an explicit acknowledgement from the beneficiary VASP before they broadcast the on-chain transfer. This pre-transaction workflow builds on the same Travel Rule transaction primitives that underpin the post-transaction approach, but rearranges the order of events. The steps below describe how to collect beneficiary confirmation up front, how to handle delayed responses, and how to fall back gracefully when the counterparty does not answer automatically.

1. Create the Travel Rule message without the blockchain hash

Send the CREATE request as soon as the customer confirms the withdrawal details, but omit the blockchain transaction hash. You still include blockchain context (asset, network, origin, destination) so the counterparty understands what they are approving.

curl --request POST 'https://api.cryptoswift.eu/transactions' \
  --header 'x-api-key: $API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "asset": "USDC",
    "amount": "250.00",
    "blockchainInfo": {
      "blockchain": "Ethereum",
      "origin": "0xCustomerWallet",
      "destination": "0xBeneficiaryWallet",
      "destinationType": "CUSTODIAL"
    },
    "originator": {
      "type": "NATURAL",
      "name": "Jamie Rivera",
      "address": "Alexanderplatz 25, Berlin",
      "country": "DE",
      "accountNumber": "cust-45781"
    },
    "beneficiary": {
      "type": "NATURAL",
      "name": "Leonie Schulz",
      "accountNumber": "swift-88452"
    },
    "vaspInfo": {
      "beneficiaryVaspName": "SwiftExchange",
      "beneficiaryVaspEmail": "compliance@swiftexchange.eu"
    }
  }'

Store the returned transaction UUID—it anchors subsequent status checks and the later PATCH that adds the hash.

2. Wait for the counterparty decision

Two delivery options help you detect the response:

  • Subscribe to webhooks so you receive DELIVERED and CONFIRMED statuses as soon as the beneficiary VASP processes the message. Sign the endpoint using Webhook signatures.
  • Poll the Transactions API (GET /transactions/{id}) on a back-off schedule if you cannot receive inbound traffic.

A fully confirmed pre-transaction flow waits for a CONFIRMED response before broadcasting funds. Because automatic responses from counterparties remain limited today, design a fallback: after a timeout (for example, 30 minutes) escalate to manual outreach or revert to the post-transaction workflow so funds can still move with documented justification.

Information Circle
Hybrid option

Waiting only for the DELIVERED status is a pragmatic middle ground. It proves the counterparty VASP received the payload and can access it, while you proceed with settlement without blocking on an explicit confirmation.

3. Broadcast the crypto transaction

Once you decide to continue—either after CONFIRMED, after a manual green light, or when the hybrid DELIVERED threshold is met—submit the blockchain transfer as usual within your payments infrastructure.

4. Patch the Travel Rule message with the transaction hash

After the on-chain transaction has a hash, update the Travel Rule record so both VASPs can reconcile the message with the blockchain settlement.

curl --request PATCH "https://api.cryptoswift.eu/transactions/{transactionId}" \
  --header 'x-api-key: $API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "blockchainInfo": {
      "blockchain": "Ethereum",
      "transactionHash": "0x7d...c93"
    }
  }'

Include any additional status metadata if your compliance team resolved open questions during the manual review.

Operational checklist

  • Define SLA thresholds for how long to wait before triggering the fallback or hybrid path.
  • Route webhook notifications to case-management tooling so analysts can see DELIVERED, CONFIRMED, or DECLINED updates in real time.
  • If you bypass the full pre-transaction confirmation, document the rationale in the transaction monitoring record so auditors can trace the decision.
  • Keep both the pre- and post-transaction playbooks available—tenants often apply the pre-transaction pattern only to high-risk withdrawals while defaulting to the post-transaction flow elsewhere.

Pre-transaction coordination is optional but valuable for counterparties with strict settlement rules. Adopt it selectively where it reduces investigation work, and fall back to the concurrent post-transaction design whenever it would otherwise block legitimate customer transfers.

Next steps