Travel rule implementation: an EU and UK action plan

To implement the Travel Rule across UK and EU operations, treat it as a four-track project: scope, data, transmission and oversight. The realistic target is to complete first-pass scoping and a messaging pilot within 90 days.

That single framing solves the problem compliance teams keep running into: treating the Travel Rule as a data-format exercise rather than a governance one. It is both. Get the scope wrong and you either over-collect (a GDPR headache) or leave transfers unprotected (a supervisory finding waiting to happen).

Before anything else, read four documents in this order:

• FATF Recommendation 16 and its Interpretive Note — the global baseline every other rule builds on.
• Regulation (EU) 2023/1113 (the recast Transfer of Funds Regulation, or TFR) — binding law for EU-based PSPs and CASPs, with a stricter field set than FATF's floor.
• EBA Guidelines on information requirements — the operational detail on missing-data timelines that the TFR itself doesn't spell out.
• FCA statements and FinCEN guidance — for UK expectations and, where you have US counterparties, the older but still active American threshold.

Get the four tracks moving in parallel and the payoff is concrete: fewer enforcement findings at your next audit, cleaner cross-border settlement because counterparties stop rejecting incomplete payloads, and lower ongoing headcount cost once verification and enrichment run through automation rather than manual queues.

Key Takeaways

Effective travel rule implementation depends on treating scope, data, transmission and oversight as one coordinated project rather than four separate workstreams.

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Table of Contents

• What travel rule implementation actually requires
• Who has to comply, and which transfers are in scope?
• Which regulations and supervisory guidance actually govern this?
• What data has to travel with each transfer?
• How should policies handle missing or incomplete data?
• How do you actually transmit travel rule data?
• What does a realistic implementation roadmap look like?
• What will supervisors actually check?
• How do GDPR and recordkeeping obligations interact?
• What are the most common implementation problems?
• A one-page checklist you can use today
• How Aithea supports your travel rule programme
• Sources
• FAQ

What travel rule implementation actually requires

The Travel Rule is FATF Recommendation 16's requirement that originator and beneficiary information travel alongside a funds or crypto-asset transfer, so the receiving institution can screen it the same way it would screen a customer sat in front of it. It sounds simple. It has taken the industry the best part of a decade to operationalise, largely because virtual asset service providers (VASPs) didn't exist as a regulated category when the rule was first drafted for wire transfers.

Three developments make 2024 to 2026 the period where implementation stopped being optional:

• Regulation (EU) 2023/1113 applied from 30 December 2024, extending Travel Rule obligations to crypto-asset transfers across the EU with no de minimis threshold — every transfer, regardless of size, needs the data attached.
• The EBA's final Guidelines became applicable the same date, with a compliance deadline of 27 November 2024, giving supervisors a concrete yardstick for missing-data handling.
• The TFR's application date was deliberately aligned with MiCA, so any firm seeking CASP authorisation is now solving licensing and Travel Rule readiness as one project rather than two.

A quick number worth sitting with: by 2025, 85 of 163 surveyed jurisdictions had passed Travel Rule legislation, according to FATF's targeted update. Just over half the world has a rulebook. The rest is exactly why the industry still talks about the "Sunrise Issue" — the gap where a compliant sender has no compliant counterparty to send data to.

That gap matters operationally. It means your policy can't just say "transmit the data." It has to say what happens when the receiving VASP in a jurisdiction with no legislation simply can't process what you send. FATF's own best-practice guidance recommends jurisdictions build risk-based mitigations for exactly this scenario, and your firm needs the same logic at operational level, not just at policy level.

The EU's no-de-minimis stance is the detail that surprises firms migrating from traditional payments compliance, where small-value thresholds are common. Under the TFR, a €10 crypto transfer carries the same data obligation as a €10 million one.

Who has to comply, and which transfers are in scope?

Scope mapping trips up more compliance teams than any technical question, largely because the terminology shifts between regimes. Get the entity and transfer taxonomy wrong at the start and every downstream policy inherits the error.

The core roles compliance teams need to map onto their own business lines:

