Travel Rule Architecture Build: From Scratch (2026)

There is no shortage of Travel Rule writeups in 2026. Almost all of them compare vendors. Notabene versus Sumsub versus Sygna versus Veriscope versus OpenVASP. Pricing tiers, counterparty coverage, IVMS101 conformance, UI screenshots. Useful, but not the build. The build is the four-layer operating stack that has to be in place before the vendor question becomes the right question at all.

Picking a Travel Rule vendor without first architecting the stack is the single most common failure mode we see in CASPs preparing for MiCA go-live. The vendor decision is Layer 2 of four. Layers 1, 3 and 4 — the protocol routing, the policy decision tree, and the exception handling — sit on either side of it and determine whether the vendor you pick can actually do the job you need it to do. Choose vendor first, and you will spend the next twelve months retrofitting a stack around a tool that is shaped wrong for the architecture.

This guide is the architecture build. It treats Travel Rule as the Travel Rule operating stack — four layers, each with its own deliverables, supervisor evidence, failure modes, and integration sequence. It is written for the people doing the build: CASP CTOs, MLROs, Heads of Compliance, and the integration teams who will live with the system after the consultants leave.

The Travel Rule is, in concept, simple. FATF Recommendation 16 — set out in the FATF Updated VASP Guidance¹^[1] — requires the originator VASP to obtain, hold and transmit originator and beneficiary information when value moves across VASPs. The EU implementation under the Transfer of Funds Regulation goes further: no de minimis threshold for crypto transfers (fiat keeps its €1,000 floor), and originator-and-beneficiary information required on every transfer regardless of amount.

The architecture is hard because the simple rule meets a fragmented protocol landscape, an incomplete counterparty graph, and a population of self-hosted wallets that don't sit on the other end of any VASP-to-VASP message. The Transfer of Funds Regulation²^[2] applied from 30 December 2024 — concurrent with MiCA³^[3] — and has been live for over a year. Most of the supervisory findings we are now seeing are not vendor failures. They are architecture failures that vendor choice could not have rescued.

A vendor-first build asks: which provider has the most counterparties? An architecture-first build asks four questions in order. Which protocols do we need to speak, and how do we route between them? Which vendor gives us the counterparty coverage and SLA the protocol map requires? What policy — thresholds, decision trees, data-minimisation rules — do we hardcode into the system? And how do we handle the exceptions — self-hosted wallets, sunrise jurisdictions, batched transactions, identity-verification edge cases — that the vendor will not handle for us?

The supervisor — whether it is the EBA, ESMA, or a national competent authority during a MiCA CASP authorisation review — does not ask which vendor you use. The supervisor asks which protocols you support, what your policy framework is, how you handle self-hosted wallet receipts above the AMLR threshold, what your sunrise-jurisdiction handling looks like, and whether your evidence pack can demonstrate a defensible end-to-end process. The vendor is a means; the architecture is the deliverable.

Each layer has a single owner, a clear deliverable, and a specific piece of evidence the supervisor will want during inspection. Confusing layers is how Travel Rule programmes drift into a pile of vendor configuration that nobody can explain end-to-end.

The protocol layer is the data-and-transport substrate. There is no single Travel Rule protocol; there is a small zoo of them, each with its own message format, transport, and counterparty-discovery model. The four that matter in 2026:

• IVMS101 — the InterVASP Messaging Standard, the canonical data schema. Not a transport; a payload format. Every credible Travel Rule protocol carries IVMS101 inside its envelope. If your stack does not emit and consume strict IVMS101, you are not compliant in any practical sense.

• TRP (Travel Rule Protocol) — an open HTTPS-based protocol developed by a working group of major VASPs. Synchronous request/response. Pragmatic, widely adopted in EEA and UK CASP cohorts.

• Sygna BridgeMessaging — a closed-network protocol operated by Sygna; high counterparty coverage in APAC and meaningful presence in EEA. Vendor-bound but mature.

• OpenVASP — an open protocol with decentralised counterparty discovery via Ethereum smart contracts. Lower adoption than TRP in 2026 but architecturally interesting and used by a specific subset of Swiss and EEA VASPs.

