vault

15 — Compliance (DAC8, Travel Rule, MiCA)

docs/15-Compliance.mdtype: compliance-referenceupdated: 2026-05-03

Compliance — DAC8, FATF Travel Rule, MiCA

Nothing on this page is implemented in the MVP. This is the compliance brief that will gate live launch — see 10-Roadmap#Beta and 10-Roadmap#GA. Tracked together because the data-collection requirements overlap; the obligations and timelines do not.

Why three regimes, not one

Each regime answers a different question about the platform:

Regime Question it answers Trigger Cadence
MiCA / CASP licensing Are you allowed to operate at all? One-time + ongoing Authorisation (one-shot) + ongoing supervision
FATF Travel Rule (TFR) Who's sending and receiving each transfer? Every transfer (no de minimis in EU) Real-time, attached to each tx
DAC8 / CARF What was each customer's annual activity? Customer activity over the year Annual report

A custodial EU-touching platform like Daxchain has to satisfy all three. MiCA is the entry ticket; the other two are operational obligations that follow from holding the ticket. Order of build:

  1. MiCA / CASP — gates the legal right to operate. Application typically takes 3–6 months; capital + governance + AML policies all need to be in place at filing time.
  2. FATF Travel Rule — operational dependency for sending custodial transfers; must be live by Beta launch.
  3. DAC8 — annual reporting; first cycle 2027 covers calendar 2026, so aggregation must start at year-start of the first applicable year.

Travel Rule is the higher engineering lift (real-time messaging integration); DAC8 is the higher data-quality lift (TIN + tax-residence per merchant + per-customer aggregation + XML reporting); MiCA is the higher organisational lift (capital, governance, ongoing supervision).

FATF Travel Rule

What it is

Issued by the Financial Action Task Force as Recommendation 16, extended to virtual assets in 2019. Implemented locally:

  • EU: Regulation (EU) 2023/1113 — the Transfer of Funds Regulation (TFR), in force since 30 December 2024. EU dropped the de minimis threshold — applies to any amount.
  • US: FinCEN guidance under the BSA — USD 3,000 threshold.
  • Singapore: MAS Notice PSN02 — SGD 1,500.
  • UK: FCA — GBP 1,000.
  • Other jurisdictions set their own.

What we'd have to do

Whenever Daxchain (a VASP) sends crypto to another party, we transmit originator + beneficiary identity data to the receiving VASP. Receiving VASPs do the same in reverse, screen against sanctions, and refuse / return non-compliant transfers.

Required fields, per FATF + EU TFR:

Originator block:

  • Name (legal name).
  • Account / wallet identifier (the on-chain source address).
  • One of: physical address, national ID number, customer ID number, date + place of birth.

Beneficiary block:

  • Name.
  • Account / wallet identifier (the on-chain destination address).

Self-hosted wallet variant: when the counterparty is a self-custodial wallet (no VASP on the other side), the originating VASP must either:

  • Verify the destination address belongs to the originator (self-attest + proof), OR
  • Collect the beneficiary's identity from the originator and screen accordingly.

What it integrates with

Travel Rule data rides alongside the on-chain transaction via off-chain messaging protocols. Common ones:

  • IVMS 101 — InterVASP Messaging Standard. The data schema everyone uses.
  • TRP — Travel Rule Protocol (open).
  • Notabene, Sumsub Travel Rule, Veriscope, Shyft, OpenVASP — competing networks/ vendors offering counterparty-VASP discovery + IVMS 101 transport.

Without an integration, we can't legally send custodial transfers to other regulated VASPs in the EU.

Open questions for Daxchain

MiCA — CASP licensing

What it is

The Crypto-Asset Service Provider (CASP) license is the mandatory authorization under the EU's Markets in Crypto-Assets Regulation (MiCA), in effect since 30 December 2024. One license, granted by a National Competent Authority (NCA) in any member state, passports to provide crypto services across all 27 EU member states — replacing the patchwork of national VASP registrations that existed before MiCA.

Why it gates Daxchain

A custodial platform offering EU customers any of: custody, exchange, transfer services, payment acceptance, on/off-ramp, or trading platform operation must hold a CASP license (or partner with a licensed CASP under a co-CASP arrangement). The MVP touches at least: custody (via Fireblocks), exchange (convert), transfers (Send / Payouts / API-order settle), payment acceptance (Merchant API / Pay-to). That puts us squarely inside CASP scope.

Capital classes

MiCA tiers CASP authorisations by activity. Initial paid-in capital floor depends on the highest class the firm operates:

Class Initial capital Activities covered
Class 1 €50,000 Reception + transmission of orders, advisory, portfolio management, order execution on behalf of clients, transfer services for crypto-assets
Class 2 €125,000 Class 1 + custody and administration on behalf of clients, exchange of crypto-assets for funds or other crypto-assets, placing of crypto-assets
Class 3 €150,000 Class 2 + operation of a trading platform for crypto-assets

