TheMonsoon Ledger

Under the Hood ·

A crypto transfer carries no names, so the travel rule sends them in a separate message

The exchanges send the names in a message between themselves, off the chain, before or at the same time as the on-chain transfer, and the receiving exchange matches the two. The design works only when both ends are regulated service providers that can find and trust each other. Transfers to self-hosted wallets fall outside the message, and India's rules do not yet say how to handle them.

By

Subject
The travel rule for virtual asset transfers
Problem
Exchanges in India, Singapore and Hong Kong must pass the sender's and receiver's identity along with a crypto transfer. How do they do it when a blockchain records only addresses and amounts?

A crypto exchange meets the travel rule by sending the sender’s and receiver’s details to the receiving exchange in a separate, encrypted message, off the blockchain, before or at the same time as it sends the crypto. The blockchain transfer carries only two addresses and an amount. The receiving exchange matches the message to the deposit, checks the names, and holds or returns a deposit that arrives without one. The design depends on both ends being regulated service providers that can find each other. When one end is a wallet that its owner controls, no firm receives the message. Hong Kong and Singapore have rules for that case. India does not yet.

The problem

The travel rule is the Financial Action Task Force (FATF) requirement that a firm sending a payment passes on who is sending it and who is receiving it. It began with bank wire transfers under Recommendation 16, which FATF revised in June 2025 with changes taking effect by the end of 2030 (FATF, 18 June 2025). FATF applies it to virtual asset service providers: exchanges, brokers and custodians that move crypto for customers.

India’s Financial Intelligence Unit (FIU-IND) consolidated its rules for these providers in guidelines of 8 January 2026. On 9 September 2026 it issued non-compliance notices to 15 offshore platforms serving Indian users without registering, and sought takedown of their apps and websites (Wire). Every registered Indian exchange now has to send identity data with its transfers to other providers.

Across FATF’s network, 83 per cent of surveyed jurisdictions had passed travel rule legislation by July 2026, up from 73 per cent in 2025, and a further 11 reported that implementation was under way (FATF, 16 July 2026). The question for an Indian exchange, and for the FIU-IND officers who inspect it, is how the data travels when the ledger that moves the asset has no field for a name. The rules for each market are compared in the State of Play note on the travel rule. This piece follows the mechanism.

How it works

Some terms first. A wallet holds the keys that control crypto at an address, a string of characters that identifies where crypto is sent on a blockchain. A hosted wallet is one a service provider controls for its customer. A self-hosted wallet (regulators also say unhosted wallet) is one whose keys the owner holds. The originator sends the transfer and the beneficiary receives it. The originating and beneficiary providers are the firms acting for them.

Follow a customer of Sample Exchange India sending ether to their own account at Sample Exchange Singapore, worth more than S$1,500. The exchanges use the Travel Rule Protocol (TRP), an open, royalty-free specification maintained by the OpenVASP Association and first drafted by Standard Chartered, ING and BitGo (TRP repository).

One transfer, two channels

The names travel in an encrypted message between the two exchanges. The blockchain carries only addresses and an amount. Numbers match the steps below.

  • Sample Exchange IndiaSends
  • Sample Exchange SingaporeReceives
  • EthereumPublic ledger

  1. 1Travel addressA link to the receiving exchange's system, passed on by the customer

  2. 2Checks the receiver

  3. Both sides prove who they areCertificates over mutual TLS

  4. 3Transfer inquiryAsset, amount, and identity data in IVMS101: name, PAN, ID number, address, date of birth

  5. 4Screens the sender, checks its customer

  6. Approval with a deposit addressOr a rejection, before any crypto moves

  7. 5Ether transferFrom address, to address, amount. No names

  8. Transaction identifier

  9. 6Deposit arrives

  10. Matches it to the inquiry, credits the customer

  • Encrypted message between the firms, off chain
  • Transaction on the blockchain
