Travel Rule and TON: how tracking works

By 2026, the FATF Travel Rule is no longer a distant abstraction. It is a working procedure that processes billions of dollars in crypto every day, and every TON user who has ever sent Toncoin or USDT through a centralised exchange (Binance, OKX, Bybit, Bitget, KuCoin) brushes against its consequences. Sometimes it shows up as a 30-minute withdrawal delay. Sometimes as a source-of-funds questionnaire. Occasionally as a temporary deposit hold.

This article unpacks how the Travel Rule operates on the exchange side, how it interacts with TON’s transparent on-chain data, and what an exchange compliance desk can actually do with your transfers. No alarmism: the vast majority of transfers go through automatically. But understanding the mechanics is worth your time — especially if you withdraw large amounts or use TON across multiple jurisdictions.

What the FATF Travel Rule is

The Travel Rule is Recommendation 16 of the Financial Action Task Force (FATF), an intergovernmental anti-money-laundering body. The rule was originally written in 1996 for bank wire transfers: the originating bank must pass a defined data set about the customer (name, address, account number) to the beneficiary bank, so the transaction “travels” with identifying context.

In 2019, FATF extended Recommendation 16 to VASPs — Virtual Asset Service Providers. This includes centralised exchanges, custodial wallets, OTC desks, and arguably some DeFi front-ends (the “control” definition remains contested). Since 2021, major jurisdictions — the EU, the UK, Singapore, Japan, Switzerland — have phased the rule into national law.

Key parameters as of 2026:

• EU threshold: €1000 (Regulation 2023/1113, the Transfer of Funds Regulation accompanying MiCA). Below the threshold, a reduced data set; above, the full set.
• US threshold: $3000 (FinCEN, Bank Secrecy Act). Active since 1996 for wires, extended to crypto in 2020-2022.
• United Kingdom: £1000.
• Switzerland, Singapore, Japan: low or zero threshold — Travel Rule applies to all inter-VASP transfers.

What data is shared: IVMS-101 and TRP

The transmission format is standardised — it is IVMS-101 (InterVASP Messaging Standard). What it carries:

• Originator full name.
• Physical address (or legal entity name plus registered address).
• Wallet address / blockchain identifier.
• Unique identifier (passport, tax ID, national ID).
• Beneficiary full name.
• Beneficiary wallet address.
• Sometimes date and place of birth.

The transport layer between VASPs is TRP (Travel Rule Protocol), Sumsub Travel Rule, Notabene, Veriscope, or the TRUST Network. These are technical gateways: Exchange A packages the IVMS-101 payload into an encrypted message and sends it to Exchange B before or just after the on-chain transaction. If Exchange B is a member of the same network, the message clears automatically. If not, the deposit may sit in pending status until manual reconciliation.

How this maps to TON specifically

TON is a public, transparent blockchain. Any address and any transaction is visible on Tonscan, Tonviewer, or the Toncoin Explorer. Two consequences for the Travel Rule:

1. Off-chain data (IVMS-101) layers on top of on-chain data. The exchange knows that transaction EQA...abc → EQB...xyz happened in block 12345678 — that is public to everyone. The Travel Rule adds: “the originator is John Smith, passport XXX, resident of Berlin”.
2. On-chain clustering works. Chainalysis, Elliptic, TRM Labs, Crystal Blockchain — all of these providers build address graphs for TON and tag them with known attributes: “Binance hot wallet address”, “address belonging to a cluster linked to drainer campaign X”, “address that received funds from an OFAC SDN entity”.

When you withdraw Toncoin or USDT from Binance to Tonkeeper and then send onward to another user, Binance sees the first hop (its hot wallet to your self-custodial address). Further hops are visible to Binance only if the funds return to Binance or to another CEX that shares a Travel Rule channel with it.

What actually happens to your transfers

A realistic scenario — USDT-on-TON deposit from a third-party wallet:

1. You send 5000 USDT from Tonkeeper to a Bybit deposit address.
2. Bybit observes the transaction in the TON mempool and credits it after 1-2 confirmations.
3. The compliance scanner kicks in: the source address is screened by a chainalysis provider. Clean — instant credit.
4. If flagged (links to mixers, sanctioned entities, drainer campaigns), the deposit goes on hold. You receive a source-of-funds request: where did the USDT come from, supporting documents, screenshots, statements.
5. If the answer is satisfactory — funds released. If not — the deposit may be returned to the sender (often minus a fee) or escalated.

For withdrawals to an external wallet, the procedure is mirrored: the exchange records the destination address. If the address is already flagged, the withdrawal is blocked at confirmation. If a sanctions link surfaces later, the exchange may retroactively request clarifications on older withdrawals.

Self-custodial transfers and the “unhosted wallet” debate

FATF issued guidance in 2021 labelling transfers to and from “unhosted wallets” (i.e. non-custodial) as higher risk. The EU’s AMLD-5 and now MiCA formalised this: for transfers above €1000 to or from an unhosted wallet, the exchange must verify address ownership — typically by asking the user to sign a message with the private key, or to make a small test transaction (a Satoshi test).

In practice in 2026:

• Most major exchanges require address whitelisting for withdrawals above €1000, with a 24-72 hour delay.
• Some require ownership proofs (challenge-response) for larger withdrawals.
• Deposits from unhosted wallets pass through the same chainalysis filter, but the threshold for triggering a source-of-funds request is usually higher — €10000-15000.

Comparison across jurisdictions

What this means for you in practice

Do:

1. Use a stable set of TON addresses for CEX operations — this simplifies your own audit trail and does not look like address-hopping.
2. Keep records of crypto purchases (CSV exports, screenshots, P2P contracts). You will need them if a source-of-funds request lands.
3. If withdrawing a large amount (above €1000) to a new address, whitelist it ahead of time — do not try to do everything in one session.
4. Before deposits, check the sender address reputation on Tonviewer or Tonscan. If it is publicly tagged as scam, the deposit will almost certainly be flagged.

Don’t:

1. Do not try to “bypass” the Travel Rule by splitting one transfer into ten transactions of €100. This is structuring — a separate offence in most jurisdictions and explicitly criminalised in many.
2. Do not use mixers (Tornado-style) for funds you plan to land on a CEX. This is an automatic flag.
3. Do not accept large payments from unknown addresses without understanding the source — you will be asked to justify it on the CEX later.

Conclusion and what to read next

The Travel Rule is not “surveillance of every TON user”. It is a mechanism that activates when you use a regulated provider (a CEX, a custodial wallet, a licensed OTC desk). Self-custodial TON transfers are formally outside its scope, but the moment funds touch the regulated perimeter, off-chain data starts linking to on-chain history.

Practical takeaway: keep records of your own operations, use licensed exchanges in your jurisdiction, and do not try to game compliance — it creates more risk than the rules themselves.

Next read — how the Travel Rule is folded into MiCA for EU users, and how OFAC sanctions add a second compliance layer on top of the Travel Rule.