Travel Rule implementation · engineering partner
AML & Travel Rule integration,
engineered into your transfer path.
TrustChange builds Travel Rule software for EU-facing licensed VASPs, PSPs, EMIs, neobanks and banks. We engineer the canonical IVMS-101 message shape, the transfer gate, the evidence log and adapters into the vendor API you choose — Sumsub Travel Rule API, Notabene, Sygna, TRP or direct IVMS-101 messaging — as bespoke code under your brand. TrustChange is not a Travel Rule vendor; you keep the code, the evidence and the option to swap vendors without a rewrite.
- EU-based engineers
- MiCA-ready messaging
- IVMS-101 canonical shape
- GDPR-aware storage
What "Travel Rule integration" means here
Vendor Travel Rule software vs a TrustChange integration — the honest table
Most searches for Travel Rule implementation or Sumsub Travel Rule API assume the answer is a SaaS licence. We work the other way. TrustChange is not a Travel Rule vendor and does not resell one. We integrate the vendor(s) your compliance team chooses behind a canonical message shape, so the transfer path speaks one contract and your vendor mix stays your call.
Deciding whether to build or wrap what you have? Start with CTO advisory. The wider AML practice sits on compliance engineering. Case tooling: AML case management software development. Screening on the money path: AML transaction monitoring software.
| Dimension | Vendor Travel Rule SaaS | TrustChange integration |
|---|---|---|
| Model | SaaS licence + per-message fee | Adapter into your chosen vendor(s), inside your code |
| Integration | Ships inside vendor UI + webhook | Engineered into your transfer path, one canonical shape |
| Vendor lock-in | Yes — moving vendors means a rewrite | None — vendor is an adapter, swap without a rewrite |
| Evidence | Stored on vendor platform | Stored in your ledger + audit log, exportable on demand |
| Multi-vendor | Rare — usually one at a time | Multiple adapters live at once, per corridor or asset |
| TrustChange role | Not a Travel Rule vendor | Engineering partner — vendor mix stays your call |
Subsystems
Three subsystems inside every Travel Rule integration
A Travel Rule build is not one API call. It is the vendor and protocol adapter layer, the transfer-flow integration that puts the messaging step in the right place, and the evidence surface that a reviewer will actually open. We build the three together, on one plan, with one team accountable end to end.
-
01
Vendor & protocol adapters
Adapters into the Travel Rule vendor API you choose — Sumsub Travel Rule API, Notabene, Sygna, TRP or direct IVMS-101 messaging — behind one canonical interface, so the wallet or gateway does not care which vendor is behind it.
- Sumsub · Notabene · Sygna · TRP
- IVMS-101 canonical shape
- Swap vendors without a rewrite
-
02
Transfer flow integration
The Travel Rule messaging step engineered into the payment or withdrawal path — pre-flight VASP lookup, message send, response handling and hold-or-release decision under policy.
- VASP lookup + resolution
- Pre-signing gate
- Response-aware release
-
03
Evidence & operator surface
The evidence log and analyst surface: every message stored with vendor id, IVMS-101 payload, counterparty response and operator decision — plus case queues for held or ambiguous transfers.
- Message-level audit log
- Aged hold queue
- Reviewer exports
Stack
What sits behind bespoke Travel Rule software
Eight layers, one system. Every layer names an owner, a control and a piece of audit evidence — nothing is left implied under the "Travel Rule" label.
Delivery patterns and evidence: how we deliver. Wallet-side custody: wallet and custody engineering. Payout-side controls: AML compliance for payment platforms. Crypto-specific AML: crypto AML compliance software.
| Layer | What we build |
|---|---|
| Canonical message shape | One IVMS-101-aligned canonical message across originator, beneficiary, wallet and transaction fields Vendor adapters translate to/from this shape — the transfer path only sees one contract. |
| VASP directory & resolution | Beneficiary VASP lookup across vendor directories, with caching, retry and fallback A resolved VASP id, discovery method and confidence attach to the message. |
| Vendor API adapters | Integrations for Sumsub Travel Rule API, Notabene, Sygna, TRP and IVMS-101 direct where required One canonical interface; the transfer flow does not care which adapter is live. |
| Transfer gate | Rule-based gate on the pre-signing step: allow, hold, escalate or reject under vendor verdict, VASP confidence and threshold Rules are configuration, reviewable and versioned in the admin console. |
| Case workflow | Held transfers open aged cases with the IVMS-101 payload, vendor response and reviewer notes attached Four-eyes gates on manual overrides above defined thresholds. |
| Ledger integration | Signed transfer events into your ledger with vendor id, message id, rule version and operator id on every posting Retries never mint money twice; every posting carries a full chain of evidence. |
| Controls & access | SSO, role-based access, four-eyes gates on releases, tamper-evident audit log, GDPR-aware retention EU-hosted by default; retention rules per case class and per counterparty. |
| Reporting & audit | Close packs, MLRO dashboards, message-level exports and reviewer-shaped bundles Regulator-shaped exports out of the same store as ops reports. |
Transfer path
How a Travel-Rule transfer crosses the venue
Every crypto transfer above the applicable threshold goes through the same gates before the wallet ever signs. Speed comes from tuning the pipeline, not from skipping a step or trusting a stale vendor verdict.
- 01
Request
Real time
A user or system initiates a crypto transfer above the applicable threshold; the venue prepares the withdrawal request.
- 02
VASP lookup
Sub-second
The beneficiary address is resolved to a counterparty VASP via vendor directories; a self-hosted-wallet path branches here.
- 03
Message send
Sub-second
The canonical IVMS-101 message is sent via the chosen vendor API (e.g. Sumsub, Notabene, Sygna, TRP).
- 04
Response
Vendor-bound
Counterparty response returns via webhook or callback; the verdict is stored with the message id and vendor id.
- 05
Gate
Rule-driven
The transfer gate allows, holds, escalates or rejects the release under your policy; every decision writes the rule version.
- 06
Sign & report
Post-decision
Approved transfers sign and broadcast; the message, verdict and decision publish to the audit log and close pack.
Delivery
How we deliver a Travel Rule implementation
Five steps, in this order. Travel Rule work runs inside the transfer backlog — no separate compliance phase bolted on before launch, no big-bang release of an untested Travel Rule integration.
- 01
Scoping
Weeks 1–2
We map corridors, thresholds, self-hosted-wallet policy, licence context and your MLRO's expectations for evidence. Output: a scope, a control map and a costed plan.
- 02
Architecture
Weeks 3–4
Canonical message shape, vendor adapter contracts, transfer-gate rules and export schemas written down first. Auditor requirements shape the design.
- 03
Build
Two-week sprints
Vendor adapters, transfer-flow integration, case workflow and reporting ship in slices. Each merge runs tests, static checks and a dependency scan.
- 04
Hardening
Before cut-over
Replay against historical transfers, load work, failure drills, self-hosted-wallet edge cases and a third-party review window. Cut-over is rehearsed with your ops team.
- 05
Launch and run
Cut-over + ongoing
Named engineers on 24/7 cover. Runbooks, dashboards, corridor playbooks and the audit bundle handed to your team on day one, with a documented on-call rota.
Engagement
Four ways to buy your Travel Rule integration
Same engineers, same standard. Only the commercial shape changes.
-
Fixed-scope build
A defined Travel Rule integration at a fixed price and date. Best when corridors and vendors are settled.
-
Dedicated team
A standing squad with a lead. Best for long roadmaps with new corridors and vendor adapters each quarter.
-
Staff augmentation
Senior engineers inside your team. Best when you already own the plan and need integration depth.
-
CTO advisory
Architecture and vendor-mix review before you commit. Best at the design stage.
Questions
FAQ: AML & Travel Rule integration
Six answers up front on scope, build-vs-integrate, vendor partnerships, AML-layer fit, MiCA/PSD2/GDPR and support. Bring the rest to the call.
What does Travel Rule implementation from TrustChange actually cover?
We engineer a bespoke, client-owned Travel Rule integration end to end: the canonical IVMS-101 message shape, adapters into the vendor API you choose (Sumsub Travel Rule API, Notabene, Sygna, TRP or IVMS-101 direct), VASP lookup and resolution, the transfer gate that sits before signing, the case workflow for held transfers, ledger integration and reviewer-shaped exports. It ships as source code in your repositories, with the IP assigned to you.
Do you build Travel Rule software from scratch or integrate an existing vendor?
Both — and the honest answer is that most clients want an integration, not a re-invention. TrustChange writes the canonical message shape, the transfer gate and the evidence log ourselves, and integrates one or more Travel Rule vendors as adapters behind that. You keep the option to swap vendors, run several in parallel (for example one per corridor), or move to IVMS-101 direct messaging over time without rewriting the transfer path.
Do you have a partnership with Sumsub, Notabene, Sygna or TRP?
No exclusive partnership. TrustChange is not a Travel Rule vendor and we do not resell any of them. We name Sumsub Travel Rule API, Notabene, Sygna and TRP as common integration targets because they are what most EU clients evaluate; the vendor decision stays with your compliance team, and our adapter model means you are not locked to one.
How does the Travel Rule integration fit with the rest of the AML control layer?
It sits alongside sanctions and wallet-risk screening on the transfer path — screening runs first, Travel Rule messaging runs before signing, and any held case joins the same aged queue your analysts already work. Downstream, the message and verdict post to the same double-entry ledger and audit log as the payment itself, so an auditor sees one story per transfer.
How are MiCA, PSD2, AML and GDPR engineered in?
TrustChange is an engineering partner, not a law firm — your compliance team and MLRO set the policy, we ship the controls and the evidence. That means MiCA-ready Travel Rule messaging on crypto transfers, PSD2-aware fields on the fiat side of mixed flows, AML rules that run inside the transfer path and GDPR-aware storage of counterparty personal data with retention rules per corridor. Nothing about licences, opinions or supervisor approvals is claimed on your behalf.
Do you also run the Travel Rule integration after launch, or hand it over?
Both are on the table. Most clients start with named TrustChange engineers on 24/7 cover during the first months while their own team ramps up, then take the platform in-house with runbooks, dashboards and an on-call handover we author together. Some keep us on as a dedicated development team or on staff augmentation for new-vendor adapters, corridor changes and integration with adjacent systems.
Book a discovery call for AML & Travel Rule integration
Bring the corridors, the vendor(s) you are evaluating, the licence context and the launch date. We come back with a control map, an architecture view and a costed plan for a Travel Rule integration you own end to end. No demo theatre.