Source: TRP specification; FIU-IND guidelines, para 5.3The Monsoon Ledger

  1. The receiver asks for a travel address. The customer opens their Singapore account and asks to receive ether. In TRP, Sample Exchange Singapore issues a “travel address” in place of a blockchain address: an encoded web link to its own system (TRP specification, Travel Address). The customer pastes it into the withdrawal screen in India, with the beneficiary’s name.

  2. The sending exchange checks the receiving exchange. Before sending any data, Sample Exchange India carries out due diligence and sanctions screening on the counterparty, to avoid dealing with illicit actors or sanctioned parties (FIU-IND guidelines, January 2026, para 5.3.1). Hong Kong’s guideline describes the same step: decide whether the other end is a provider or a self-hosted wallet, identify the provider, for example from lists of licensed firms, and judge whether it can protect the data it receives (SFC AML Guideline, paras 12.13.5 and 12.13.8). The two exchanges authenticate each other with digital certificates over mutual TLS, an encrypted connection in which both sides prove who they are (TRP specification, Client Authentication).

  3. The message goes first. Sample Exchange India sends a transfer inquiry to the link in the travel address. It contains the asset, the amount and the identity data in IVMS101, a common data format for originator and beneficiary details maintained by the interVASP Standards Working Group (IVMS101.2023). FIU-IND requires the originator’s Permanent Account Number (PAN), identity document number, verified name, wallet address, physical address and date of birth, plus the beneficiary’s name and wallet address (para 5.3.5). The data must go before or with the transfer. Sending it afterwards is not allowed (para 5.3.4). No crypto has moved yet.

  4. The receiving exchange decides. Sample Exchange Singapore screens the originator’s details against sanctions lists (TRP specification, Overview) and checks that the beneficiary’s name and account match its own verified customer. FIU-IND sets this duty for an Indian beneficiary exchange (para 5.3.6(e)), and the SFC for a Hong Kong one (SFC AML Guideline, para 12.11.21). It then replies with either an approval carrying the deposit address or a rejection (TRP specification, Transfer Inquiry Resolution).

  5. The crypto moves on chain. Sample Exchange India checks the deposit address with on-chain analytics and broadcasts the transfer. The Ethereum ledger records the sending address, the receiving address and the amount. No name, PAN or date of birth appears on the chain. Once the transfer is confirmed, the sending exchange posts the transaction identifier to the receiving exchange (Transfer Confirmation).

  6. The receiving exchange matches and credits. Sample Exchange Singapore matches the deposit to the approved inquiry and credits the customer. If a deposit arrives without the required data, the receiving firm must ask the sender for it. Hong Kong expects it to consider holding the crypto back from the recipient or returning it (SFC AML Guideline, paras 12.11.22 and 12.11.23 and footnote 157). Singapore tells firms to consider rejecting transfers from overseas providers that fail to send originator details (Guidelines to MAS Notice PSN02, para 13-9-1).

TRP lets a sending firm skip the inquiry, take an ordinary blockchain address and send the crypto before the beneficiary approves, provided the identity data has already gone. The specification notes that this gives up the chance to reject a transfer before any crypto moves (TRP specification, Overview).

When the receiver holds their own wallet

Change one fact: the customer withdraws to a self-hosted wallet on their phone. Step 2 finds no provider at the other end, so steps 3, 4 and 6 have no one to receive them. The rules then diverge by market.

The same transfer to a self-hosted wallet

With no provider at the other end, the travel rule message has nowhere to go, but the crypto still moves. Hong Kong and Singapore set extra checks for this case. India's rules do not yet cover it.

  • Sample Exchange IndiaSends
  • Customer's own walletSelf-hosted
  • EthereumPublic ledger

  1. 2Finds no provider at the other end

  2. 3No firm to receive the identity data

  3. 5Ether transferFrom address, to address, amount

  4. Ether arrives

  • Encrypted message between the firms, off chain
  • Transaction on the blockchain
