The MiCA and Travel-Rule Compliance Stack for a New CASP

A crypto-asset service provider authorised under MiCA takes on, from the day its authorisation is granted, obligations that are continuous rather than periodic: transmit originator and beneficiary information on every transfer, screen counterparties and addresses, verify control of self-hosted addresses above a threshold, keep records of every service, activity, order and transaction in a prescribed form, and maintain a business continuity policy its management body has endorsed. Each is separately supervised, and each produces evidence a competent authority can ask for. This blueprint runs that stack so the evidence is a by-product of operating the business rather than a reconstruction carried out under examination.

The recast Transfer of Funds Regulation has applied to crypto-asset transfers since 30 December 2024, and the EBA travel-rule guidelines took effect the same day, so the obligation is live. MiCA's transitional period closed on 1 July 2026, so the firms serving EU clients are now authorised CASPs, each carrying the full obligation set from the date of its own authorisation. The pattern is in production, with three named institutions running it and the earliest screening a MiCA e-money token since August 2024, yet no published reference architecture exists for the combined stack, because vendors publish their own layer and stop at its boundary. For a newly authorised CASP the value is in running every obligation as one evidenced chain from the first day of authorisation, which also clears the way for the product blueprints that usually follow within weeks.

Yes, if you hold a MiCA Art. 63 CASP authorisation or are in final supervisory dialogue on one, you execute transfers to and from counterparty CASPs and self-hosted addresses, and you already run an onboarding and AML function for another regulated activity.

Probably not, if you will not hold your own authorisation and intend to keep serving EU clients on somebody else's licensed rail - a different pattern applies. Also not, if your transfer volumes are low: this is a fixed-cost operating stack against a variable revenue base, and below a certain volume operating on an authorised provider's rail is the cheaper answer.

• The information duty and the self-hosted threshold are separate duties. Article 14 of Regulation (EU) 2023/1113 requires originator and beneficiary information on every crypto-asset transfer with no de-minimis - recital 27 grants no exemption for low-value domestic transfers. The EUR 1,000 figure that does exist governs a different duty: under Art. 14(5), a transfer above it to or from a self-hosted address obliges the provider to assess whether the customer owns or controls that address. A stack that applies a EUR 1,000 data-collection floor by analogy to payments is non-compliant from its first transaction. Separating the two duties at the routing layer keeps that error from occurring.
• Self-declaration does not satisfy the self-hosted duty. The EBA travel-rule guidelines (EBA/GL/2024/11, applying 30 December 2024) address the acceptable methods, and paragraph 83 rules out a customer's own say-so. The verification mechanism has to be built into the architecture.
• No vendor owns the record store. Commission Delegated Regulation (EU) 2025/1140 prescribes records of all crypto-asset services, activities, orders and transactions. Each vendor in the stack holds only its own layer, so the institution cannot outsource this one; it has to be designed in from the start, so the records exist before any examination.