Summary: This is a hands-on blueprint for making non-custodial wallets “Travel Rule-ready” without wrecking UX—using verifiable ownership proofs (EIP-1271, BIP-322), privacy-preserving identity (VC 2.0 + SD‑JWT), and interoperable messaging (IVMS 101.2023, TRISA/TRP)—mapped to what regulators actually require in 2026.

If you’re shipping an EU/UK release this quarter, you now must verify ownership on transfers involving self-hosted addresses over €1,000 and exchange standardized originator/beneficiary data with counterparties; the U.S. withdrew the proposed “unhosted wallet” KYC rule in 2024, but MSB Travel Rule duties still apply. (eur-lex.europa.eu)

Title: How to Implement “Travel Rule” Compliance in Non-Custodial Wallets

Hook: Your wallet passes every pen test—yet exchanges still reject your users’ withdrawals and deposits

• You integrated analytics, travel rule vendors say “VASPs only,” and your team is fielding tickets like “Transfer blocked—missing beneficiary info.”
• EU’s Transfer of Funds Regulation (TFR) has applied since December 30, 2024. For transfers over €1,000 involving self-hosted addresses, CASPs must verify that the address is owned or controlled by their customer, and originator/beneficiary data must accompany every CASP↔CASP transfer. If your wallet can’t help users pass that check, exchanges will continue to bounce the funds. (eba.europa.eu)

Agitate: The cost of “we’ll deal with it later”

• Missed go‑live dates in the EU/UK because your wallet can’t surface ownership proofs that CASPs can automatically verify. (eba.europa.eu)
• Higher abandonment at cash-in/cash‑out because users are forced off-flow to upload screenshots instead of a cryptographic proof of control.
• Risk desk escalations: without standardized IVMS 101 payloads, your exchange counterparties can’t reconcile O/B information, triggering manual reviews and settlement delays. (intervasp.org)
• Regulatory friction: UK FCA expects firms to collect/verify Travel Rule data and to store it when counterparty jurisdictions haven’t implemented the rule yet; weak processes will be flagged in audits. (fca.org.uk)

Who this is for (and the exact phrases you need to show up in RFPs and regulator meetings)

• Heads of Compliance / MLROs at EU/UK CASPs integrating with non‑custodial wallets: “Regulation (EU) 2023/1113 Articles 14–16,” “verification of self‑hosted address ownership > €1,000,” “EBA Travel Rule Guidelines (30 Dec 2024),” “record retention: 5 years (Article 26).” (eur-lex.europa.eu)
• Wallet Product & Engineering Leads: “EIP‑1271 contract signatures,” “BIP‑322 message signing,” “ERC‑4337 smart accounts,” “SIWE challenge,” “deterministic ownership proofs across chains.” (eips.ethereum.org)
• Enterprise Identity/Privacy Teams: “W3C Verifiable Credentials 2.0,” “SD‑JWT (RFC 9901) selective disclosure,” “OID4VCI 1.0 issuance,” “GDPR data minimization + 5‑year retention ceiling.” (w3.org)
• Partner/Network Ops: “IVMS 101.2023 schema,” “TRISA VASP Directory,” “TRISA↔TRP interoperability to beat the sunrise problem.” (intervasp.org)

The 7Block Labs implementation playbook (technical but pragmatic)

1. Map jurisdictional requirements to wallet capabilities

• EU TFR scope: zero threshold for CASP↔CASP transfers; additional verification when a CASP interacts with a self‑hosted address above €1,000 (ownership/control assessment). Application date: December 30, 2024. (vasiliou.law)
• UK: FCA requires firms to collect/verify and share Travel Rule data; when sending to non‑implementing jurisdictions, collect/verify and store before transfer. Last updated February 6, 2026. (fca.org.uk)
• U.S.: FinCEN withdrew the 2020 “unhosted wallet” KYC proposal in Aug 2024. Non‑custodial wallet providers aren’t subject to that proposed counterparty KYC rule; however, MSBs remain responsible for Travel Rule obligations in covered transactions. (consumerfinancialserviceslawmonitor.com)

Result: a per‑route ruleset: CASP↔CASP (IVMS 101 always), CASP↔Self‑Hosted > €1,000 (ownership verification + risk assessment), P2P (non‑CASP): outside TFR scope but subject to local AML/KYC where applicable. (eur-lex.europa.eu)

1. Standardize data exchange with IVMS 101.2023

