ESMA’s 21 October MIDAS instructions provide operational details for centralised crypto-market surveillance. The manual describes data submitted in response to competent-authority requests under the MiCA framework, rather than announcing a new licence or transferring national supervisory responsibility to ESMA.[1]
Submission scope and workflow
| Area | Instruction |
|---|---|
| Trading-platform CASPs | Execution records (auth.117), including both buy and sell legs where applicable, plus pre-trade order-book records (auth.118)Source 1 |
| Other CASPs | Execution records (auth.117), with the relevant buy or sell leg per recordSource 1 |
| Frequency | Every two weeks; alternatives require agreement with the provider and national authoritiesSource 1 |
| Transport and format | Dedicated SFTP; plain-text UTF-8 JSONSource 1 |
| File limit | 500 MB; split larger datasets into partsSource 1 |
| Local validation | Pre-validate mandatory fields and datatypes against the supplied JSON schemaSource 1 |
| Validation | Transmission, file and content checksSource 1 |
| Onboarding | Separate test and production endpoints, with test files before productionSource 1 |
The first phase uses a limited subset of data rather than the full MiCA record-keeping inventory. It excludes personal identifiers and specified supervisory or investigative data. Feedback files identify validation findings, requiring firms to distinguish successful transmission from accepted content and correct rejected submissions.[1]
Filename validation is also substantive: the prescribed pattern identifies the dataset type, the record date and the part number out of the total parts. A malformed filename can be rejected before business-content checks. The first-phase exclusions do not abolish the wider MiCA record-keeping obligations; they limit what this initial MIDAS collection receives.[1]
Sources & further reading
- MIDAS Reporting Instructions, ESMA65-955014868-17690 ESMA · Accessed 26 Oct 2026