What is MiCA? The Complete Guide to EU Crypto-Asset Regulation

The Markets in Crypto-Assets Regulation is the EU's directly applicable framework for the issuance of crypto-assets and the provision of crypto-asset services, replacing a patchwork of national regimes with a single set of rules enforced by national competent authorities and, for the largest issuers, with an ESMA and EBA role. It entered into force on 29 June 2023. Title III, covering asset-referenced tokens, and Title IV, covering e-money tokens, applied from 30 June 2024. The remaining provisions, including the authorisation regime for crypto-asset service providers, applied from 30 December 2024.

This article is specifically about the safeguarding and custody obligations MiCA places on CASPs and token issuers, which are the provisions that determine how client funds and client crypto-assets must be held. It does not re-cover the licensing regime, the market abuse provisions, or the white paper requirements for token issuance. Readers wanting the licensing and authorisation picture, or Safeheld's approach for a specific type of firm, should go to the dedicated pages: the Article 68 explainer for what the custody article means operationally, the crypto custodian guide, and the exchange-focused guide for CASPs operating trading venues.

Article 70 governs client funds, meaning fiat currency belonging to clients that a CASP receives or holds in the course of providing crypto-asset services. Where a CASP holds client funds, it must place them, no later than the end of the business day following the day on which they were received, with a central bank or a credit institution.

Client funds must be held in an account or accounts separately identifiable from any accounts used to hold funds belonging to the CASP itself. This separate identification requirement is the operative safeguard: it is what allows client funds to be distinguished from the CASP's own money if the CASP fails, and it mirrors the segregation principle found in other EU and UK client money regimes, applied here specifically to the fiat leg of a crypto-asset service.

Article 70 is a funds-holding obligation. It is not the same provision as the one governing crypto-assets held for clients, which is addressed separately in Article 75, and firms building compliance programmes should not treat next-business-day placement of fiat as satisfying their custody obligations for the crypto-assets themselves.

Article 75 applies to CASPs providing custody and administration of crypto-assets on behalf of clients. It requires the CASP to enter into an agreement with each client specifying the custody arrangement's duties and liabilities, to keep a register of positions for each client enabling the identification, at any time and without delay, of the client's assets and their holding location, and to maintain the same type and quantity of crypto-assets as would be required to meet the client's entitlement.

Client crypto-assets must be held distinctly from the CASP's own holdings, whether on-chain through distinctly identifiable addresses or wallets, or through equivalent arrangements achieving the same segregation outcome. A CASP is liable, in the event of loss of a client's crypto-asset arising from an incident attributable to the CASP, for a loss of the same type and quantity, or the corresponding value, without undue delay, unless the CASP can prove the incident arose independently of its operations.

Article 75 does not use the language of internal and external reconciliation found in frameworks like the FCA's client assets rules or the UK's safeguarding regime, and it does not prescribe a reconciliation frequency. Its mechanism is the combination of a client-level register, a segregation requirement, and a liability standard, rather than a specified cadence of matching activity. CASPs that import a reconciliation frequency from another jurisdiction's rulebook and present it as a MiCA requirement are overstating what Article 75 actually says.

It is worth stating plainly, because the claim is made loosely elsewhere: neither MiCA itself nor the technical standards issued under it establish a specific monitoring or reconciliation frequency for client funds or client crypto-assets. The obligations are outcome-based, expressed as the ability to identify a client's holdings at any time and without delay, and to maintain adequate segregation continuously, rather than as a rule requiring reconciliation daily, weekly or on any other stated interval.

In practice this places the operational judgement on the CASP. A firm that can only demonstrate its segregation and entitlement position through an infrequent manual process is exposed to the same risk the rule is trying to prevent, even though no specific frequency has been breached, because the underlying obligation is continuous identifiability, not a periodic check. The absence of a prescribed frequency is not the absence of an expectation; it simply means the expectation is expressed through the outcome rather than the method.

Article 143 allowed providers that were already lawfully providing crypto-asset services under national law before MiCA's CASP provisions applied to continue doing so under a transitional arrangement, for a period member states could set, ending no later than 1 July 2026. Individual member states set their own, often shorter, windows, and the national positions were published by ESMA.

That window has now closed everywhere. There is no jurisdiction in which a provider can rely on Article 143 transitional treatment rather than MiCA authorisation. A firm operating in the EU today needs either a CASP authorisation from a national competent authority or an applicable exemption; reliance on prior national permissions is no longer available anywhere in the bloc.

Safeheld reconciles client funds held under Article 70 and client crypto-assets held under Article 75 as two distinct populations, matching on-chain wallet balances against the client-level register Article 75 requires, and fiat balances held with credit institutions against the client funds ledger, rather than treating the two as a single position. Because MiCA sets no prescribed frequency, the practical answer is to run both continuously, so that the identifiability the regulation requires is genuinely available at any time rather than reconstructed when asked for.

Each reconciliation run is sealed with a SHA-256 Merkle root and independently verifiable, giving a CASP a tamper-evident record of its segregation and entitlement position on any given day, which is the evidentiary form a national competent authority is most likely to find persuasive in the absence of a codified reporting template for this specific question.