The protocol-layer decision is not which protocol to support — it is how to route between them. A counterparty VASP on Sygna cannot receive a TRP message; a counterparty on OpenVASP cannot receive a Sygna message. Most Travel Rule vendors offer multi-protocol routing — they translate between protocols on the wire — but the routing rules, fallback logic, and message reconciliation across protocols are still the originator CASP's responsibility. Deliverable: a routing map keyed by counterparty VASP identifier, with primary and fallback protocols specified.

With the protocol map in hand, vendor selection becomes a tractable question. The criterion is not market share; it is counterparty coverage against your actual counterparty graph. A vendor with 1,800 counterparties is useless to you if the 40 VASPs you actually exchange value with are mostly on a competing network.

The vendor cohort in 2026 is small and named. Notabene runs a multi-protocol network with strong TRP coverage and a deep counterparty graph across EEA, UK and US cohorts. Sumsub Travel Rule Solution bundles Travel Rule into a broader KYC/AML stack, attractive to CASPs that want one vendor for identity and Travel Rule. Sygna runs the largest APAC counterparty graph and is essential if your counterparty graph leans East. Veriscope (by Shyft) and OpenVASP round out the named alternatives. Most live CASPs end up using more than one vendor, or one vendor with multi-protocol routing inside it, to span the counterparty graph they actually have.

Vendor diligence is operational. Test the counterparty match rate against your real transfer history — what percentage of the past 90 days of outgoing volume would have hit a known counterparty? Test the sunrise handling — what does the vendor do when the counterparty is in a jurisdiction without a Travel Rule regime? Test the self-hosted wallet path — what does the vendor do when there is no counterparty VASP? Deliverable: a signed counterparty-coverage report against your actual transfer graph, not a generic network-size claim.

Policy is the layer where most CASPs underinvest. The vendor will execute whatever message you ask it to send, but the decisions about when to send, what data to populate, and how to react to a counterparty response are policy, not vendor configuration. The policy framework runs against the AMLR⁴^[4] and the TFR — TFR Articles 16 and 17 govern crypto-asset transfer information; AMLR provides the surrounding CDD and EDD rules.

The policy deliverable is a written Travel Rule Policy document covering: in-scope transfer types (every crypto-asset transfer, no de minimis), the required originator and beneficiary data fields (full IVMS101 dataset), the data-minimisation principle (collect only what the regulation requires; do not over-share), the decision tree for each counterparty class (registered VASP in a Travel Rule jurisdiction, registered VASP in a sunrise jurisdiction, unregistered VASP, self-hosted wallet, internal-transfer-on-same-platform), and the supervisory escalation triggers when counterparty data is missing or inconsistent.

Two policy decisions matter more than the others. First, hold-or-release on missing counterparty data. TFR Article 17 lets the beneficiary CASP determine its own approach when originator information is missing, but the originator's policy must specify whether it ever sends a transfer without complete information, under what conditions, and with what compensating controls. Second, counterparty due diligence on the receiving VASP — is the counterparty a credible regulated entity, or are you potentially sharing originator information with a sanctioned or unregulated entity? The policy must specify the diligence floor before a counterparty is added to the routing map.

The exception layer is where the architecture stops being clean. It is also where most supervisor findings cluster. Three exception classes need their own runbooks: self-hosted wallets, sunrise jurisdictions, and batched or aggregated transactions.

Self-hosted-wallet handling is set out separately below — it is the single largest exception class by volume. Sunrise-jurisdiction handling is the second largest and the source of most policy ambiguity. Batched transactions — where a CASP aggregates many customer transfers into a single on-chain transaction, or where the counterparty does — need an explicit message-format and reconciliation rule, because a single on-chain transaction may correspond to multiple Travel Rule messages on either side of the wire. Each exception class requires a deliverable: a documented runbook, an evidence-capture flow, and a periodic supervisory-evidence pack.

A sunrise jurisdiction is one that has not yet implemented FATF Recommendation 16 in domestic law, or has implemented it but with a different effective date, scope, or threshold. The counterparty VASP in that jurisdiction may not be obliged — or technically able — to send or receive Travel Rule messages. The originator CASP, however, is obliged by its own jurisdiction's law to obtain and transmit the information.

