Travel Rule
The Travel Rule feature helps to keep transactions on your exchange compliant with required regulations, and thus, assist with obtaining licensing.
What is the 'Travel Rule'?
The Travel Rule is a compliance feature that collects information about who is sending and receiving funds on larger transactions. It exists so your exchange can meet the regulatory Travel Rule requirement (originally FATF Recommendation 16), which asks Virtual Asset Service Providers (VASPs) to gather and keep basic counterparty details on transfers above a set value.
This guide explains what the feature does, what your users will experience, and how you, as an operator, manage it. It is intentionally non-technical.
Travel Rule Feature Summary
When the Travel Rule is switched on, you set a 'threshold amount'. Any deposit or withdrawal with a value at or above that amount must carry extra information about the other party (the 'counterparty') and the reason for the transfer.
Withdrawals are paused until the user fills in these details, and deposits are placed on hold until the source of funds is provided.
Everything collected is stored as a compliance record you can look up later, one record per transaction.
How to Set Up the Travel Rule Feature
Navigate to the Travel Rule in Operator Controls → General → Travel Rule.
There are only two settings:
On / Off switch
Enables or disables the whole feature. When off, nothing changes for users, and no information is collected.
Threshold amount
The value, expressed in your exchange's native currency, at or above which a transaction must collect Travel Rule information.
A few things worth knowing:
The threshold is always measured in your exchange's native currency (for example, USDT). If a user transacts in another asset, the system converts that transaction's value into the native currency using live pricing, then compares it against your threshold.
The check is 'at or above' the threshold. A transaction exactly equal to the threshold qualifies; anything below it is unaffected.
If the system cannot determine a transaction's value in native currency (for example, pricing is temporarily unavailable), it does not block or hold that transaction — normal operation continues. The Travel Rule never gets in the way when the value is unknown.
Travel Rule User Flow
Withdrawals
When a user requests a qualifying withdrawal, they are shown a short form before the withdrawal can proceed. They cannot complete the withdrawal until it is filled in.
The form asks, in order:
Who is the service provider on the other side?
An exchange / VASP - Another exchange or regulated service. The user then enters:
The name of that exchange/ provider
The account holder's name.
A self-custody wallet - A private wallet. The user ticks "The receiver is myself" if it's their own wallet, or else, enters the counterparty's name.
What is the purpose of the transfer?
A fixed list is offered: Personal transfer, Investment, Purchase of goods/services, Salary/income, Gift, Trading, or Other (which lets the user type their own reason).
Once submitted, the withdrawal continues as normal, and a compliance record is saved.
Deposits
Deposits work the other way around because the funds arrive on their own. When a qualifying deposit comes in, it is placed on hold instead of being credited immediately.
The user is asked to provide the same kind of information as above, using the same form (worded from the sender's side).
Once the user provides the source-of-funds details, the deposit's Travel Rule hold is cleared and, assuming nothing else is holding it, the deposit is credited.
The On-Hold System
The Travel Rule does not work in isolation. It plugs into a single, shared hold system that decides whether an incoming deposit is credited or kept pending.
This is the most important concept for operators to understand because it is what ties the Travel Rule together with your other compliance controls.
The diagram below shows the journey of an incoming deposit through the hold system. The key takeaway is the loop near the bottom: the deposit keeps waiting until every active hold from any control has been cleared.
Potential Hold Reason
A deposit can be held for more than one reason at the same time. The Travel Rule is just one reason among several. Common hold reasons include:
Travel Rule
The exchange (this feature)
The deposit is at/above your threshold and needs source-of-funds details.
Blacklist
The exchange
The source address is on your blacklist.
KYT / screening
A connected screening plugin (e.g. AMLBot, Scorechain)
The transaction was flagged by an automated risk check.
Screening unavailable / auto-deposit off
The platform
Screening could not run, or you have manual deposit approval switched on.
Each reason is tracked independently on the deposit. One can be cleared without disturbing the others.
When a Hold is Credited
A held deposit is credited only when there are no active hold reasons left.
That means clearing the Travel Rule hold on its own is not enough if a screening hold is also active. The deposit remains pending until that one is resolved too.
This is deliberate: it guarantees that no single control can be bypassed by satisfying a different one. A deposit has to pass all of your active checks before the funds become spendable.
Blacklisted addresses
A blacklist match is treated as a hard stop and takes priority. When a deposit arrives from a blacklisted address:
The deposit is held on the blacklist reason.
No Travel Rule record is created.
There is no point asking the user for counterparty details on funds you are rejecting on other grounds, so the user is never prompted for further information, and you are not left with a half-collected record for a transaction you intend to reject.
KYT, AML, and Transation Screening Plugins
If you run a Know-Your-Transaction (KYT) screening plugin such as AMLBot or Scorechain, it participates in the very same hold system:
When a screening plugin flags a deposit, it adds its own KYT hold reason.
That hold coexists with any Travel Rule hold on the same deposit — both must be cleared before the deposit is credited.
When a screening plugin returns a clean result, it clears the holds it is responsible for, allowing automated processing to continue.
Because every control writes to one shared hold list, a deposit can be simultaneously waiting on the user (Travel Rule) and on your screening provider (KYT) — and it will sit pending until both are satisfied. You don't have to coordinate these controls manually; they layer on top of one another automatically.
Clearing Responsibilty
The ability to clear a hold is split by responsibility:
Travel Rule
The user clears it by submitting the requested source-of-funds information. (Operators can also act on it.)
KYT / screening
Cleared automatically by the screening plugin when it returns a clean result, or by the operator.
Blacklist and other holds
The operator, from the admin transaction screens.
The important guardrail: when a user submits their Travel Rule details, that action clears only the Travel Rule reason. It can never clear a blacklist, screening, or other operator-managed hold. Users can resolve the one thing they are responsible for (their own counterparty details) while every genuine risk decision stays firmly with the operator and your screening tools.
How This Assists the Operator
One place, one rule
Travel Rule, blacklist, and KYT screening all feed the same hold system, and a deposit is only released when every check passes. You don't maintain separate, competing approval flows as they stack automatically.
No accidental release
Because a deposit needs all active holds cleared, satisfying one control can never unlock funds that another control is still flagging.
Less manual work
Users resolve their own Travel Rule prompts and screening plugins clear their own flags automatically, so routine cases move forward without you touching them. You step in only for the holds that genuinely require an operator decision.
A clean audit trail
Every qualifying transaction leaves a compliance record you can pull up per transaction, which makes responding to regulators or information requests straightforward.
Sensible prioritisation
Hard rejections (blacklist) short-circuit the rest, so you're never collecting or reviewing counterparty details for funds you were always going to reject.
How to Review Records as the Operator
When the Travel Rule feature is active, a View travel rule details link appears on every deposit and withdrawal row in the admin transaction screens, as well as under an individual user's profile.
Clicking it fetches and shows the compliance record collected for that transaction: counterparty type, the names provided, and the purpose of the transfer.
If a particular transaction never required Travel Rule information (for example, if it was below the threshold), the panel simply reports that no Travel Rule record was collected for it.
Each qualifying transaction is its own record — there is no merging or reuse of details across transactions, even when the same wallet address is involved. The user is asked every time, so every record reflects the information as it was at the time of that specific transfer.
What gets stored
For each qualifying transaction, the record keeps:
Whether it was a deposit or withdrawal, and the transaction itself.
The transaction value, both in the original asset and in your native currency.
The counterparty type (exchange/VASP or self-custody).
The counterparty name and, for exchanges, the service-provider (VASP) name.
Whether the user declared the wallet as their own.
The purpose of the transfer.
These records are retained so you can demonstrate compliance and respond to information requests.
Last updated