Capital is paid-in equity (own funds), not balance-sheet float. Operational requirements (governance, AML, IT-resilience, complaints handling, segregation of client funds) are layered on top of the capital floor.

Likely class for Daxchain

Class 2 (€125,000) is the working assumption based on the shipped MVP:

  • ✅ Custody on behalf of clients (Fireblocks-backed wallets per 03-Domains#Wallet & Ledger).
  • ✅ Transfer services (Send / Receive / Payouts / API-order settle).
  • ✅ Exchange of crypto-for-crypto and crypto-for-funds (convert, plus the Mercuryo-iframe buy/sell).
  • ❌ No order-book trading platform — convert uses oracle pricing, not order matching. So not Class 3.

If the product expands to a true matching engine, the class moves to 3 (€150K) and the application changes scope. Tracked at 09-Open Questions#CASP path.

Application process

Five-stage path with the chosen NCA:

  1. Preliminary assessment — informal pre-application engagement with the NCA (some are formal, e.g. France AMF; some are advisory, e.g. Estonia FSA).
  2. Documentation preparation:
    • Business plan + 3-year financials.
    • Governance + organisational chart.
    • AML/KYC policies + procedures.
    • IT security + operational resilience plan (ties to 14-Operations#DORA-relevant themes).
    • Complaints handling + conflicts of interest policy.
    • Custody / safeguarding policy (segregation of client crypto + reconciliation cadence).
    • Capital adequacy demonstration.
  3. Application submission to the NCA in the chosen member state.
  4. NCA review — typically 3–6 months, often longer for first-wave applicants. NCA can ask for clarifications, additional capital, or scope reduction.
  5. Authorization — once granted, the license is passportable to all 27 EU states via notification (no re-application).

Transition + deadlines

  • 30 December 2024 — MiCA fully applicable; CASP regime in force.
  • 1 July 2026 — many EU member states require existing local-VASP registrations to file a CASP application by this date (the so-called "grandfathering window"). Specific deadlines differ per member state.
  • By end of 2026 — most national VASP regimes phased out; CASP becomes the only legal path.

The grandfathering window does not exist for new entrants — anyone starting fresh after 30 December 2024 must file a CASP application before serving EU customers.

Choosing the NCA

Open question for Daxchain — see 09-Open Questions#CASP path. Common considerations:

NCA Reputation Notes
Estonia (FSA) Crypto-friendly, fast processing pre-MiCA Strict on substance — needs real local presence
Lithuania (Bank of Lithuania) Fintech hub, English-speaking Heavier capital + governance scrutiny than pre-MiCA
Cyprus (CySEC) Cheap setup, English-speaking Reputation costs (legacy CIF concerns)
Malta (MFSA) Pre-MiCA crypto specialism Slower, more scrutiny, higher fees
Ireland (CBI) Heavy lift but reputable Strong NCA, useful if banking-grade trust matters
France (AMF) Toughest, longest process Best reputation; expensive
Germany (BaFin) Toughest, longest process Big EU market access; heavy substance bar

Trade-offs: speed vs reputation vs cost vs how friendly the NCA is to crypto-native ops models.

Co-CASP path

The alternative: don't hold the license ourselves, partner with a licensed CASP that "fronts" the regulated activity. Common shapes:

  • Pure white-label — the partner CASP holds customer relationships; Daxchain provides infrastructure.
  • Tied agent / appointed representative — Daxchain operates under the partner's umbrella, with a defined liability boundary.

Trade-off: faster time-to-launch + lower capital requirement, but per-transaction fees + dependency on the partner's continued license + less product control. Stage-gated decision at 09-Open Questions#CASP path.

What this means for the platform

Surface Pre-CASP Post-CASP
Customer onboarding KYC via Sumsub mock KYC by chosen vendor + DAC8 TIN/tax-residence + risk classification
Send / Payouts / API order Mocked AML Live AML + Travel Rule + sanctions screening
Custody Mocked Fireblocks Live Fireblocks with segregated client wallets, monthly reconciliation report to NCA
Complaints Email In-product complaint flow, 8-week SLA per ESMA guidance
Capital n/a €125k own funds, demonstrable via audited statements
Regulatory reporting None Quarterly + annual to the NCA, plus DAC8 to home tax authority
White-label n/a If we end up serving downstream platforms, additional disclosure obligations

Open questions

DAC8 / CARF

What it is

Directive (EU) 2023/2226 (DAC8) — the 8th amendment to the EU's Directive on Administrative Cooperation. Aligned with the OECD Crypto-Asset Reporting Framework (CARF).

  • Adopted: October 2023.
  • Member states must transpose: 31 December 2025.
  • Applies from: 1 January 2026.
  • First reporting cycle: 2027 (covering 2026 activity).

What it requires

Every CASP (any MiCA-regulated entity, plus some that aren't) has to:

  1. Collect TIN + tax residence for every customer at onboarding. KYC-plus.
  2. Aggregate annually — for each customer, total value of crypto activity per asset:
    • Crypto-to-fiat exchanges.
    • Fiat-to-crypto exchanges.
    • Crypto-to-crypto exchanges.
    • Transfers (in / out).
    • Reportable retail payments (≥ EUR 50,000 to merchants).
  3. Report to home tax authority — annual XML in the CARF/DAC8 schema.
  4. Cross-border exchange — tax authorities share the data automatically across the EU and with CARF partner jurisdictions (currently US is observer, not signatory; will likely follow).

Scope (broader than Travel Rule)

DAC8 covers things Travel Rule doesn't:

  • Self-custody transfers (initiated through a CASP).
  • NFTs (with carve-outs for unique non-fungibles used as collectibles).
  • Stablecoins.
  • E-money tokens.

What we'd have to add

Capability Today DAC8 minimum
Tax-residence on user not collected per-user field, validated at onboarding
TIN collection not collected per-user field with country-specific format checks
Per-asset annual aggregation derivable from transactions + ledger_entries dedicated reporting view + freeze-at-year-end
CARF XML export not implemented annual job that produces the standard schema
Customer notice not given DAC8 requires informing customers their data is shared
Retention best-effort minimum 5 years per the directive
Classification logic implicit per transactions.type each on-chain event must be classified as transfer / exchange / payment

Open questions

How they intersect with the platform today

Payouts (reference/payouts)

Each batched recipient transfer is a "transfer of crypto-assets" under TFR. All of the following will need to ride with each row, regardless of amount, in the EU:

  • Originator block (the merchant's identity).
  • Beneficiary block (recipient — VASP-attached or self-custodial).
  • VASP identifier — Daxchain's BIC / VASP DID / Notabene workspace, depending on protocol.

The Bruno collection at tests/bruno/payments/ and tests/bruno/payouts/ will need new positive scenarios for the Travel Rule message and negative scenarios for missing/invalid identity data.

Merchant API / QR Payments (user-stories/06-Merchant-API-QR-Payments)

Customer side is anonymous today. Under TFR, when the merchant settles received funds onward, the outgoing transfer carries Travel Rule data — but inbound from a payer wallet is treated as a deposit into the merchant's omnibus, with the originator being the payer's VASP (if known) or the payer themselves.

Send / Receive (03-Domains#Send, 03-Domains#Receive)

The personal Send flow is a custodial outbound transfer: full TFR scope. Receive on a per-user deposit address is inbound — Daxchain is the beneficiary VASP and screens the originator data.

Buy / Sell (03-Domains#Buy, 03-Domains#Sell)

Card on-ramp via the acquirer is fiat → crypto held by Daxchain → no on-chain transfer in the user-facing leg. The Travel Rule applies to the next outbound. DAC8 still records the buy as a fiat-to-crypto exchange.

Engineering surface — what this changes

New schema (planned)

Table Columns to add
users tax_residence_country (ISO 3166-1), tax_id_number (text, encrypted), tax_id_country (ISO 3166-1), dac8_consent_acknowledged_at (timestamptz)
payees beneficiary_legal_name, beneficiary_country, beneficiary_self_attested_self_hosted (boolean), beneficiary_vasp_identifier (text
payout_rows tfr_originator_payload (jsonb, IVMS 101), tfr_beneficiary_payload (jsonb), tfr_message_id (text), tfr_status (enum: `pending
api_orders tfr_originator_payload, tfr_beneficiary_payload (only when settling outbound)
New table dac8_reports per-customer per-year aggregates: total in/out, exchange totals per asset, retention markers
New table tfr_messages message log for Travel Rule sent/received: direction, counterparty_vasp, protocol, payload, status, at

Concrete schema design lands when the Travel Rule vendor + DAC8 reporting library are picked.

New surfaces (planned)

  • Onboarding — TIN + tax-residence collection at signup. Validation per country format.
  • /payees/[id] — per-payee VASP / self-attest fields.
  • /admin/dac8 — annual report preview + XML export.
  • /admin/travel-rule — message log, retry, dead-letter.
  • /api-orders/config — merchant Travel Rule company-info form (legal name, country, VASP id).

New jobs (planned)

  • Travel Rule outbound on every send / payout / api-session settle.
  • Travel Rule inbound listener (counterparty VASP messages).
  • Year-end DAC8 aggregation snapshot.

Sequencing

Phase Compliance milestone
MVP (today) Mocked AML via Elliptic only. No TFR, no DAC8, no MiCA.
Beta (10-Roadmap#Beta) Travel Rule integration + sanctions screening live for the launch jurisdiction. CASP path decided. TIN collected at signup.
GA (10-Roadmap#GA) DAC8 first reporting cycle delivered (covering 2026 → reported 2027). Full multi-jurisdiction Travel Rule support.
Scale DAC8 expanded to additional CARF partner countries.

Cross-references