The sunrise problem is not a fringe edge case. As of 2026, FATF's own Targeted Update reporting consistently shows that a substantial minority of jurisdictions globally have not yet effectively implemented the Travel Rule, with implementation lagging in regions where some of the highest-volume counterparty VASPs are domiciled. Any EEA CASP with global counterparties will have meaningful sunrise exposure.

The architecture response has three components. First, a jurisdictional sunrise list — a maintained register of jurisdictions where Travel Rule is not yet effective, refreshed against FATF and national supervisor publications. Second, a per-jurisdiction escalation rule — does the CASP send the originator information unilaterally and accept that the counterparty cannot receive it formally? Does it hold the transfer pending alternative information exchange? Does it block transfers above a risk-based threshold to sunrise counterparties? Third, an evidence trail — for every sunrise-jurisdiction transfer, the system must capture which jurisdiction was identified, which compensating control was applied, and the senior compliance officer who approved the policy default.

The supervisor does not expect a CASP to refuse to transact with sunrise counterparties. The supervisor expects the CASP to have made a deliberate, documented, risk-based decision about how to handle them and to have evidence that the decision is being applied consistently. The failure mode is not transacting with a sunrise counterparty; the failure mode is doing so without a policy and without a trail.

The AML Regulation introduces explicit obligations on CASPs in respect of transfers to and from self-hosted wallets — wallets controlled by the customer rather than by another regulated entity. AMLR Articles 79 and 80 sit alongside TFR Article 14a in setting out what the CASP must do when the counterparty is not a regulated VASP.

The core threshold is €1,000. Above that threshold, the CASP must take risk-based measures to verify that the self-hosted wallet is owned or controlled by the customer involved in the transfer. That verification can be performed through several technical methods — micro-deposit / Satoshi test, cryptographic message-signing from the wallet's private key, screenshots within the customer's own custodial app, or address-attribution analytics — but the choice must be documented in the policy framework and applied consistently.

Below €1,000, the verification obligation is lighter, but the CASP still has CDD obligations on the customer and a residual responsibility to apply address-screening and risk monitoring against sanctions lists and known illicit address clusters. Blockchain analytics from providers like Chainalysis, Elliptic or TRM Labs is the workhorse here, but it does not replace the verification step above €1,000.

The architecture implication is that self-hosted wallet flows need their own verification engine — not a Travel Rule message. A Travel Rule vendor is the wrong tool here; what is needed is a verification workflow inside the CASP's customer-facing flow that captures the proof, attaches it to the transfer record, and gates the transaction until verification is complete. This is policy-and-engineering work, not vendor work.

A common confusion: IVMS101 is not a protocol, it is a schema. The three protocols below — TRP, Sygna, OpenVASP — each carry IVMS101 payloads with different transports and counterparty-discovery models.

The practical 2026 architecture for most EEA CASPs is: IVMS101 as the canonical schema, TRP as the primary protocol, Sygna as a secondary protocol for APAC counterparties, OpenVASP only if a specific counterparty requires it. A vendor that bridges all three protocols on the wire is the path of least operational pain — but only after the counterparty graph and the routing map have been built.

A realistic build sequence for a CASP starting from zero is a 12–16 week programme with five named checkpoints. Compressing this aggressively is possible — and is exactly how Travel Rule programmes end up with the architecture failures the supervisor will later find.

1. 1

   Weeks 1–2 — Counterparty graph & protocol map. Pull 90 days of outbound transfer history. Identify the top 40 counterparty VASPs by volume. Map each one to its Travel Rule protocol. Output: protocol coverage matrix.

2. 2

   Weeks 3–5 — Vendor selection & contracting. RFP against the protocol map. Test counterparty match rate. Negotiate SLA on message-delivery latency, counterparty onboarding, and sunrise handling. Output: signed vendor agreement.

3. 3

   Weeks 4–8 — Policy framework. Draft Travel Rule Policy. Build decision trees. Run policy through MLRO and board approval. Output: approved Travel Rule Policy and operational runbooks.