• VASP / CASP (Virtual Asset Service Provider / Crypto-Asset Service Provider) — any entity exchanging, transferring or custodying crypto-assets on behalf of customers. CASP is the MiCA-era term used in the EU; VASP remains the FATF and global default.
• PSP (Payment Service Provider) — banks, e-money institutions and payment institutions handling fiat transfers under the traditional Travel Rule regime.
• Intermediary PSP / Intermediary CASP — any entity sitting between originator and beneficiary institutions in a payment chain, with narrower obligations to pass on data received rather than to source it.
• Correspondent institutions — relevant mainly for cross-border fiat flows, where chained intermediaries multiply the number of parties that must retain and forward data correctly.

Thresholds differ by regime, and this is where firms trip themselves up if they assume one number applies everywhere. FinCEN's rules set a USD 3,000 threshold for US fiat transmittals, a figure dating from the pre-crypto Bank Secrecy Act framework. The EU applies no de-minimis to crypto-asset transfers under the TFR. The UK's own position tracks FATF's baseline but supervisors expect firms to justify any threshold they apply through risk assessment rather than defaulting to a foreign number because it's convenient.

Common exclusions and edge cases worth flagging in your scoping document:

• Transfers between two accounts held by the same customer at the same institution are typically out of scope, though document the reasoning rather than assuming it.
• Unhosted (self-custodied) wallets sit outside the VASP-to-VASP data chain entirely, which means your counterparty due diligence needs a separate track for assessing the risk of transfers to and from wallets with no institutional counterpart to exchange data with.
• Batch or aggregated transfers can qualify for adjusted handling in some regimes, but only where the underlying originator data is still retrievable on request.

Which regulations and supervisory guidance actually govern this?

Five documents carry real weight here, and they don't all carry the same legal force, which is worth understanding before you draft a single policy line.

FATF Recommendation 16 and its Interpretive Note set the global standard but are not directly enforceable law in themselves; they bind countries to legislate, not firms to comply directly. Treat this as the floor, not the rulebook you cite to your board.

Regulation (EU) 2023/1113 is directly applicable EU law, no transposition required. Article 14(1) is the one to read first: it lists the originator field set for crypto-asset transfers, including name, distributed ledger address or account number, and either a physical address, official identification number, or date and place of birth. Article 14(2) mirrors this for beneficiary data.

The EBA's Guidelines fill the gap the TFR leaves open: what happens when data is missing. This is where the specific working-day deadlines live, and it's the document your operational playbook should reference most heavily.

FCA statements on Travel Rule expectations track the FATF standard closely but layer in the FCA's characteristic emphasis on senior management accountability and evidenced risk assessment, so UK firms should read FCA guidance for tone as much as content.

FinCEN's guidance remains the reference point for any firm with US-facing payment rails, and its Q&A document is unusually specific about intermediary obligations, worth reading even for EU-only firms because it shows how a mature Travel Rule regime resolves ambiguity in practice.

• Read the TFR first if your business is EU crypto-asset transfers.
• Read the EBA Guidelines first if you already have TFR obligations mapped and need operational deadlines.
• Read FCA statements first if you're UK-only and haven't yet decided your risk-based threshold approach.

What data has to travel with each transfer?

The field set is the part of Travel Rule implementation most likely to get outsourced to engineering without compliance sign-off, which is a mistake, because the fields differ meaningfully by regime and getting them wrong means rebuilding your data schema mid-project.

The EU set is stricter than the FATF floor by design, and firms building for global operations generally find it easier to build to the EU standard and treat other regimes as subsets, rather than the reverse.

Verification expectations differ from collection expectations. You must collect the full field set on every transfer; you don't necessarily need to re-verify identity on every single one if the customer is already known and verified through existing KYC. Acceptable evidence for verification typically mirrors your existing customer due diligence standard: government-issued ID, proof of address, or reliance on a verified third-party attestation where your risk appetite allows it.

Formatting matters more than most compliance teams expect. IVMS101 has become the de facto industry standard for structuring these fields for machine-to-machine exchange between VASPs, even though it isn't a FATF instrument itself, simply an industry-built schema that most Travel Rule solutions now speak natively.