• Adopt IVMS 101.2023 as the canonical data model for originator/beneficiary identity payloads. This eliminates vendor lock‑in and aligns with leading Travel Rule solutions. (intervasp.org)
• Implement validation: required vs. optional attributes, allowed character sets, and jurisdictional extensions.
• Wire up discovery/interoperability:
  • TRISA VASP Directory for counterparty authentication (mutual TLS, X.509 EV KYC certs). (trisa.io)
  • TRISA↔TRP bridge for cross‑network handshakes to reduce “sunrise” failures. (openvasp.org)

1. Build cryptographic ownership verification for self‑hosted addresses

• Ethereum and AA wallets
  • EOAs: have the wallet sign a challenge (EIP‑191/712). Validate with standard secp256k1.
  • Smart contract wallets: implement EIP‑1271 check; your verifier calls isValidSignature(hash, sig) and expects 0x1626ba7e magic value. (eips.ethereum.org)
  • ERC‑4337 accounts: support both EOA‑style signatures and contract validation paths; expose a uniform “proof_of_control” API. (docs.erc4337.io)
• Bitcoin
  • Implement BIP‑322 for generic message signing—including SegWit and Taproot. Accept both “simple” and “full” proofs. (bips.xyz)
• Other chains
  • Solana: ed25519 signature of a deterministic challenge; Tezos: ed25519/secp256k1/BLSp signatures per wallet’s supported curves.
• UX contract: one click “Prove control” alongside the withdrawal/deposit flow; cache short‑lived attestations server‑side with revocation TTL.

Example: Solidity (verifier-side) snippet for EIP‑1271

interface IERC1271 {
  function isValidSignature(bytes32 hash, bytes calldata signature) external view returns (bytes4 magicValue);
}

function verifyControl(address account, bytes32 digest, bytes calldata sig) internal view returns (bool) {
  if (account.code.length == 0) {
    // EOA path (EIP-191/EIP-712 digest)
    return ECDSA.recover(digest, sig) == account;
  } else {
    // Contract wallet path (EIP-1271)
    try IERC1271(account).isValidSignature(digest, sig) returns (bytes4 magic) {
      return magic == 0x1626ba7e;
    } catch { return false; }
  }
}

1. Minimize PII with modern identity standards

• Issue user identity as W3C Verifiable Credentials 2.0; wallets present Verifiable Presentations containing only needed claims (e.g., legal name and country), enabling selective disclosure and cryptographic verifiability. (w3.org)
• Use SD‑JWT (RFC 9901) for selective disclosure of claims when your ecosystem is JWT‑centric; bind presentations to the wallet’s key to prevent replay. (ietf.org)
• Automate issuance with OID4VCI 1.0 flows from your KYC provider; store only revocation handles, not raw documents. (openid.net)
• Enforce EU record‑retention ceilings (5 years, then delete unless a lawful extension is mandated). Build deletion jobs and audit evidence into data pipelines. (service.betterregulation.com)

1. Align message transport and counterparty discovery

• Default to TRISA (mTLS + VASP Directory) for counterparties on TRISA; fall back to TRP for OpenVASP peers; bridge when needed for interop (now supported). (trisa.io)
• Serialize O/B identity with IVMS 101.2023 and attach transaction identifiers (DLT address, account ref, unique transfer ID) per TFR Articles 14–16. (eur-lex.europa.eu)
• Handle UK “partial implementation” cases: if the receiving jurisdiction lacks Travel Rule enforcement, collect/verify and store the required data before executing the transfer. (fca.org.uk)

1. Risk engine and policy automation (what supervisors expect to see)

• Dynamic rules: ownership proof required thresholds (>€1,000 to/from self‑hosted), jurisdiction risk, address heuristics, sanctions screening.
• Eventing: real‑time policy decisions on “execute / suspend / reject” with full audit trail—mirroring EBA guidance on detecting missing/incomplete info and acting on it. (eba.europa.eu)
• Privacy and DPIA: map each attribute to legal basis (AML/CFT), retention period (5y), and storage location; prove GDPR compliance on request. (service.betterregulation.com)

Practical end‑to‑end examples you can ship this sprint

A) EU CASP receives from your wallet (>€1,000)

• User taps “Withdraw to my wallet” on Exchange A (EU CASP).
• Wallet presents:
  • Ownership proof:
    • If EOA: EIP‑712 signature over nonce and address.
    • If contract wallet: EIP‑1271 validation endpoint returns magic 0x1626ba7e.
    • If Bitcoin: BIP‑322 “simple” signature for the receiving address.
  • Identity: VC 2.0 presentation disclosing legal name (and, if needed, DOB), signed by your KYC issuer; or SD‑JWT with selective disclosure and key binding. (w3.org)
• Exchange validates proof; logs IVMS 101.2023 O/B payload; executes transaction if risk thresholds are met. Ownership verification >€1,000 is satisfied per TFR. (eur-lex.europa.eu)

