Skip to content

Pre-transaction Travel Rule workflows

Build a request-before-broadcast pattern for outgoing Travel Rule transactions using multi-signal decisioning and the Rule Engine.

Some tenants need a decision 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.

CryptoSwift provides multiple signals to support meaningful pre-transaction decisioning. These include Travel Rule message status, Travel Rule Risk Score, counterparty information, transaction amount, wallet context, and other data points available at message creation time. These signals can be combined in the Rule Engine, where compliance teams define the rules and CryptoSwift calculates the outcome for each Travel Rule message.

1. Create the Travel Rule message without the blockchain hash

Send the Travel Rule message 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. For API payload examples, see Outgoing transactions.

2. Evaluate the immediate decision inputs

The synchronous Create Transaction response is the first decision point. Depending on your setup, it can give you:

  • Travel Rule message status
  • Travel Rule Risk Score
  • counterparty routing or delivery context
  • beneficiary VASP information
  • transaction amount and blockchain context
  • a Rule Engine outcome

Use those signals together with your own controls to decide whether to proceed, wait, review, or block.

A fully confirmed pre-transaction flow is still valid when your policy requires a CONFIRMED response before broadcasting funds. It is no longer the only option.

Rule Engine

Use the Rule Engine to combine the available signals into an automated policy. Compliance teams define the logic in the Client Dashboard, and CryptoSwift evaluates the policy for each Travel Rule message as it is created.

3. Example policy patterns

These are examples only. They should be adapted to the regulatory requirements that apply to your jurisdictions, counterparties, and your own AML policies.

  • PROCEED: Travel Rule risk severity is LOW_RISK and the transaction amount is below your threshold, for example EUR 1,000.
  • PROCEED: Travel Rule risk severity is LOW_RISK and the counterparty responds with CONFIRMED, even when the amount is above your standard low-value threshold.
  • BLOCK: Travel Rule risk severity is HIGH_RISK, or the score is above a risk threshold defined by your compliance team.
  • WAIT: The amount is above a threshold such as EUR 1,000 and the counterparty has not responded yet, or the message is still PENDING. After the wait period, if no update arrives and the message remains PENDING, the fallback action can move to REVIEW.

4. Monitor asynchronous updates

Use delivery status updates, webhooks, or API polling as described in Outgoing transactions to detect later counterparty responses.

If your workflow includes waiting logic, define 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.

5. Broadcast the crypto transaction

Once you decide to continue, submit the blockchain transfer as usual within your payments infrastructure. That green light may come from a CONFIRMED response, a Rule Engine outcome, a manual review, or another documented policy threshold.

6. 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. Use the PATCH example in Outgoing transactions.

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

Operational checklist

  • Define which signals can affect the decision, such as status, risk severity, amount, beneficiary VASP, or wallet context.
  • Define SLA thresholds for how long to wait before triggering the fallback path.
  • Route webhook notifications to case-management tooling so analysts can see DELIVERED, CONFIRMED, or DECLINED updates in real time.
  • Make sure compliance teams own the Rule Engine policy logic and update it when regulatory or AML requirements change.
  • Document why transactions proceed without a full counterparty confirmation when your policy allows it, so auditors can trace the decision.
  • Keep both the pre- and post-transaction playbooks available: VASPs 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 or for policies that need multiple decision signals before funds move. 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

See also