Travel Rule integration: what to do when the counterparty cannot receive the message
How exchanges should handle unreachable Travel Rule counterparties: EU TFR requirements, secure fallbacks, incoming holds, self-hosted wallets and audit logs.
Kostiantyn Boiko, Blockchain Engineer
English original
If the receiving exchange cannot receive the required data through your usual Travel Rule network, hold the withdrawal while you establish another compliant, secure channel. Article 14(8) of the Transfer of Funds Regulation (EU) 2023/1113 bars the originator’s provider from initiating or executing a crypto-asset transfer “before ensuring full compliance” with Article 14, and Article 14(4) requires the data to go “in advance of, or simultaneously or concurrently with” the transfer. You can find another secure channel, let the customer choose another destination, or cancel. Nothing moves on chain while you decide.
Incoming transfers are harder, because the coins have already arrived. Article 17 requires risk-based procedures to execute, reject, return or suspend a transfer with missing data, which in practice means a pending state the customer can see. FATF’s July 2026 survey shows that implementation remains uneven, but legislation and supervisory activity do not establish whether an individual counterparty can receive your message. A Travel Rule integration has to treat unreachable counterparties as a normal case.
We build exchange, wallet and custody software that has run in production at the reference exchange since 2024, with withdrawal approval queues, address whitelists and pending states. This is a technical reading, not legal advice. Required marks a rule with its citation; Our recommendation marks our engineering advice.
What does the Travel Rule require?
FATF applies Recommendation 16 to virtual assets through paragraph 7(b) of the Interpretive Note to Recommendation 15. The originating provider obtains originator and beneficiary information, submits it to the beneficiary provider “immediately and securely” and makes it available to authorities. A footnote allows the data to be sent directly or indirectly; it need not be attached to the on-chain transfer.
On 18 June 2025 FATF announced revisions to Recommendation 16, including standardised information for cross-border person-to-person payments above USD/EUR 1,000 and measures to reduce payment fraud and errors. FATF set an implementation deadline of the end of 2030; firms’ binding obligations depend on applicable implementing law. FATF’s explanatory note says VASPs are not brought directly into Recommendation 16; the updated requirements reach them through Recommendation 15. The revised interpretive note keeps the rule that matters here: a beneficiary institution needs risk-based procedures for when to execute, reject or suspend a transfer that lacks required information.
What is the Travel Rule sunrise issue, and how big is it?
FATF’s June 2025 Best Practices on Travel Rule Supervision define the sunrise issue as the “uneven adoption of the Travel Rule across jurisdictions”. The paper says an ordering institution can require Travel Rule compliance whatever the beneficiary’s jurisdiction demands, and that FATF does not require tools to interoperate, though VASPs should weigh interoperability when choosing one.
FATF’s seventh targeted update, published on 16 July 2026:
| Survey year | Jurisdictions with Travel Rule legislation passed |
|---|---|
| 2025 | 85 of 117 (73%) |
| 2026 | 91 of 109 (83%), with 11 more in progress |
The figures are self-reported: 147 jurisdictions responded overall and 109 answered the legislation question. The executive summary says almost half of the jurisdictions with a law had taken no supervisory or enforcement action; paragraph 25 puts it at 55 of 91.
What does the EU require when the counterparty cannot receive?
Regulation (EU) 2023/1113 has applied since 30 December 2024 wherever the originator’s or beneficiary’s provider has its registered office in the EU, with no minimum amount for crypto-asset transfers (recital 30). The EBA’s Travel Rule Guidelines (EBA/GL/2024/11) apply from the same date.
| Rule (citation) | What it means for the system |
|---|---|
| Art. 14(1)–(2) | Originator and beneficiary names; applicable DLT addresses and crypto-asset account numbers; the originator’s address including country, official personal document number and customer identification number, or alternatively date and place of birth; and qualifying LEI or equivalent identifiers where the regulatory conditions apply |
| Art. 14(4), 14(8); EBA GL 25(b) | Send the data no later than the initiation of the blockchain transaction; do not initiate or execute until Article 14 is met |
| EBA GL 24 | The exception for systems with technical gaps ended on 31 July 2025 |
| EBA GL 26 | Assess a messaging system’s reachability: which counterparties it reaches and how many transfers succeed |
| Art. 16(1), (3)–(5) | Detect missing data; apply beneficiary-verification requirements before making assets available, including the limited low-value exception and rules on prior verification |
| Art. 17(1) | Reject or return, or request the data before making the assets available |
| EBA GL 49–50 | Empty fields and meaningless values (such as “xxxxx” or “My Customer”) count as missing |
| EBA GL 56 | Deadline for requested data: 3 working days inside the EU, 5 from outside, up to 7 days where the chain has more than two parties or a non-EU provider |
| EBA GL 64 | If you execute despite gaps, document why; never execute if the parties cannot be unambiguously identified |
| Art. 17(2); EBA GL 67–75 | Identify repeatedly failing counterparties; use warnings and deadlines where appropriate, then reject future transfers or restrict or terminate the relationship as required; report identified repeated failures within the EBA reporting deadline |
| Art. 18; Art. 26 | Consider missing data when assessing suspicion and whether an FIU report is required; retain the required records for five years, subject to any lawful national extension |
Travel Rule and unhosted wallets: the EUR 1,000 check
For a transfer to a self-hosted address, Article 14(5) has the provider obtain and hold both parties’ data and make the transfer individually identifiable; Article 16(2) mirrors this for incoming transfers. Above EUR 1,000, the provider must assess whether its customer owns or controls the address. The EBA guidelines set out the TFR self-hosted wallet verification steps:
- Classify first with blockchain analytics, third-party data or messaging identifiers, and ask the customer if they give no answer, before the transfer starts or the assets are made available (GL 77–79).
- Value it in euros at that moment’s rate, ignoring fees (GL 81–82).
- Assess ownership or control, using an appropriate method where verification is needed: attended or unattended remote verification showing the address, a small predefined transfer, a signed message, or another reliable means; combine methods if one is not enough (GL 83–85).
- Reuse verification where permitted: maintain a customer-specific whitelist only while the conditions in GL 86 remain satisfied, and reassess when ownership, control or risk changes.
Article 37(2) asked the Commission to report by 1 July 2026 on self-hosted address risks and whether specific measures are needed. Check the Commission’s published follow-up before relying on this section; the supplied research did not establish whether the report had been published by 31 October 2026.
How do other regimes handle it?
| Regime | Counterparty cannot receive | Incoming data missing |
|---|---|---|
| South Africa, FIC Directive 9 (from 30 April 2025) | Every transfer; a provider “may not execute” one it cannot make compliant (para. 4.8); FIC guidance PCC 61 allows no buffer time | Policies to execute, suspend or return (para. 6.5); no value to the client while held |
| Singapore, MAS Notice PSN02 | The ordering institution “shall not execute” if it cannot comply (para. 13.11) | Policies to execute, reject or suspend (para. 13.14) |
| Dubai VARA jurisdiction, excluding DIFC; circular dated 24 February 2026 | Do not execute unless requirements are met; use best efforts to find another secure channel and reassess persistent cases | Reject where possible, delay, permit or return; report systemic failures |
How do you find the counterparty VASP?
Networks use four approaches, often combined:
- Customer-assisted discovery: the customer selects a platform, after which supported network workflows ask that platform to confirm the address relationship before personal data is disclosed (CODE, GTR, Sygna, VerifyVASP).
- Address lookup: hashed address registries (Notabene), on-chain attestations the controlling VASP answers (Shyft Veriscope), or blockchain analytics attribution.
- Directory lookup of the counterparty’s endpoint and certificate (TRISA).
- An address that carries routing: TRP’s Travel Address, a URL the beneficiary gives instead of a bare chain address.
Our recommendation: treat attribution as evidence, not truth. Store which method classified the address, the answer and when, and let a compliance officer override it with a reason.
Which Travel Rule protocols and networks exist?
The table below summarises the projects’ own documentation reviewed for this article. We have not independently tested delivery, security or interoperability; confirm current capabilities, supported versions and commercial terms before procurement.
| Name | What it is | Finding the counterparty | Data and transport | Counterparty not on it |
|---|---|---|---|---|
| CODE | Commercial hub set up by Bithumb, Coinone and Korbit | Customer selects VASP; address checked | IVMS101; end-to-end encrypted | Docs cite links to VerifyVASP, GTR, Sygna |
| GTR | Commercial hub, Singapore, since 2022 | Customer selects VASP; beneficiary confirms address | Confirm the current payload schema, encryption boundaries and hub authentication with GTR | Email or bulletin board; delivery not guaranteed |
| Notabene | Commercial platform on the open TAP spec | Relationships, hashed address registry, analytics | IVMS101; DIDComm; end-to-end | Says it reaches counterparties without a tool |
| Shyft Veriscope | Self-hosted software using Shyft Network attestations | On-chain attestation; controlling VASP responds | IVMS101 over peer-to-peer HTTPS | Request waits until the VASP joins |
| Sygna Bridge | Commercial messaging hub | VASP code plus name; address check | IVMS101; encrypted, signed | Email protocol for vetted VASPs |
| TRISA | Open protocol (MIT), OpenVASP stewardship since 1 October 2026 | Global Directory Service, also the CA | gRPC over mTLS; IVMS101 | Envoy can email a secure link |
| TRP | Open royalty-free spec, OpenVASP Association | Travel Address from the beneficiary | IVMS101 subset; TLS 1.3, mTLS | None in core spec; TRISA extension |
| VerifyVASP | Commercial network operated by VerifyVASP Pte. Ltd. | Customer selects VASP; beneficiary confirms | IVMS101; end-to-end via central relay | Confirm out-of-network options directly with the vendor |
Several offer unhosted wallet proofs by signed message or test transfer. A fallback feature does not by itself establish secure delivery, complete counterparty coverage or regulatory compliance. The TFR is technology-neutral (recital 50); EBA GL 26 asks you to measure a network’s reach.
What should the system do with an outgoing transfer?
| Situation | Required (citation) | Our recommendation |
|---|---|---|
| VASP found and reachable | Transmit required data no later than initiation of the blockchain transaction; meet Article 14 before allowing initiation or execution (Art. 14(4), 14(8); GL 25(b)) | As a conservative policy, require a defined delivery acknowledgement before broadcast and store its ID; distinguish transport receipt from counterparty compliance approval |
| VASP found, not reachable | No execution without Article 14 compliance; for third-country recipients, assess data protection and establish any required GDPR Chapter V transfer mechanism (recital 34; Art. 25) | Hold as awaiting_counterparty; retry, try another network or secure email, then cancel and release the balance |
| Unhosted wallet | Both parties’ data; above EUR 1,000 assess ownership (Art. 14(5); GL 83) | Assess whether the customer controls the address; reuse valid verification only under a monitored, customer-specific whitelisting policy |
| Unknown | Classify before initiation; ask the customer (GL 78–79) | Block until classified; never default to “self-hosted” to get a transfer out |
Our recommendation: retry for a few minutes synchronously, then with backoff for a period your policy sets (we would start at 24 hours) before cancelling. The funds stay reserved in the ledger; nothing is signed.
What should the system do with an incoming transfer?
| Situation | Required (citation) | Our recommendation |
|---|---|---|
| Data complete | Apply beneficiary-verification requirements and applicable exceptions (Art. 16(3)–(5)) | Match the message to the verified customer record; review discrepancies and release only after all required checks |
| Data missing or meaningless | Reject or return, or request data first (Art. 17(1); GL 49–50, 56) | Credit as held, visible but not spendable; request through the same network (GL 58) |
| Data late | Decide by the deadline; record why if you execute (GL 62, 64) | Match late messages by transaction hash; count delays toward the counterparty’s failure rate (GL 68) |
| From an unhosted wallet | Data from your customer; above EUR 1,000 assess ownership (Art. 16(2); GL 63) | Ask in-app before crediting; reuse whitelisted proofs |
A confirmed on-chain transfer cannot be undone by rejecting its Travel Rule message; returning assets requires a separate transaction. Where returning to the original address is not possible, EBA GL 55 says to hold the assets in a secure, segregated account while arranging a return with the originator.
Our recommendation: before returning assets, complete the required sanctions and compliance review, authenticate the sending platform’s instructions, and confirm the return address, network and any memo or tag. Do not assume the source address can credit the original customer. State who pays the network fee.
Which pending states do you need?
Our recommendation: model awaiting_counterparty, awaiting_customer_info, ownership_check, compliance_hold, return_pending, returned, rejected and released, and record who made each move, under which policy version, and why. In our custody software a stuck-money screen collects transfers that are waiting for approval and have been forgotten; held Travel Rule transfers belong in the same view.
What should you log for auditors?
Required: retain the prescribed records for five years, subject to lawful national extensions (Art. 26); document your risk factors (GL 52), reasons for execution despite information gaps (GL 64), and identification and handling of repeatedly failing counterparties (GL 67–75).
Our recommendation: for each transfer, log:
- transfer ID, transaction hash, asset, amount, and euro value with the rate and time used;
- counterparty classification, method and result;
- network, message IDs, and timestamped transmission, acknowledgement and blockchain events, with synchronised clocks and tamper-evident records to reconstruct the sequence;
- a payload integrity reference, with the required retrievable records encrypted in an access-controlled store; apply retention and deletion rules to payloads, proofs, logs and backups, and do not publish personal data or linkable identifiers on-chain (Art. 25–26);
- each state change, policy version, decision maker and reason;
- ownership proofs and per-counterparty failure counts.
What should the customer see?
Good practice: explain the transfer’s status, the customer’s next step and the next review point. Do not disclose suspicious-activity reports or other information prohibited by applicable tipping-off rules.
- Counterparty not reachable: “We could not deliver the required details to the receiving platform. Your funds have not left your account. We will retry for 24 hours, or you can cancel.”
- Unhosted, above EUR 1,000: “For this transfer above EUR 1,000, we need to assess whether you control the wallet. Follow the verification method shown here. We may reuse a valid result, but can request a new check if circumstances change.”
- Incoming, data missing: “We received 1,250 USDT for your account, but it is not yet available to spend. We have requested information from the sending platform and will update you by 7 November. Release or return depends on the required checks.”
Travel Rule FAQ
What is the Travel Rule sunrise issue?
FATF’s name for the uneven adoption of the Travel Rule across countries, which leaves one side of a transfer with no obligation or no tool to exchange data. In its July 2026 survey, FATF reported legislation in 91 of the 109 jurisdictions answering that question; this does not establish whether a particular counterparty has a working integration.
Can I send a withdrawal if the receiving exchange is on no Travel Rule network?
In the EU, network membership is not mandatory, but Article 14 must be met and the required data transmitted securely no later than initiation of the blockchain transaction. An affirmative counterparty acceptance is not a blanket requirement in the cited provisions. Article 14(8) of Regulation (EU) 2023/1113 bars initiating or executing the transfer before compliance. Some networks offer email fallbacks; otherwise the customer picks another destination or cancels.
Does the Travel Rule apply to unhosted wallets?
EU TFR obligations cover transfers between an in-scope CASP and a self-hosted address. The CASP obtains and holds the required information and, above EUR 1,000, assesses whether its customer owns or controls the address. Requirements outside the EU depend on local law.
How long can I hold an incoming transfer with missing information?
The EBA’s missing-information response deadlines are generally three working days for EU senders and five for non-EU senders, with an extension up to seven days in specified cases. They are not a universal maximum holding period. If the deadline expires, apply your documented risk-based decision process; do not release funds automatically.
Do I have to use a particular Travel Rule protocol?
No. The EU regulation is technology-neutral and FATF does not require tools to interoperate. The EBA asks you to assess each system’s reach, and FATF notes that many VASPs run several systems in practice.
How BitPolaris helps
Our exchange ships with an operations console covering deposits, withdrawals and approvals, stuck funds, reconciliation and an audit log. Custody adds withdrawal address whitelisting with a 24-hour delay on new addresses, on by default, approval quorums per asset and amount band, and an exportable log of every operator action. The wallet runs Address Shield format, network and lookalike checks on every send.
Our product pages list no built-in connection to a Travel Rule network, so plan to contract a provider and agree the integration scope with us. The Licence Technical Pack documents AML, KYT and Travel Rule flows for a MiCA or VARA application (Pro, €6,300 one-time). See also what regulators ask for.
We are not a law firm and never hold customer funds or keys. Installing our software does not make anyone compliant or licensed.
Sources
- FATF, FATF updates Standards on Recommendation 16 on Payment Transparency, 18 June 2025
- FATF, Explanatory Note for Revised R.16, June 2025
- FATF, The FATF Recommendations, updated June 2026
- FATF, Seventh Targeted Update on Virtual Assets/VASPs and press release, 16 July 2026
- FATF, Best Practices on Travel Rule Supervision, June 2025
- Regulation (EU) 2023/1113, OJ L 150, 9 June 2023
- EBA, Travel Rule Guidelines, EBA/GL/2024/11 (PDF), 4 July 2024
- Financial Intelligence Centre, Directive 9 and PCC 61
- Monetary Authority of Singapore, Notice PSN02 and Guidelines to PSN02
- VARA, Circular on the UAE Virtual Assets Travel Rule, 24 February 2026, and Rulebook, Travel Rule section
- OpenVASP Association, Travel Rule Protocol, specification and TRISA–OpenVASP FAQ
- TRISA, Global Directory Service and Envoy
- Notabene, developer documentation and product page
- Sygna, developer documentation and Sygna Bridge
- VerifyVASP, documentation and product page
- CODE, CodeVASP documentation
- Global Travel Rule, out-of-network documentation
- Shyft Network, Veriscope documentation