Travel Rule data privacy: what you may share, with whom, and what never goes on chain

Travel Rule compliance is usually treated as a messaging problem. Pick a protocol, map the fields, send the payload. The harder question is a privacy one. The same originator and beneficiary details that an anti money laundering supervisor expects you to transmit are personal data that a privacy regulator expects you to minimise, secure and eventually delete. Travel Rule data privacy sits in that gap.

For a credit union, a tier-2 bank or a licensed money service business, the gap is not theoretical. You send names and account identifiers to a counterparty you may never have met. That counterparty often sits in another jurisdiction. The payment itself may settle on a public blockchain. Each of those three facts raises a separate privacy question. This article works through them in the order an examiner will.

Is Travel Rule data personal data, and does privacy law apply?

Almost always, yes. The required payload is built from names, account or wallet identifiers and, above certain thresholds, an address or an identity document number. Under the EU General Data Protection Regulation, that is personal data about an identified natural person. Canadian federal privacy law and the UK regime reach the same conclusion. Even a business payment carries personal data, because the sender's authorised signatory and the beneficiary's named contact are individuals.

A wallet address on its own may identify nobody. Once your records tie it to a customer, it identifies someone, and a Travel Rule message is exactly that tie. The European Data Protection Board took a similar view in its Guidelines 02/2025 on processing of personal data through blockchain technologies, issued for public consultation in 2025. The safe design assumption is that the whole payload is personal data. Everything else follows from that.

What is your lawful basis for sharing originator and beneficiary data?

You need a lawful basis before you send anything. The right choice is legal obligation, not consent. Consent must be freely given and capable of being withdrawn. Neither is true here. A payer who refuses cannot have the payment processed, and a withdrawal would leave you unable to meet the rule.

The obligation has to be a real and specific one. FATF Recommendation 16, extended to virtual asset transfers by FATF's 2019 standards, is the international benchmark, and it sets a de minimis threshold of USD 1,000 for those transfers. In the United States, FinCEN's recordkeeping and Travel Rule requirements at 31 CFR 1010.410 apply from USD 3,000, and FinCEN's 2019 guidance applied them to convertible virtual currency. In the European Union, Regulation (EU) 2023/1113 has applied since 30 December 2024 and sets no de minimis for crypto-asset transfers.

Write the basis down per jurisdiction, not once globally. The threshold differs, the data set differs, and so does the regulator you will explain it to. A firm licensed in two countries may owe a different payload on the same corridor depending on which entity books the payment.

How does Travel Rule data cross a border under GDPR Chapter V?

This is the step most programmes miss. Sending personal data from the European Union to a counterparty outside it is a restricted transfer. Chapter V of the GDPR requires a mechanism for it: an adequacy decision, standard contractual clauses, or a narrow derogation. An AML obligation to send the data is not itself a transfer mechanism.

Many counterparty institutions sit in jurisdictions with no adequacy decision. Standard contractual clauses are the workable answer, and they have to be signed before the first payment rather than after the first query. Some firms lean on the Article 49 derogation for important reasons of public interest. Regulators read derogations narrowly and expect them to be occasional, so do not open a standing corridor on one.

The practical consequence will surprise your payments team. Opening a corridor now needs a legal step as well as a technical one. Before the first live transfer you want a data sharing agreement with the receiving institution and a record of which mechanism covers that route. Keep that record where operations can find it, because the question tends to arrive mid payment.

Why does nothing identifying belong on a public blockchain?

A public chain is append only. You cannot delete an entry, you cannot correct it, and you cannot control who reads it. That collides directly with the right to erasure, with rectification and with data minimisation. The EDPB's 2025 blockchain guidelines make the same point, which is to design so that personal data never reaches the chain at all.

For a settlement leg the rule is simple. On chain, carry an amount and a reference. Off chain, carry the identities. A transaction hash, a payment reference and a unique end to end transaction reference are enough to join the two records later during an audit. Nothing in that set names a person. Hashing a name is not a fix either, because a hash of a known value can be reproduced and tested.

The chain should prove that value moved and when. It should never be the place a regulator discovers who moved it.

What happens when the counterparty cannot receive the data?

Two gaps recur, and both need a documented answer. The first is the sunrise problem. Your jurisdiction has implemented the rule and the receiving one has not, so there is no obliged counterparty to send to. FATF's June 2025 targeted update on implementation of its virtual asset standards found that adoption and supervision remain uneven across jurisdictions.

The second gap is a transfer to or from a wallet that no institution controls. There is no counterparty institution to receive a payload at all. In both cases, the answer is a recorded decision rather than silence. Note what you collected, what you could not send, why, and the risk assessment you applied before releasing the payment.

Do not close either gap by pushing more data to an unverified endpoint. An unauthenticated transmission is a privacy incident waiting to be reported, and it proves nothing to your AML supervisor. Verify the counterparty institution first, or hold the payment and say why.

What evidence does each regulator ask to see?

The two files overlap more than most firms expect, and building them separately is how they drift apart. An AML examiner wants to see that the required information was collected, that it travelled with the payment, and that someone looked at the incoming payload rather than filing it. Expect requests for a sample of transfers at and just below each threshold, the transmission logs for them, and the decisions taken where a payload was missing or incomplete.

A privacy regulator asks a different set of questions about the same flow. Which fields do you send, and why each one. What is the lawful basis, and where is it recorded. Which mechanism covers the transfer out of the European Union, and who signed it. How long do you keep the data, and can you show a deletion actually happened. Can a customer be told, in plain language, that their details are shared with a receiving institution.

Build one evidence set that answers both. A single register per corridor, holding the counterparty, its licence check, the transfer mechanism, the fields sent, the retention clock and the last exception, is usually enough. Two registers maintained by two teams will disagree within a year, and the disagreement is the finding.

How do you build a process that satisfies both regulators?

Sequence the privacy controls with the messaging work, not after the first corridor goes live. The order below is the one that survives an examination.

• Map the data set per jurisdiction: which fields, from which threshold, under which named obligation.
• Record the lawful basis and complete a data protection impact assessment before the first live payment.
• Verify the counterparty institution and its licence, then sign the transfer mechanism and the data sharing agreement.
• Transmit over an authenticated and encrypted channel, and log both the transmission and its acknowledgement.
• Keep identities off the settlement leg, carrying only an amount and a reference on chain.
• Set retention to the AML record keeping period in each jurisdiction, then delete on schedule and keep the deletion evidence.
• Rehearse the exceptions twice a year, including a counterparty that cannot receive the payload.

The last step matters more than it sounds. Findings rarely concern the happy path. They concern what the firm did on the day delivery failed, and whether anyone wrote it down.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross-border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. It settles in regulated stablecoins on public blockchains while keeping identity data off them. FATF Travel Rule information is carried as IVMS101 data alongside ISO 20022 messages, pacs.008 for the customer credit transfer and pacs.009 for the interbank leg, tracked end to end by UETR, so the on-chain record holds an amount and a reference rather than a name. KYB and KYC onboarding, sanctions and PEP screening and a tamper-evident audit trail sit in the same platform, which means the file an AML examiner asks for and the record a privacy regulator asks for come from one place.