The UK Travel Rule for cryptoasset transfers came into force on 1 September 2023 through amendments to MLR 2017. The UK regime differs from the EU TFR in two important ways: a £1,000 threshold for transfers between hosted and unhosted wallets (TFR uses €0 for all transfers), and risk-based flexibility on the sunrise problem where counterpart VASPs cannot yet exchange Travel Rule data. JMLSG Sector 22 is the sectoral guidance crystallising UK operational expectations. This guide covers the legal framework, JMLSG Sector 22 interpretation, threshold and geographic scope, beneficiary VASP verification, FCA expectations, the common operational failure modes and a side-by-side comparison with the EU TFR.
Quick reference
- Effective date: 1 September 2023.
- Legal basis: New Part 7A added to MLR 2017 (Regulations 64A–64H) by the 2022 amendment.
- Thresholds: CASP-to-CASP transfer £0 (all transfers in scope); unhosted wallet ↔ CASP transfer £1,000 (in scope above this threshold).
- Sunrise approach: UK allows risk-based flexibility — if the counterpart VASP cannot exchange data, transfers may proceed with recordkeeping and risk assessment.
- Guidance: JMLSG Sector 22 (added 2022, updated 2023).
- Geographic scope: A UK CASP's inbound and outbound transfers, domestic and international, are in scope.
1. Legal framework — MLR 2017 Part 7A
The UK Travel Rule was implemented by adding a new Part 7A to MLR 2017 (Regulations 64A–64H) through the 2022 amendment. Part 7A is the UK's transposition of FATF Recommendation 15 for cryptoassets, paralleling MLR 2017's existing "transfer of funds" framework for traditional payments.
Key concepts:
- CASP (Cryptoasset Service Provider): in the UK this term covers FCA-registered cryptoasset exchange providers and custodian wallet providers.
- Originator: the party initiating a crypto transfer.
- Beneficiary: the party receiving a crypto transfer.
- Unhosted wallet: a wallet not held by a VASP, where the owner controls the private keys.
Regulation 64B (originator obligations) and Regulation 64C (beneficiary obligations) define the responsibilities of each side.
2. Threshold and scope
The UK Travel Rule has a two-tier threshold structure:
| Scenario | Threshold | Action |
|---|---|---|
| CASP A → CASP B (both crypto businesses) | £0 | Full Travel Rule data set on every transfer |
| Unhosted wallet → CASP (receiver is a crypto business) | Above £1,000 | Above £1,000: full Travel Rule data; below: simplified information |
| CASP → Unhosted wallet | Above £1,000 | Above £1,000: verification of sender, recordkeeping |
Thresholds are per-transfer; however, linked transactions can trigger an aggregation analysis — if a customer sends five £900 transfers within 24 hours, the firm must consider deliberate structuring to evade the threshold.
Geographic scope: a UK FCA-registered CASP's UK domestic transfers are in scope, as are inbound and outbound international transfers. The UK Travel Rule applies even when the counterpart is outside the UK (for example a Turkish VASP regulated under KVHS, or an EU-based CASP).
3. JMLSG Sector 22 — sectoral guidance
The Joint Money Laundering Steering Group publishes sectoral guidance built on top of MLR 2017. Sector 22: Cryptoasset Service Providers was added in 2022 and updated in 2023 to reflect the UK Travel Rule's coming into force.
Sector 22 structure:
- 22.1 — Introduction: scope, terminology, CASP position within MLR 2017.
- 22.2 — Risk assessment: crypto-specific risk factors (mixer usage, country risk, customer segment).
- 22.3 — Customer due diligence: digital onboarding, beneficial ownership, EDD scope.
- 22.4 — Transfer of cryptoassets (Travel Rule): detailed operational guidance.
- 22.5 — Transaction monitoring: on-chain monitoring approaches.
- 22.6 — SAR reporting: crypto-specific suspicion indicators.
- 22.7 — Recordkeeping and training.
Sector 22 compliance is not strictly mandatory by statute — but because JMLSG is HM Treasury-recognised, non-compliance is hard to defend before the FCA or in court. In practice UK cryptoasset firms use Sector 22 as their operational rulebook.
4. Travel Rule data set
The data set required under the UK Travel Rule mirrors FATF Recommendation 15:
For the originator (sender):
- Full name / corporate name
- Originating account / wallet reference
- Address OR customer identification number / date and place of birth
For the beneficiary (receiver):
- Full name / corporate name
- Beneficiary account / wallet reference
The data set aligns with fields supported by the IVMS 101 messaging standard. Our IVMS 101 standard guide covers the data structure in detail.
The UK regime does not mandate a specific messaging protocol; IVMS 101 has become the de facto standard. CASPs select from network solutions like TRP, Sygna, TRISA and OpenVASP.
5. Beneficiary VASP verification
Before completing a transfer, the UK Travel Rule expects the originator to assess whether the beneficiary wallet is "held by a VASP". The verification process:
- VASP detection: identify whether the destination wallet is associated with a VASP (typically via blockchain analytics and VASP directory lookup).
- Counterpart VASP validation: confirm the identified VASP is a genuine cryptoasset business, not on sanctions lists, and meets a minimum AML standard.
- Travel Rule data exchange: if validation passes, send the Travel Rule message via the chosen network.
- If unhosted: alternative protocol — collect beneficiary detail from the originating customer (name, address or identifier), retain records; simplified summary for below-threshold transfers.
Counterparty reliability in UK practice maps to the concept of "counterparty due diligence": each partner VASP's FATF/MLR compliance, sanctions exposure and MLRO structure should be reviewed annually.
6. The sunrise problem — UK approach
The sunrise problem: globally, not all VASPs are subject to Travel Rule at the same moment, creating scenarios where one side is in scope but the counterpart is not (or has no technical infrastructure). Our Travel Rule sunrise problem guide covers the global dimension.
The UK approach recognises risk-based flexibility. JMLSG Sector 22 and the FCA's Dear CEO correspondence distinguish three scenarios:
- Counterpart VASP is in scope but lacks technical infrastructure — the UK CASP may proceed, keeping records, but repeated occurrences should feed into the firm-wide risk assessment.
- Counterpart jurisdiction has not yet enacted Travel Rule — the UK CASP may proceed, again with records and risk assessment.
- Counterpart is sanctioned or in a high-risk jurisdiction — the transfer must be refused.
This sunrise notice approach is one of the most visible differences between the UK and the EU TFR — the latter takes a much stricter, near-absolute data-mandatory model.
7. Comparison with the EU TFR
| Topic | UK Travel Rule | EU TFR (in force 2024) |
|---|---|---|
| Effective date | 1 September 2023 | 30 December 2024 |
| Legal basis | MLR 2017 Part 7A | EU Regulation 2023/1113 |
| CASP-CASP threshold | £0 (every transfer) | €0 (every transfer) |
| Unhosted wallet threshold | £1,000 | €1,000 |
| Sunrise flexibility | Risk-based flexibility recognised | Strict; transfer blocked if counterpart not in scope |
| Counterpart VASP verification | Counterparty DD expected | "Trustworthy" counterpart lists (in development) |
| Messaging standard | Unspecified (IVMS 101 de facto) | IVMS 101 referenced |
| Geographic scope | UK CASP outbound and inbound | EU CASP outbound and inbound |
Our EU financial regulation guide covers the EU TFR in detail.
8. FCA expectations and common operational failures
Since 2023 the FCA has used "Dear CEO" letters to highlight four core expectations on UK Travel Rule compliance:
(1) Live operation: "not yet implemented" is unacceptable. Travel Rule messages must be sent, received and logged in real time.
(2) Counterpart VASP verification procedure: must include an annual review cycle; "default trust" is unacceptable.
(3) Risk-based sunrise handling: repeated counterpart-infrastructure gaps must be tracked in the risk assessment and feed into customer/jurisdiction-level policy.
(4) Audit log and traceability: every Travel Rule message must have an audit log retained for at least five years.
Common operational failures:
- Generic counterpart validation: a single-tier system treating all VASPs as equally trustworthy.
- Below-threshold structuring not detected: a customer making serial £999.99 transfers and the firm not flagging the pattern.
- Skipped beneficiary classification: transfer executed without determining whether the destination is a VASP wallet or unhosted.
- Messaging network mismatch: the firm operates on one network (e.g. TRP) while the counterpart is on another (e.g. Sygna) and no bridge is in place.
- No sunrise tracking: risk-based flexibility used but not documented.
These failure modes may not trigger enforcement action immediately, but they reliably appear in supervisory feedback during annual reviews.
9. Multi-jurisdictional perspective
For a cryptoasset firm serving UK, EU and (for example) Turkish customers concurrently, three Travel Rule regimes operate in parallel:
- UK: £1,000 unhosted threshold, JMLSG Sector 22, risk-based sunrise.
- EU: TFR, €0 every transfer, strict sunrise.
- Turkey: KVHS regulation, FATF Recommendation 15 reference, MASAK interpretation.
Our Travel Rule by jurisdiction comparison places the three side by side. A single infrastructure layer that is "customer-jurisdiction aware" — one policy for UK customers, another for EU, a third for Turkey — becomes necessary.
10. Practical implementation checklist
A live-readiness checklist for UK Travel Rule:
- Registered as a CASP on the FCA cryptoasset firms register (mandatory since 10 January 2020)
- Travel Rule policy written and approved by the MLRO
- Messaging network integration (TRP, Sygna, Veriscope, etc.) live
- IVMS 101 message generation and parsing infrastructure
- Beneficiary VASP verification workflow (blockchain analytics + VASP directory)
- Counterparty due diligence procedure
- Sunrise tracking — log of risk-based flexibility usage
- £1,000 threshold checks and below-threshold structuring scenarios
- Audit log retention (5+ years)
- Annual SMCR compliance review
Frequently asked questions
What does the UK Travel Rule require for transfers to unhosted wallets?
For transfers from a UK CASP to an unhosted wallet of £1,000 or more, the sender must be verified (in most cases the customer of the CASP), and beneficiary information (name or identifier, address or identifier) collected from the customer. Because there is no counterpart VASP to receive a Travel Rule message, the data is retained by the UK CASP. For transfers below £1,000, simplified information is acceptable.
Do I have to refuse the transfer if there is a sunrise problem?
No — the UK regime allows risk-based flexibility. If the counterpart VASP is in scope but lacks technical infrastructure, the UK CASP may proceed, provided that: (a) the situation is documented, (b) repeated cases are tracked in the firm-wide risk assessment, (c) the counterpart is not in a high-risk jurisdiction or sanctioned. The EU TFR is stricter — sunrise flexibility is much more limited there.
Which messaging network should I use for Travel Rule messages?
The UK regime does not mandate a specific network. Common options: TRP (Travel Rule Protocol) — supported by major exchanges; Sygna Bridge — popular in Asia; TRISA — open source; OpenVASP — European focus; Veriscope — institutional. You do not need to be on the same network as the counterpart — cross-network bridge solutions (e.g. Notabene, Sumsub TravelRule) exist. Selection factors: counterpart network concentration, pricing, IVMS 101 support, audit features.
Is the UK Travel Rule disproportionate for a small UK CASP?
No — the UK regime applies proportionately. The £1,000 threshold, sunrise flexibility and risk-based approach mean a small CASP can run a sustainable model with automated infrastructure rather than fully manual processing. That said, Travel Rule infrastructure (network integration, IVMS 101 generation, beneficiary verification, audit logging) requires a baseline architectural investment even for smaller firms. Third-party SaaS solutions (e.g. Legichain's Travel Rule module) materially reduce that burden.
Can a UK CASP send transfers to a Turkish KVHS-licensed exchange?
Yes, with counterparty DD: the Turkish KVHS firm's SPK registration, MLRO, AML framework should be assessed. Turkey applies its own interpretation of Travel Rule — verify the KVHS firm operates on an IVMS 101-compatible network. In a sunrise scenario (where KVHS infrastructure is incomplete) the UK CASP can proceed under risk-based judgement; documentation and risk assessment are required.
How Legichain helps
UK Travel Rule compliance requires a three-layer infrastructure: (1) messaging network integration, (2) beneficiary VASP verification workflow, (3) threshold and sunrise risk management. Legichain's Travel Rule infrastructure delivers JMLSG Sector 22-aligned messaging, IVMS 101 generation and parsing, and major network integrations (TRP, Sygna, TRISA) through one API. Beneficiary wallet VASP detection runs through our blockchain AML module; counterparty DD is automated against sanctions and adverse media layers in our AML screening API. With a single customer-jurisdiction setting you can run UK (£1,000), EU (€0) and Turkey policies in parallel. See our crypto exchange solutions page for integration architecture detail.
Next steps
- UK financial regulation guide — UK regulatory architecture and cluster pillar.
- FCA cryptoasset registration guide — registration process.
- FATF Travel Rule guide — global Travel Rule framework.
- Travel Rule by jurisdiction — Turkey, EU, UK side by side.
- IVMS 101 standard explained — message structure.