B) UK firm sends to a jurisdiction without live Travel Rule

• UK exchange collects and verifies O/B info; if the counterparty can’t receive, it still stores the data and then proceeds based on risk, per FCA expectation. Your wallet’s inline VC/SD‑JWT flow reduces manual friction. (fca.org.uk)

C) CASP↔CASP, zero threshold (always send IVMS)

• For any CASP↔CASP transfer, include full IVMS 101.2023 payload (no de‑minimis), then transmit over TRISA or TRP depending on the counterparty directory entry. (vasiliou.law)

Engineering spec (what to build)

• Ownership Proof Service
  • Chains: Ethereum (EIP‑1271 + EOA), Bitcoin (BIP‑322), Solana (ed25519), more via adapters.
  • API: POST /proofs with chain, address, challenge; returns signed proof + metadata.
  • Storage: short‑lived cache (e.g., 24h); rotatable revocation list.
  • Security: mTLS between wallet app and backend; attestations signed with HSM/MPC keys.
  • Observability: percent successful proofs by chain/wallet type; median proof latency.
  • Integrations: ERC‑4337 accounts supported via contract‑validation path. (docs.erc4337.io)
• Identity & Consent
  • VC 2.0 wallet SDK with OID4VCI issuance from your KYC vendor; SD‑JWT support for JWT ecosystems. Selective disclosure by default. (w3.org)
• Travel Rule Messaging
  • IVMS 101.2023 schema + validation.
  • TRISA client (VASP Directory enrollment, X.509 EV KYC certs); TRP client; interop bridge detection. (trisa.io)
• Data Governance
  • Retention: auto‑delete at 5 years (with regulator‑requested extensions only).
  • Encryption: PII at rest with envelope encryption; keyed hashing for identifiers.
  • Audit: immutable event logs for “collect/verify/transmit,” aligned to EBA guidance. (eba.europa.eu)

Best emerging practices we recommend in 2026

• “Proof of Control” before “Proof of Identity”: fail fast on address ownership so you don’t process unnecessary PII.
• Default to selective disclosure: SD‑JWT or VC 2.0 presentations with just the claims your counterparty needs; retain revocation handles, not raw docs. (ietf.org)
• Registry‑driven interop: use the TRISA VASP Directory and TRISA↔TRP bridge to shrink integration time and reduce “sunrise” fall‑throughs. (trisa.io)
• Contract‑wallet first‑class treatment: your verifier MUST implement EIP‑1271 to avoid rejecting legitimate smart accounts (AA/4337) at the ownership‑proof step. (eips.ethereum.org)
• Align with FCA expectations on non‑implementing jurisdictions: collect/verify/store even if the receiver can’t ingest; your policy engine decides execution with a documented, risk‑based rationale. (fca.org.uk)

Governance, procurement, and ROI—how we make this stick

What your board, procurement, and regulators will care about—and what we ship as artifacts:

• Policy map: TFR Articles 14–16 (O/B info and self‑hosted verification), Article 26 (5‑year retention), FCA Travel Rule statement alignment and exceptions handling. (eur-lex.europa.eu)
• DPIA + TOMs: GDPR‑aligned data flows and retention schedule (delete at 5 years, with documented case‑by‑case extensions only). (service.betterregulation.com)
• Interop dossier: IVMS 101.2023 conformance tests; TRISA/TRP integration test reports. (vaspnet.com)
• Technical validation: chain‑specific proof libraries (EIP‑1271, BIP‑322), cryptographic test vectors, and negative‑case testing. (eips.ethereum.org)

How 7Block Labs executes (and where we add the most value)

• Compliance‑by‑design architecture sprints (2–3 weeks) to map flows and choose the smallest‑surface solution that still passes audits.
• Rapid prototyping of “ownership proof” and “selective disclosure” inside your wallet UX, using our prebuilt libraries for EIP‑1271/BIP‑322/VC 2.0/SD‑JWT. (eips.ethereum.org)
• Counterparty enablement: we configure TRISA/TRP connections and IVMS 101.2023 serialization so exchanges stop rejecting transfers. (openvasp.org)
• Audit‑ready documentation and runbooks your MLRO and CISO can sign.

GTM metrics and operating targets we align on from day 1

• Reduce “Travel Rule‑related rejects” on fiat on‑/off‑ramps by 60–80% within 60 days post‑launch (target KPI).
• Cut manual review time per flagged transfer to <5 minutes by moving to standardized IVMS payloads and cryptographic ownership proofs (target KPI).
• Keep PII storage below 1% of total transfer records via selective disclosure + revocation handles (target KPI).
• Time‑to‑greenlight in EU/UK: first production counterparties live in 8–12 weeks, with clear evidence pack for auditors (target timeline driven by directory onboarding and test cycles).