Pro Tip: Build your internal data model to IVMS101 field names from day one, even for fiat transfers that don't strictly require it. Retrofitting a schema after your crypto desk goes live on an IVMS101-compatible provider is far more expensive than aligning up front.

How should policies handle missing or incomplete data?

This is where most Travel Rule programmes either work smoothly or fall apart in an audit. A clean field-mapping exercise means nothing if your team has no documented logic for what to do when the beneficiary VASP sends back a transfer missing three required fields.

A workable policy needs five components, in this order:

1. Scope statement. Which transfer types, entities and thresholds trigger Travel Rule obligations for your business, cross-referenced to the specific regulation (TFR, FATF baseline, FinCEN) that applies to each flow.

2. Roles and accountability. Name who owns the decision to execute, suspend, reject or return a transfer with incomplete data. This should not sit with a junior analyst alone; the EBA Guidelines expect a documented decision trail, which implies someone with authority signed off.

3. Data obligation and verification standard. The field set you collect (see the previous section) and when re-verification of identity is triggered, tied to your existing risk-based approach.

4. Exception handling and timelines. This is the operational core. The EBA's Guidelines recommend requesting missing information within a few working days for intra-Union transfers and a longer working-day period for transfers originating outside the Union, with extensions permitted in genuinely complex correspondent chains.

5. Recordkeeping and audit trail. Every decision to proceed, suspend or reject needs a timestamped record, not a verbal sign-off buried in a chat channel.

The decision logic itself typically resolves to four outcomes:

1. Execute — all required fields present and consistent; process normally.
2. Suspend and request — fields missing but the counterparty relationship is otherwise low-risk; request the missing data within the EBA's recommended window and hold the transfer pending response.
3. Reject — the counterparty fails to respond within the deadline, or the missing fields relate to high-risk indicators (sanctioned jurisdiction, PEP exposure, prior STR history).
4. Return — funds already received but data arrives incomplete after the fact; return to originator with documented reasoning.

Escalation matters here as much as the decision tree. A pattern of missing data from a specific counterparty VASP should trigger a review of that relationship, not just repeated one-off suspensions. Build explicit integration points between your Travel Rule exception log and your SAR/STR filing process, so a transfer that gets rejected for missing data and also shows other red flags doesn't fall through a gap between two separate systems. The same applies to sanctions screening: Travel Rule data enrichment should feed your screening engine, not sit in a parallel silo that screening never sees.

Pro Tip: Treat every missing-data suspension as a mini case file, even if it resolves within hours. Supervisors reviewing your programme will ask to see a sample of these, and a clean audit trail across dozens of resolved cases is worth more than a policy document alone.

Automation genuinely changes the economics of this workflow. Manually chasing missing beneficiary data across dozens of correspondent VASPs doesn't scale, and it's precisely the kind of repetitive, rules-based decision that AI-assisted triage can accelerate, flagging which suspended transfers need human review versus which meet a pattern automatically resolvable within policy. Aithea's work on integrating AI into AML frameworks covers how this triage layer typically gets built without displacing the human sign-off the EBA Guidelines expect.

How do you actually transmit travel rule data?

Three architectural models dominate the market, and the choice affects everything from your vendor contract to your incident response plan.

Direct API / peer-to-peer connections between your systems and each counterparty VASP offer the most control but scale poorly. If you transact with 200 counterparty VASPs, that's potentially 200 individual integrations to build, test and maintain, each with its own authentication and payload quirks.

Messaging hubs and brokered services sit between VASPs, translating and routing Travel Rule payloads so you integrate once with the hub rather than with every counterparty individually. This is where most mid-sized firms land, trading some cost for a dramatic reduction in integration overhead.

Industry bridges connect otherwise-incompatible hubs, addressing exactly the Sunrise Issue problem: your provider speaks one protocol, your counterparty's provider speaks another, and the bridge translates between them so neither side has to abandon its existing vendor relationship.

IVMS101 underpins all three models as the common data schema, meaning field mapping and payload validation become the genuine engineering work, not the transport layer itself. Get your field mapping wrong at this stage and you'll pass IVMS101-shaped messages that fail semantic validation at the receiving end, a subtler and more frustrating failure than an outright rejected connection.