4. 4

   Weeks 6–12 — Engineering integration. Integrate vendor API. Build the self-hosted-wallet verification engine. Build the sunrise-jurisdiction routing. Build evidence-capture and audit logging. Output: end-to-end working pipeline in staging.

5. 5

   Weeks 13–16 — UAT, parallel run, go-live. UAT with named counterparties. Two-week parallel run with manual fallback. Go-live with senior compliance sign-off and a 30-day post-go-live evidence pack to the board.

Five failure modes recur across the supervisory findings we have seen on Travel Rule programmes since TFR applied at the end of 2024.

• Vendor-first architecture. Picking a Travel Rule vendor before mapping the protocol graph. Result: a tool that does not cover the actual counterparty population, and a retrofit programme later.

• No sunrise policy. Treating every counterparty as Travel-Rule-compliant. Result: transfers proceeding to sunrise counterparties without documented escalation, and a supervisor finding on inconsistent handling.

• Self-hosted wallet as a Travel Rule exception. Trying to send Travel Rule messages to addresses with no counterparty VASP. Result: misclassified flows, missing AMLR Article 79 verification evidence, and a fundamental architecture gap.

• Over-collection of originator data. Sharing more PII than the TFR requires because the vendor template offered more fields. Result: GDPR exposure and counterparty pushback on data-minimisation grounds.

• No evidence pack. The system works in practice but the supervisor cannot be shown end-to-end evidence — which messages went out, which were rejected, which were held, which counterparties failed, which sunrise routes were used, which self-hosted wallet verifications were captured. Result: a working programme treated as a non-working one because it cannot be evidenced.

Most of these failures are programme-management failures, not technical ones. Travel Rule, like KYC vendor selection, sits at the intersection of compliance, engineering, and operations — see our KYC vendor selection guide for the parallel architecture in the customer-identity domain. Both fail in the same way when one function dominates the design.

Yes. Under the Transfer of Funds Regulation, originator and beneficiary information must accompany every crypto-asset transfer regardless of amount. The €1,000 de minimis that applies to fiat does not apply to crypto. A €5 crypto transfer between two EEA CASPs is in scope.

€1,000 is the threshold at which a CASP must take risk-based measures to verify that a self-hosted wallet is owned or controlled by the customer to whom the transfer relates. Below €1,000 the verification obligation is lighter but address-screening and CDD still apply. This threshold is distinct from the Travel Rule itself, which has no de minimis for crypto.

No. The vendor provides the protocol layer and message-routing infrastructure. The policy framework, exception runbooks, and supervisor evidence pack remain the CASP's responsibility. Outsourcing the protocol layer is acceptable; outsourcing the policy decisions is not.

The CASP must still fulfil its own jurisdiction's obligation to obtain and attempt to transmit originator information. The policy should specify whether the CASP unilaterally sends the information, holds the transfer pending alternative information exchange, or applies a transactional limit. The choice is the CASP's, but it must be documented, applied consistently, and evidenced for each affected transfer.

The TFR provides the legal basis for the data transmission, so the sharing itself is lawful under GDPR Article 6(1)(c) (legal obligation). The risk is on over-collection — sending more personal data than the TFR requires — and on counterparty handling once the data is shared. Data minimisation must be hardcoded into the Travel Rule Policy and the vendor configuration.

• AML Compliance for Crypto Firms: What the 6AMLD Requires (2026) — the broader AML framework that the Travel Rule architecture sits inside.

• KYC Vendor Selection for a Crypto Exchange — parallel architecture-first approach to identity vendor selection.

• AMLR Readiness 12-Month Roadmap — wider AMLR programme that includes self-hosted wallet rules under Articles 79–80.

• MiCA Compliance Guide for CASPs (2026) — full CASP authorisation walkthrough where Travel Rule sits as one workstream.

• Compliance Advisory — hands-on Travel Rule architecture, policy and evidence-pack build.

The Travel Rule is now over a year live under the TFR and AMLR, and supervisors have moved past the implementation grace period into substantive inspection. The CASPs whose programmes hold up under that scrutiny in 2026 and 2027 are not the ones with the most expensive vendor. They are the ones that built the architecture before they bought the tool — four layers, four owners, four evidence packs — and treated the vendor as a means rather than the deliverable.