Skip to content

Post-transaction Travel Rule flows under MiCA

Teams often ask whether they may release on-chain transfers before the beneficiary VASP has acknowledged the Travel Rule payload. MiCA's Transfer of Funds Regulation (TFR) allows post-transaction processing, provided the originator VASP sends the Travel Rule message concurrently and the beneficiary VASP follows a documented risk-based procedure. This page summarises the relevant articles and offers guidance on operational safeguards.

Information Circle
When to choose the post-transaction model

Use this pattern as your default when automated acknowledgements from counterparties are rare or when you want to avoid blocking customer withdrawals while still meeting MiCA requirements.

Implementing the post-transaction workflow

1. Collect compliance-ready data

Capture the full Travel Rule payload before you broadcast the crypto transfer. At minimum you need the asset, amount, blockchain network, origin and destination addresses, originator and beneficiary identities, and beneficiary VASP contact details. Supplying wallet type, beneficiary VASP name, and other metadata improves delivery rates—see Improving data quality for recommendations.

2. Send the Travel Rule message alongside the blockchain transfer

Trigger the API request at the same time you submit the on-chain transaction. Include the blockchain hash if it is already available; otherwise patch it later once your payments system returns it.

curl --request POST 'https://api.cryptoswift.eu/transactions' \
  --header 'x-api-key: $API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "asset": "BTC",
    "amount": "0.015",
    "blockchainInfo": {
      "blockchain": "Bitcoin",
      "transactionHash": "f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16",
      "origin": "bc1qoriginaddress",
      "destination": "bc1qbeneficiaryaddress",
      "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 reconciliations, especially if you later patch the hash or other fields.

3. Monitor status updates

Use the stored UUID to watch delivery and compliance statuses. Two complementary options:

  • Subscribe to webhooks for near real-time DELIVERED, CONFIRMED, or DECLINED updates, secured with Webhook signatures.
  • Poll GET /transactions/{id} on a back-off schedule when inbound web traffic is not feasible.

Route notifications to analysts so they can document decisions and, when needed, update the transaction state or provide additional information.

Regulatory obligations for post-transaction flows

Outgoing transactions: send data concurrently, not afterwards

Article 14(4) of Regulation (EU) 2023/1113 states that originator VASPs must transmit beneficiary and originator information "in advance of, or simultaneously or concurrently with, the transfer of crypto-assets." The regulation does not require a two-way handshake to finish before broadcasting the on-chain transaction. The expectation is that:

  • The full Travel Rule payload leaves the originator VASP at the same time the blockchain transfer is submitted.
  • The originator VASP keeps evidence that the payload was dispatched (transaction ID, timestamp, payload hash).
  • Subsequent responses from the beneficiary VASP can arrive later via webhook, and you should route them to compliance teams for review.

In practice, once your system has sent the Travel Rule message concurrently with the blockchain transfer, you may release the funds even if the beneficiary VASP has not yet replied. Holding transactions indefinitely until an acknowledgment arrives is not mandated, though you may choose to delay settlement for high-risk cases.

Incoming transactions: follow risk-based controls

Article 17(1) mandates that beneficiary VASPs maintain "effective risk-based procedures" to decide whether to execute, reject, return, or suspend transfers that lack complete information. Two key points flow from this requirement:

  • If the Travel Rule data is missing or incomplete, revert to your existing AML/CTF risk assessment. You may temporarily freeze funds while you gather more information.
  • Article 17(2)(a) further clarifies that when you become aware the mandated information is missing or incomplete you should, on a risk-sensitive basis and without undue delay, reject the transfer or take another appropriate action.

Therefore, you need documented playbooks for scenarios where Travel Rule data is late, incomplete, or contradictory. CryptoSwift's Claims API and incoming transaction status updates are designed to support these obligations.

Designing a controlled post-transaction flow

Put the regulatory guidance into an operational plan by ensuring that:

  • Outgoing flows capture the Travel Rule payload alongside the blockchain submission so you can prove concurrency.
  • Beneficiary-side systems can freeze payouts when risk scores or missing data trigger alerts, and only release funds after the review finishes.
  • Beneficiary VASPs can update incoming transactions to CONFIRMED or DECLINED, including statusReasoning, so the originator VASP receives clear feedback.
  • Exceptions (for example, high-risk withdrawals or repeated missing data) escalate automatically to manual review before funds are released.

Further reading

Next steps