Adoption data illustrates why interoperability, not raw participation, is now the bottleneck: 85 of 163 jurisdictions have passed legislation, but legislation alone doesn't guarantee your specific counterparty runs a technically compatible messaging stack.

Security and logging requirements deserve equal weight to the messaging layer itself, because you're now transmitting personal identifying data across institutional boundaries at volume:

• Encryption in transit and at rest for every payload containing originator or beneficiary personal data, no exceptions for "low-risk" transfers.
• Key management with clear rotation policy and access restricted to systems, not individuals, wherever technically feasible.
• Immutable logging of every transmission attempt, success, failure and manual override, timestamped and retained per your recordkeeping policy.
• Interoperability testing before go-live with at least two counterparty types: a hub-based counterparty and a direct API counterparty, to surface format assumptions your own team didn't know it was making.

A pragmatic interoperability checklist before production cutover: confirm your provider's IVMS101 field mapping against the TFR Article 14 list line by line. Run a negative-path test sending a deliberately incomplete payload and confirm your missing-data workflow triggers correctly. Verify your logging captures enough detail to reconstruct a decision six months later without needing to ask the analyst who made it. Test failover to a manual process if your primary transmission channel goes down mid-transfer.

Pro Tip: Don't treat the technical pilot and the compliance sign-off as sequential. Run your first interoperability test with compliance reviewing the actual payloads in real time. Fields that look fine in a data dictionary sometimes reveal gaps only when you see a live, populated message.

The EBA's own guidance acknowledges that full technical capability won't arrive everywhere overnight, permitting temporary derogations with compensating measures for firms facing genuine technical limitations, originally bounded to 31 July 2025 in some cases. If your firm is relying on any derogation, document the compensating controls as rigorously as you would a fully automated solution, because supervisors will ask what stood in for the missing automation.

What does a realistic implementation roadmap look like?

A Travel Rule programme that tries to do everything simultaneously usually delivers nothing on time. Sequencing the work across three horizons keeps scope honest and gives you defensible progress markers if a supervisor asks where you are mid-project.

Days 1 to 90: scoping and pilot.

1. Map every transfer type your business handles against the applicable regime (TFR, FATF baseline, FinCEN) and confirm which flows are genuinely in scope.
2. Draft the core policy: scope, roles, data fields, missing-data decision logic, and recordkeeping standard.
3. Shortlist two to three Travel Rule technology providers and run a technical proof-of-concept with your highest-volume counterparty type.
4. Complete a field-mapping exercise against IVMS101 and validate against a small batch of live-format test transfers.

Days 91 to 180: production build and controlled rollout. 5. Integrate the chosen transmission model into your transaction monitoring and sanctions screening systems, not as a bolt-on. 6. Train front-line and compliance staff on the missing-data decision tree, with named escalation owners. 7. Run production traffic through a limited counterparty set, with compliance reviewing a sample of every suspended or rejected transfer weekly. 8. Formalise your audit trail and reporting so a supervisor request can be answered within days, not weeks.

Days 181 to 360: full rollout and governance handover. 9. Extend to full counterparty coverage, including lower-volume or higher-risk relationships deprioritised in the pilot. 10. Hand governance from the project team to business-as-usual compliance ownership, with a defined review cadence (quarterly is typical) to reassess thresholds and counterparty risk.

Vendor selection deserves its own checklist, separate from the general procurement process, because Travel Rule providers vary enormously on dimensions generic RFP templates don't capture:

• Interoperability: does the vendor connect to industry bridges, or only within its own closed network of subscribers?
• IVMS101 compatibility: native support, or a proprietary format requiring translation?
• Security and data residency: where is data processed and stored, and does that align with your regulatory obligations if you operate across multiple jurisdictions?
• SLA and audit logging: what response time guarantee exists for missing-data requests, and can you export a full audit log independently of the vendor's dashboard?
• Regulatory change support: does the vendor track EBA, FCA and FATF updates and adjust field requirements proactively, or does that burden sit entirely with your team?

