Travel Rule

Travel Rule is a norm from FATF Recommendation 16 that requires regulated crypto intermediaries to pass personal data about the originator and beneficiary along with the transfer itself. The goal is to close the “blind spot” where money moved between VASPs without any information about the parties — unlike a classic banking SWIFT transfer.

Who it applies to

Travel Rule covers VASPs (Virtual Asset Service Providers): crypto exchanges, custodial wallets, OTC desks, fiat gateways. Non-custodial wallets do not technically fall under the definition, but this is a grey zone — several jurisdictions are trying to extend the rules to “unhosted wallets” as well.

Trigger threshold

FATF recommends a threshold of USD 1,000 / EUR 1,000, above which the rule is mandatory. National regulators apply the benchmark differently:

• EU — no threshold: from the entry into force of the relevant MiCA / TFR section, the Travel Rule applies to any transfer between CASPs starting from the first euro.
• US (FinCEN) — threshold of USD 3,000, with discussion of lowering it to USD 250, but the rule has not been adopted.
• Switzerland, Singapore, the UK — at the level of 1,000 USD/CHF/GBP.
• UAE, Hong Kong, Japan — implemented with their own thresholds and nuances around non-custodial transfers.

What data is shared

The standard set follows the IVMS-101 schema (an international data standard):

• Originator: name, wallet address, ID document or residential address, sometimes date and place of birth.
• Beneficiary: name, wallet address, sometimes a verified account at the receiving VASP.

This data is not part of the on-chain transaction itself — there is simply no room for it there — but is sent through a separate channel between VASPs.

How it is implemented technically

Several competing solutions:

• TRP (Travel Rule Protocol) — a standard from a consortium of large exchanges and custodians.
• Sygna Bridge, Notabene, Sumsub Travel Rule, VerifyVASP, TRISA — commercial and open-source providers.
• OpenVASP — a separate open protocol that lost momentum after the market consolidated around IVMS-101.

All of them use IVMS-101 at their core as the message format and exchange it through secured channels between VASPs.

Implications for the TON ecosystem

• Exchanges with TON pairs. When transferring TON or USDT-jetton to another exchange above the threshold, both sides are obliged to exchange Travel Rule messages. Without this, the transfer is rejected or frozen.
• Custody services. Custodial services inside TON projects, if they want to comply with EU or other strict jurisdictions, must integrate one of the Travel Rule providers.
• Transfers to or from non-custodial. This is the most contested area. In the EU the VASP must record that the counterparty is a non-custodial wallet, and for transfers above EUR 1,000 perform additional checks (sumsub-style ownership verification).
• For the user. Sending crypto between exchanges now often requires entering the receiver’s name and confirming that it is your account. This is not the exchange being capricious — it is Travel Rule.

Practical takeaways

• Expect to enter the holder name of the receiving account when withdrawing TON from one exchange to another.
• Sending to your own non-custodial wallet may require proof of ownership: signing a message via Tonkeeper or a similar procedure.
• This is not legal advice; specific Travel Rule rules depend on jurisdiction and continue to change.