Where this lives in your stack (and how we support it)

• Non‑custodial wallet engineering: leverage our web3 development services to embed proofs, VC 2.0, and SD‑JWT into mobile/extension code.
• Exchange/CASP side: integrate IVMS 101.2023 serialization and Travel Rule transport via our blockchain integration.
• Smart contract paths: ensure EIP‑1271 support and AA compatibility with our smart‑contract development and blockchain development services.
• Security and audits: formalize verification logic and retention controls with our security audit services.
• Cross‑chain routes and bridges: cover multi‑network address proofs with our cross‑chain solutions development and blockchain bridge development.

Brief in‑depth details for legal and technical reviewers (citations to current sources)

• EU TFR enforcement and self‑hosted threshold: applicable since Dec 30, 2024; for transfers >€1,000 involving self‑hosted addresses, CASPs must verify ownership/control; CASP↔CASP transfers run at zero de‑minimis. (eba.europa.eu)
• UK FCA expectations: when counterparties can’t yet receive Travel Rule data, UK firms must still collect/verify and store the information before executing; guidance updated Feb 6, 2026. (fca.org.uk)
• SD‑JWT is now an IETF standard (RFC 9901, Nov 2025) enabling selective disclosure; W3C Verifiable Credentials 2.0 reached Recommendation in May 2025; OID4VCI 1.0 finalized Sept 2025. These are the identity primitives we recommend. (ietf.org)
• EIP‑1271 is the canonical method for contract‑based signature validation; ERC‑4337 is the de‑facto account abstraction stack for smart wallets. Your verifier must handle both. (eips.ethereum.org)
• Bitcoin ownership proofs should implement BIP‑322 for modern address types (SegWit/Taproot). (bips.xyz)
• IVMS 101.2023 is the updated data model; TRISA↔TRP interoperability is live and helps resolve counterparty “sunrise” issues. (vaspnet.com)
• Retention: store O/B data for 5 years, then delete unless a lawful extension applies (documented and time‑boxed). (service.betterregulation.com)
• U.S. posture: withdrawal of the 2020 “unhosted wallet” KYC NPRM in Aug 2024 reduces direct pressure on non‑custodial wallet developers, but MSB Travel Rule duties remain for covered entities. (consumerfinancialserviceslawmonitor.com)

Common pitfalls (so you can avoid rework)

• Treating EOA signatures as sufficient for all Ethereum accounts—this fails for contract wallets; add EIP‑1271. (eips.ethereum.org)
• Holding raw identity docs “just in case”—violates data minimization and clashes with 5‑year deletion duties; use VC 2.0/SD‑JWT with revocation handles instead. (w3.org)
• Relying on screenshots for ownership—regulators tolerate them only as stopgaps; ship cryptographic proof flows now. (EBA guidance on measures for self‑hosted verification.) (eba.europa.eu)
• Ignoring interop—without IVMS and TRISA/TRP discovery, counterparties will continue to NACK transfers. (vaspnet.com)

Implementation timeline (realistic for Q1–Q2 2026)

• Weeks 1–2: Architecture sprint, jurisdiction mapping, DPIA, and schema validation (IVMS 101.2023).
• Weeks 3–6: Ownership Proof Service (EIP‑1271/BIP‑322), VC 2.0/SD‑JWT flows, Travel Rule messaging clients.
• Weeks 7–8: Directory onboarding (TRISA), interop testing (TRISA↔TRP), negative‑case test harnesses. (trisa.io)
• Weeks 9–12: Pilot exchanges live, runbooks finalized, internal audit sign‑off.

Why 7Block Labs

• We build the rails that let your wallet and your counterparties exchange the right Travel Rule data, prove ownership cryptographically, and expose the minimum identity necessary—so transfers clear, users stay, and auditors sign off.
• Start with our blockchain development services for the core proof and messaging logic, add security audit services to validate controls, and finish with blockchain integration to wire in your counterparties.

CTA (personalized and specific)

Wallet PM shipping an EU/UK release by April 2026? Book a 45‑minute whiteboard with our architects this week—we’ll map your EIP‑1271/BIP‑322 proof flows, design a VC 2.0 + SD‑JWT disclosure that satisfies TFR Article 14–16 with 5‑year deletion, and return a build plan and risk register within 5 business days. Then we’ll implement it end‑to‑end via our web3 development services and harden it with a focused security audit so your counterparties stop rejecting transfers.