Source: SFC AML Guideline, para 12.14; Guidelines to MAS Notice PSN02, para 13-7The Monsoon Ledger
  • In Hong Kong, the exchange must collect the originator’s and recipient’s details from its own customer, assess the risk, accept transfers only to or from wallets it has assessed as reliable, and set transaction limits where appropriate (SFC AML Guideline, paras 12.14.2 and 12.14.3). It can confirm that the customer controls the wallet with a micropayment test, in which the customer sends a small amount the exchange specifies, or a message-signing test, in which the customer signs a message the exchange specifies (para 12.10.6, footnote 141).
  • In Singapore, the travel rule paragraph does not apply, but the exchange should treat the transfer as higher risk. Enhanced measures can include asking the customer to prove control of the wallet by sending a specified amount, verifying third parties, and enhanced monitoring (Guidelines to MAS Notice PSN02, para 13-7).
  • In India, the travel rule section covers transfers between registered providers and does not address self-hosted wallets (Wire).

Why it is built this way

The duty sits with firms because regulators supervise firms. The supervisors in all three markets license exchanges, not blockchains, and the FATF standard is written for virtual asset service providers (FATF, 16 July 2026). A rule a regulator can enforce has to bind a firm it licenses, so it binds the exchange at the point where a customer’s crypto leaves its books. Once the duty rests with the two exchanges, the data travels between them and the chain carries only the asset. The sending exchange carries most of the weight. In India it screens the counterparty before it transmits anything (FIU-IND guidelines, para 5.3.1). In Hong Kong, if it cannot be sure the data will reach the counterparty securely, it should not send the crypto (SFC AML Guideline, para 12.11.12).

The data stays off the chain because the chain is public. Anything written to a public blockchain can be read by anyone, and kept there for good. Putting a PAN and a home address in a transfer would publish them. Both FIU-IND and the SFC define “securely” as protecting the data’s integrity and keeping it from unauthorised access (FIU-IND guidelines, para 5.3.3(a); SFC AML Guideline, para 12.11.12). Hong Kong says outright that the data need not be attached to the transfer itself (para 12.11.11).

The protocols leave the blockchain alone. The Travel Rule Information Sharing Architecture (TRISA), another open protocol, states its goal as compliance “without modifying core blockchain protocols” and without adding transaction costs (TRISA documentation). Exchanges keep using public chains as they are. The cost is two systems that must be kept in step: a message network and a ledger, joined only by the transaction identifier in step 5.

Regulators set the outcome and leave the technology open. Singapore allows “any technology or software solution” that lets both firms comply (Guidelines to MAS Notice PSN02, para 13-2). Hong Kong says the same, and keeps the firm responsible for compliance whichever solution it buys (SFC AML Guideline, paras 12.12.1 and 12.12.2). India requires a technological solution and allows self-declaration only in exceptional cases where one is not feasible (FIU-IND guidelines, para 5.3.3). The result is several competing protocols and commercial networks. Hong Kong asks firms to weigh whether their solution works with the ones their counterparties use (SFC AML Guideline, para 12.12.3(a)).

A common format still leaves gaps. IVMS101 defines the fields and nothing else. It leaves out how firms find each other, how data is secured and which network protocol carries it (IVMS101.2023, Out of scope). It requires data in Latin script and sets transliteration standards, including ISO 15919 for Devanagari and ISO 7098 for Chinese characters (section 7). Its record for a person holds one national identification number (IVMS101.2023, NaturalPerson), while FIU-IND asks for both a PAN and an identity document number. No document says how Indian exchanges carry the second one. This is a reading of the two texts.

In our markets

India applies the travel rule to every transfer between registered providers, with no threshold stated, and requires the full data set in step 3 (State of Play). The rule reaches offshore providers serving Indian users, because FIU-IND treats registration as tied to the activity, not to where a firm is based (Wire). That makes counterparty checks in step 2 the hard part: an unregistered platform cannot be a counterparty an Indian exchange can trust. FIU-IND has acted against offshore platforms three times: nine in December 2023, 25 in October 2025 and 15 in September 2026 (same Wire item). All three rounds enforced registration.

Singapore applies the rule to licensed digital payment token service providers, with reduced data at or below S$1,500 and full data above (State of Play). Transfers to self-hosted wallets are outside the rule and handled as higher risk. MAS’s stablecoin consultation, which closes on 16 October 2026, says it is weighing limits on unhosted wallets but has not yet proposed any (Wire).

Hong Kong applies the rule in law, in section 13A of Schedule 2 to the Anti-Money Laundering and Counter-Terrorist Financing Ordinance, with full data at or above HK$8,000, and has the most detailed rules for self-hosted wallets of the three (State of Play). It is also the only one of the three that names the message-signing test as a way to prove control of a wallet.