Running this evaluation manually across several shortlisted vendors is exactly the kind of structured, criteria-heavy comparison that benefits from a dedicated navigator rather than a spreadsheet built from scratch. Aithea's Heliolus platform was built for precisely this kind of technology-selection exercise.

Pro Tip: Score vendors against your own weighted criteria before any sales conversation, not after. A vendor's own RFP response template will always emphasise their strengths; scoring blind first keeps your comparison honest.

What will supervisors actually check?

Supervisory reviews of Travel Rule programmes tend to follow a predictable pattern, and knowing it in advance is the cheapest preparation available to a compliance team.

Expect a supervisor to ask for: your written policy and evidence it's actually followed (not just filed); a sample of transfers showing the full data chain, including any suspended or rejected cases; technical logs proving transmission attempts and outcomes; and, for cross-border flows, evidence of how you assessed counterparty jurisdictions with weaker Travel Rule regimes (a memorandum of understanding or equivalent risk assessment, often referred to informally as an MEP in cross-border correspondent contexts).

Common findings in early audits include policies that describe an ideal process the technology can't actually support yet, missing-data logs with no documented decision rationale, and gaps between the Travel Rule exception process and the firm's separate SAR/STR workflow. Each is fixable quickly once identified, but each also signals to a supervisor that the programme was built for the audit rather than for daily operation.

FATF's supervisory guidance increasingly treats Travel Rule readiness as a licensing gate rather than a post-authorisation add-on, meaning firms seeking new CASP authorisation under MiCA should expect readiness questions during the licensing process itself, not after approval.

Pro Tip: Keep a standing "supervisor pack" updated monthly, not assembled reactively when a request lands. It should contain your current policy version, a sample of the last quarter's exception cases, and your latest technical log export.

How do GDPR and recordkeeping obligations interact?

Transmitting originator and beneficiary personal data across institutional and sometimes national borders sits in obvious tension with GDPR's data minimisation principle, and firms need a documented lawful basis rather than treating the Travel Rule as an automatic override.

The lawful basis in most EU jurisdictions rests on legal obligation, since Regulation (EU) 2023/1113 directly requires the data transfer. That doesn't remove the need for a data protection impact assessment where processing is large-scale, nor does it excuse over-collection beyond what the TFR field set actually requires.

Retention periods follow the FATF baseline of five years from the date of the transaction, mirrored in FinCEN's own five-year retention requirement for US-facing flows. Confirm your local retention rule doesn't extend this further; some national AML transpositions do.

Practical controls worth building in from the start: pseudonymise Travel Rule data at rest wherever the transmission protocol allows it without breaking the receiving VASP's ability to screen; restrict field-level access so only staff handling exception cases can see full unredacted personal data; and log every access event to the same standard as the transmission log itself.

Pro Tip: Run your GDPR lawful basis assessment alongside your Travel Rule field mapping, not afterwards. Retrofitting a data protection justification onto an already-built data flow is far harder than designing both together.

What are the most common implementation problems?

Three problems account for the bulk of Travel Rule remediation work compliance teams end up doing after go-live.

Interoperability gaps between providers. Your chosen vendor speaks IVMS101 natively; your counterparty's legacy system doesn't. Bridging this usually means selecting a provider with proven bridge connections to multiple hubs rather than assuming universal compatibility, and building a fallback manual process for counterparties you can't yet connect to automatically.

Poor data quality at onboarding. Fields collected during KYC years ago often don't map cleanly onto Travel Rule requirements, particularly around structured address formats and DLT address capture. The fix is a remediation playbook: prioritise re-collection for active high-volume customers first, use enrichment services for fields that can be verified against existing records, and build an explicit fallback procedure (manual review, not automatic rejection) for accounts where data genuinely can't be completed quickly.

Unhosted wallets and mismatched regimes. When the receiving party is a self-custodied wallet with no institutional counterpart, or operates in a jurisdiction with a materially weaker Travel Rule regime, your standard workflow doesn't apply. Build a separate, explicitly risk-based assessment track for these transfers rather than forcing them through a process designed for VASP-to-VASP exchange.

A one-page checklist you can use today

Print this, or drop it into your AML manual as a working reference during build:

