Skip to content

Post-transaction Travel Rule flows

Understand how post-transaction processing works for outgoing crypto transfers.

Teams often ask whether they may release on-chain transfers before the beneficiary VASP has acknowledged the Travel Rule payload. For the EU regulation (MiCA, TFR), post-transaction processing is allowed provided the originator VASP sends the Travel Rule message concurrently and the beneficiary VASP follows a documented risk-based procedure. This same logic is broadly consistent across major Travel Rule regimes globally, even if the terminology or thresholds differ. Disclaimer: check your regulation and the requirements that apply to your jurisdiction and counterparties.

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 Travel Rule requirements.

Implementation summary

Capture the full Travel Rule payload before you broadcast the crypto transfer, send the message concurrently with settlement, and follow up with delivery statuses. The API request examples and webhook/polling details live in Outgoing transactions.

Regulatory obligations for post-transaction flows

Outgoing transactions: send data concurrently, not afterwards

For the EU regulation (MiCA, TFR), 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

For the EU regulation (MiCA, TFR), 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

See also