Travel Rule

The Travel Rule feature collects counterparty details on larger deposits and withdrawals, so your exchange can meet Travel Rule requirements.

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 page explains what the feature does, what your users experience, and how you manage it in Operator Controls.

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.

---

Travel Rule settings

The Travel Rule has two settings:

Setting	What it does
On / Off	Enables or disables the whole feature. When it's off, nothing changes for users and no information is collected.
Threshold amount	The value, in your exchange's native currency, at or above which a transaction must collect Travel Rule information.

These settings aren't on a page in Operator Controls. To turn the Travel Rule on or change the threshold, contact the HollaEx team at support@hollaex.com.

How the threshold check works:

• The threshold is measured in your exchange's native currency (for example, USDT). If a user transacts in another asset, the transaction's value is converted to the native currency using live pricing, then compared with your threshold.
• The check is at or above the threshold. A transaction exactly equal to the threshold qualifies; anything below it is unaffected.
• If a transaction's value can't be converted to the native currency (for example, there's no price for the asset or pricing is temporarily unavailable), the transaction is treated as qualifying: it must carry Travel Rule information, and a deposit is held until it does. The compliance record then has no native-currency value.
• The check is skipped, and nothing is held, when the threshold isn't set (zero or empty), when your exchange has no native currency set, or when the transaction arrives without an amount.

---

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:

1. 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.
2. What is the purpose of the transfer?
   1. 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.

On-Hold Flow Chart

flowchart TD
    A([Deposit arrives]) --> B{From a blacklisted<br/>address?}
    B -- Yes --> BL[Hold: Blacklist<br/>no Travel Rule record created]
    B -- No --> C{At/above the<br/>Travel Rule threshold?}

    C -- No --> H
    C -- Yes --> TR[Hold: Travel Rule<br/>ask user for source of funds]

    subgraph SCREEN [Other controls may also add holds]
        K[Hold: KYT / screening<br/>flagged by AMLBot / Scorechain]
        AD[Hold: auto-deposit off<br/>or screening unavailable]
    end

    C --> SCREEN
    TR --> H{Any active<br/>hold reasons?}
    K --> H
    AD --> H
    BL --> H

    H -- "Yes — still held" --> W[Deposit stays pending]
    W -.->|"User submits Travel Rule info<br/>(clears Travel Rule only)"| H
    W -.->|"Plugin returns clean<br/>(clears KYT)"| H
    W -.->|"Operator clears blacklist /<br/>other holds"| H

    H -- "No holds left" --> CR([Deposit credited])

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:

Hold reason	Where it comes from	Typical meaning
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 Transaction 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 Responsibility

The ability to clear a hold is split by responsibility:

Hold reason	Who can clear it
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 transaction screens in Operator Controls.

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

In Operator Controls, open a deposit or withdrawal under Operations → Activity → Deposits or Withdrawals, or from a user's Deposits and Withdrawals tabs under Operations → People → Users. Click Travel Rule to see the compliance record collected for that transaction: the service provider type, the names provided, whether it's the user's own address, and the purpose of the transfer.

If no record was collected for a transaction, the window says so, and you can add the information on the user's behalf with Save travel rule info. Held transactions show their hold reasons under Hold & compliance, where operators release or reject them.

Viewing records and adding missing information are separate operator permissions, set under Exchange → Access Control.

Each qualifying transaction is its own record. Details aren't merged or reused 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 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.