Pre-transaction Travel Rule workflows

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.

Send the Travel Rule message as soon as the customer confirms the withdrawal details and your wallet-type policy says a Travel Rule message should be created, but omit the blockchain transaction hash. You still include blockchain context (asset, network, origin, destination, and destination type) so the counterparty understands what they are approving. For API payload examples, see Outgoing transactions.

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
• wallet classification evidence from your KYW pre-check, stored in your transaction or case record
• 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.

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. If the transfer will not be executed, update the outgoing message to CANCELLED with a non-empty statusReasoning.
• 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.

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.

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.

The pre-transaction flow has two mutually exclusive completion paths:

• If the transfer proceeds, patch the Travel Rule message with the on-chain transaction hash after settlement. This links the Travel Rule data to the executed blockchain transaction and concludes your integration activity for that transaction.
• If the transfer is blocked or abandoned before settlement, patch the outgoing Travel Rule message to CANCELLED and include a non-empty statusReasoning. This records the compliance decision, keeps the audit trail complete, and automatically reflects the cancellation to the counterparty VASP so they can release temporary internal holds.

• 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.
• Patch blocked pre-transaction withdrawals to CANCELLED with a non-empty statusReasoning instead of leaving them open indefinitely.
• 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.

• Post-transaction workflow
• Wallet Intelligence (KYW)
• Rule Engine
• Outgoing transactions
• Get started

• Outgoing transactions (overview)
• End-to-end Travel Rule lifecycle
• Required Travel Rule data