The case against

The rule covers the firms that comply and misses the transfers that matter. FATF’s March 2026 report on stablecoins cites Chainalysis estimates that stablecoins carried 84 per cent of illicit virtual asset transaction volume in 2025, often through unhosted wallets, and describes peer-to-peer transfers that never pass through a regulated provider (FATF, 3 March 2026). FATF’s July 2026 update names offshore providers outside effective supervision and peer-to-peer transfers through unhosted wallets among the rising risks (FATF, 16 July 2026). On this view, a registered Indian exchange pays for message networks, counterparty reviews and held deposits, while the activity the rule targets moves to wallets and platforms it does not reach.

The alternative is to put the control in the token. FATF lists as good practice that stablecoin issuers can freeze, burn or withdraw tokens, and use allow-lists that restrict transfers to pre-approved addresses or deny-lists that block high-risk ones (FATF, 3 March 2026). Under this approach the issuer’s smart contract enforces the control on every transfer, including transfers between self-hosted wallets. The cost is that the issuer gains a power over every holder, and the control works only for tokens with an issuer, not for ether or bitcoin. The trade-offs of allow-listed tokens are covered in an earlier piece.

The non-ledger alternative is to restrict the exit. A regulator can limit or block withdrawals to self-hosted wallets, so that crypto leaves regulated firms only for other regulated firms. Hong Kong’s requirement that firms set transaction limits for unhosted wallets where appropriate is a step in this direction (SFC AML Guideline, para 12.14.3). The cost is that customers who want to hold their own keys move to platforms outside the rules, such as those FIU-IND’s notices target.

The rule covers the point where crypto turns into rupees. Criminals need to cash out, and registered exchanges are where crypto meets bank accounts. A record of who sent what to whom at that point is what investigators use, and FATF still lists better travel rule implementation among its priority actions (FATF, 16 July 2026). The objection is right that the rule misses peer-to-peer transfers, and that justifies the cost only if enough illicit value reaches a registered exchange in the end. No published source measures that share, or how often FIU-IND has used travel rule data in a case. FIU-IND data on suspicious transaction reports that drew on travel rule data would settle it.

For Ethereum

An ether or ERC-20 transfer carries the sender’s address, the receiver’s address and the amount, and nothing that names a person. Every travel rule step above therefore happens off chain, and the only link back to Ethereum is the transaction identifier.

The self-hosted wallet rules touch Ethereum directly. A message-signing test on Ethereum uses a signed message, usually in the EIP-191 format, which a wallet signs with its private key and anyone can check against the address (EIP-191). That works for an ordinary account controlled by a private key. A smart contract wallet is a contract, which cannot sign a message itself, so ERC-1271 lets the contract confirm a signature through a standard function (ERC-1271). Whether an exchange’s check supports ERC-1271 decides whether customers with smart contract wallets can pass the message-signing test or must fall back on the micropayment test. Neither the SFC nor MAS mentions this case. A micropayment test works with any wallet but costs the customer a transaction fee.

Allow-lists and freeze functions in stablecoin contracts are the on-chain alternative in “The case against”. If Singapore restricts unhosted wallets for MAS-regulated stablecoins, the control would sit in token contracts on Ethereum and other networks (Wire).

What to watch

  • 16 October 2026: comments close on MAS’s stablecoin amendments, including the question of unhosted wallets.
  • FIU-IND guidance on transfers to and from self-hosted wallets, which its January 2026 guidelines do not cover.
  • The first FIU-IND penalty that cites the travel rule paragraphs (5.3.1 to 5.3.6), as distinct from registration.
  • Whether any of the 15 platforms named in September 2026 registers with FIU-IND and joins a travel rule network.
  • June or July 2027: FATF’s next targeted update, published each year since 2020, and whether more jurisdictions move from legislation to supervision and enforcement.
  • End of 2030: the revised Recommendation 16 takes effect, with standardised information for peer-to-peer cross-border payments above USD/EUR 1,000 (FATF, 18 June 2025).