• Scope: transfer types mapped, thresholds confirmed per regime, exclusions documented.
• Data: field set built to EU TFR standard (superset of FATF and US requirements), IVMS101-mapped.
• Transmission: provider selected, interoperability tested against at least two counterparty types, encryption and logging confirmed.
• Privacy: lawful basis documented, retention set to five years minimum, access controls in place.
• Monitoring: missing-data workflow integrated with sanctions screening and SAR/STR processes.
• Governance: policy signed off, escalation owners named, supervisor pack maintained monthly.

Technology-first design, compliance-led decisions

The instinct in a lot of Travel Rule programmes is to let the technology vendor's data model define the compliance policy. That's backwards. Compliance needs to define the control objectives, the missing-data thresholds, the escalation triggers, before a single API contract gets signed, otherwise you end up rebuilding your policy around whatever the vendor happened to build first.

Where technology genuinely earns its place is in scale, not judgment. AI-assisted triage can sort thousands of transfers into "clean," "needs review" and "high-risk escalation" faster and more consistently than a manual queue ever will, freeing analysts to spend their time on the cases that actually need a human decision. The mistake is expecting automation to make the judgment call itself.

Pro Tip: Run your engineering pilot and your change management plan on the same timeline, not sequentially. Staff trained on the new missing-data workflow only after the system goes live will default to old habits under pressure.

How Aithea supports your travel rule programme

Aithea exists for exactly the gap most compliance teams hit halfway through a Travel Rule build: knowing what good looks like on paper, but needing a structured way to evaluate whether a specific vendor's IVMS101 mapping, security posture and SLA actually hold up against Regulation (EU) 2023/1113 and FCA expectations before you commit budget to it.

Aithea's work spans three practical capabilities for teams in this position. Readiness reviews assess where your current policy, data model and technical architecture stand against the TFR and EBA Guidelines before a supervisor does it for you. RFP and vendor scoring applies a structured, weighted evaluation across interoperability, data residency, audit logging and regulatory change support, rather than relying on vendor sales decks. AI-enabled process integration connects your Travel Rule exception handling into existing transaction monitoring and sanctions screening, so the two don't run as disconnected silos.

If your team is somewhere between "we've read the regulation" and "we've picked a vendor," a short readiness diagnostic is the fastest way to find the gaps that matter. Get in touch to arrange one, or explore Aithea's AML and compliance consulting services for the full scope of implementation support on offer.

Sources

• Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under Regulation (EU) 2023/1113 | EBA
• Funds “Travel” Regulations: Questions & Answers | FinCEN
• Regulation (EU) 2023/1113
• Virtual assets: Targeted update on implementation of the FATF standards on VAs and VASPs

FAQ

Is the Travel Rule mandatory?

Yes. It stems from FATF Recommendation 16 and is implemented as binding law in most jurisdictions, including the EU through Regulation (EU) 2023/1113, with no de-minimis threshold for crypto-asset transfers.

What is the UK Travel Rule?

The UK applies the FATF Recommendation 16 baseline through FCA supervisory expectations, requiring firms to justify their own risk-based thresholds rather than defaulting to another jurisdiction's figures.

What are the guidelines for the Travel Rule?

The core guidelines are FATF Recommendation 16 and its Interpretive Note globally, Regulation (EU) 2023/1113 and the EBA's Guidelines within the EU, and FinCEN guidance for US-facing transfers.

When was the Travel Rule introduced?

The original wire-transfer Travel Rule dates to the US Bank Secrecy Act framework from 1996; FATF extended the standard to virtual assets from 2019, and the EU's crypto-specific version under Regulation (EU) 2023/1113 applied from 30 December 2024.

How can Aithea help with travel rule implementation?

Aithea supports readiness reviews against the TFR and EBA Guidelines, structured vendor scoring through its Heliolus platform, and integration of Travel Rule exception handling with existing transaction monitoring systems.

Recommended

• Compliance in the Age of Automation: Trends Shaping Global Trade
• Where We'll Be This Summer.
• AITHEA | AI-Powered Compliance & Risk Consulting
• The Hidden Drama of Global Trade: When Compliance Meets Complexity