MiCA reporting requirements
The framework page: scope, obligations and supervisory powers.
Read the requirements →Authorisation is the beginning of the obligation, not the end of it. These are the questions providers ask once the licence is granted and the reporting cycle starts.
Regulation (EU) 2023/1114 creates a single Union regime with several distinct populations. Title III covers issuers of asset-referenced tokens, Title IV covers electronic money tokens, Title V covers crypto-asset service providers, and Title VI covers the prevention of market abuse involving crypto-assets. A single business can sit in more than one of them, and each carries its own reporting.
For an authorised provider, the recurring obligations divide into three: periodic supervisory reporting on the activity carried on under the authorisation; event-driven notification, including material changes to the business and reporting where market abuse is suspected; and, where the provider also issues tokens, the issuer obligations in Titles III and IV.
Supervisory returns describe the authorised activity rather than the firm’s accounts. In practice a return draws on four data sources: the client base, holdings and client assets, the services actually provided under each authorised activity, and the instruments and crypto-assets involved.
The precise templates, frequencies and formats are set by technical standards and by the competent authority, and they are versioned in the same way other supervisory frameworks are. The stable part — and the part worth engineering first — is the underlying dataset: a client record that resolves to one identity, an activity record that maps to the authorisation, and an asset record with consistent identifiers.
Issuers carry a further layer. The reserve backing tokens in issue is subject to its own reporting, alongside information on tokens outstanding and on their use. Where a token reaches significance under the Regulation, supervisory responsibility and the reporting expectations attached to it change, so an issuer approaching those criteria plans for the change rather than reacting to it.
A provider that both issues and offers services runs both sets, from one dataset. The reserve position and the client-asset position are different measurements of overlapping balances, and reconciling them once is considerably cheaper than reconciling them each period.
A crypto-asset white paper is a regulatory artefact, not a marketing document. It must carry the content the Regulation prescribes, be notified to the competent authority, and be published; where a structured, machine-readable form is required, the document is tagged rather than merely converted. Tagging a document written without the required structure is where projects lose time — the drafting and the tagging are the same task approached from opposite ends.
Supervisory reporting fails on identity long before it fails on substance. Entity identifiers must resolve consistently across returns and across periods; crypto-asset identifiers must be applied consistently where the same asset appears under several tickers or on several chains; and client identity must survive account restructuring. These are the same problems the tax framework raises, which is why the two obligations are best served from one reference dataset rather than two.
Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.
No. Supervisory reporting goes to the financial supervisor that authorised the provider and describes the authorised activity. The crypto-asset tax framework reports customer and transaction data to a tax authority for automatic exchange. Most authorised providers are in scope of both, and the two filings share source data but not a destination.
The reporting cycle attaches once the authorisation is in force, on the frequency set by the competent authority. Providers that operated under a national regime before the Union framework applied may have moved across under transitional arrangements set nationally, so confirm your first reference date with the authority rather than inferring it.
The supervisory relationship follows the authorisation. A provider authorised in one Member State and passporting elsewhere reports to its home authority, but host authorities have their own supervisory interests and the tax framework has its own nexus rules. Map the three separately — they do not have to give the same answer.
The white paper obligation attaches to offers to the public and to admission to trading, and it falls on the offeror or the person seeking admission. A provider admitting an asset to trading needs to establish who carries the obligation for that asset before assuming it does not have one.
REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.
More on this framework, and the module that produces the filing.
The framework page: scope, obligations and supervisory powers.
Read the requirements →How the supervisory and tax obligations sit together in one operation.
Read use case →The tax side of the same customer and transaction data.
Read the guide →Map your activity and holdings once, then produce the supervisory filing and the tax filing from the same source. Start with a free test report.