Menu
Collage surréaliste : un grand œil orange domine des tuyaux pneumatiques reliant des bureaux à un poste central, image de la collecte des données des PSCA par MIDAS
Back
Articles
7 November 2026

How a CASP prepares for ESMA’s MIDAS reporting

ESMA’s reporting instructions dated 21 October 2026 set out how CASPs will feed MIDAS, the EU system for detecting market abuse in crypto-assets. Every authorised CASP will send its executed transactions every two weeks, and trading platforms will also send their order book. The AMF (Autorité des marchés financiers, the French financial markets regulator) has not yet set a timetable for data collection: CASPs should use the time left to clean up their data and test the transmission chain.

What does MIDAS change for a CASP?

MiCA created no transaction reporting obligation comparable to Article 26 of MiFIR. Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA) requires CASPs to keep records of all their services, orders and transactions (Article 68(9)), requires trading platforms to keep their order book data available (Article 76(15)), and empowers competent authorities to require any relevant information (Article 94). MIDAS turns this power to request into a periodic data flow.

Under a delegation agreement (Article 28 of Regulation (EU) No 1095/2010), national competent authorities have entrusted ESMA with collecting the data, checking its quality, calculating common indicators of suspicious behaviour and distributing alerts. They keep supervision, investigations and sanctions. This technical centralisation is moving ahead while legislators still debate direct supervision of CASPs: on 9 October 2026, the Council’s position on the market integration and supervision package (MISP) limited ESMA supervision to the most significant CASPs, whereas MIDAS covers all authorised CASPs.

MIDAS works through the authority that authorised the CASP. A CASP authorised in another Member State and serving France under a passport reports through its home authority, not the AMF (see providing services in France under a MiCA passport).

On 28 November 2025, ESMA said that national authorities expected to request data in the new JSON format within six months. The MIDAS reporting instructions followed, dated 21 October 2026, and CASP onboarding is open. The AMF has not yet set its timetable.

Which CASPs send which data?

The instructions set out two data flows. The executions file (message auth.117) covers executed transactions and applies to all CASPs. The order book file (message auth.118) traces the life cycle of each order, from entry to execution, cancellation or expiry; it applies only to trading platforms.

Which MIDAS data flows apply to your CASP?

1. Do you operate a trading platform for crypto-assets?
YES
Executions file, with both legs in a single record, and order book file.
↓ NO
2. Do you execute transactions for or against your clients (execution of orders, exchange)?
NO
In practice, no executions to report: custody and administration, advice, transfer services. For reception and transmission of orders, the answer depends on the conditions of Article 11 of the record-keeping RTS.
↓ YES
3. Do these transactions go through a platform, to execute the order or for a back-to-back trade?
NO
Executions file, your own leg only, coded XOFF or XXXX.
↓ YES
Executions file, your own leg only, with the MIC code and the identifiers assigned by the platform, including back-to-back trades in our view.

MIDAS takes only part of the records required by Commission Delegated Regulation (EU) 2025/1140 on record-keeping: nine fields for executions (timestamp, transaction record number, trading platform transaction ID, price currency, DTI, side, quantity, price, trading platform) and 18 for the order book, taken from Commission Delegated Regulation (EU) 2025/416. In the first phase, MIDAS excludes personal data, suspicious transaction and order reports (STORs) and investigation material. Buyers and sellers are not identified.

Sources: ESMA, MIDAS reporting instructions (ESMA65-955014868-17690), sections 1.2 and 3.1; Commission Delegated Regulation (EU) 2025/1140. Last two rows: the firm’s reading.
CASP serviceMIDAS data flowPoint to watch
Operation of a trading platform for crypto-assetsExecutions, both legs in a single record, and order bookHighest volume; consistency between orders and executions
Execution of orders on behalf of clientsExecutions, the CASP’s legMIC code and identifiers to obtain from the execution platform
Exchange of crypto-assets for funds or other crypto-assetsExecutions, the CASP’s leg, coded XOFF or XXXX off-platformBack-to-back trades on a platform also to report, in our view
Reception and transmission of orders on behalf of clientsExecutions, depending on the transmission conditions of the record-keeping RTS (Article 11)Split of records with the executing firm to confirm
Custody, advice, transfer servicesIn practice, no executions to reportTreatment of a period with no transactions to confirm

In our work with CASPs, questions come mainly from trading platforms and from providers executing orders on behalf of clients. They produce the most records and depend most on third-party data.

Does an exchange service carry a lighter MIDAS burden than order execution?

The obligation is the same: neither operates a trading platform, and each sends only the executions file, for its own leg, with the same fields and checks.

The practical burden differs. An exchange provider executing against its own book produces one record per client trade, from data it controls. It codes the transaction XOFF when the crypto-asset is admitted to trading on a platform, and XXXX when it is not admitted anywhere. An execution provider depends on the platform where it places the order: one order may produce several executions, and the transaction ID that the platform assigns to each becomes mandatory once a MIC code is reported. Obtaining these data becomes uncertain when the platform is established outside the Union.

Back-to-back trades bring the two cases closer. An exchange provider that covers each client trade on a platform carries out transactions there itself. In our view, it reports them too, since the record-keeping RTS covers all transactions of the CASP; the instructions do not address this case.

The price currency is expressed as an ISO code for an official currency and as the DTI short name for a crypto-asset. A crypto-to-crypto exchange therefore needs two reliable DTIs per pair, an exchange against euros only one.

How do the data reach MIDAS?

The CASP uploads JSON files (UTF-8) that comply with ESMA’s schemas to a dedicated SFTP server. Each file is 500 MB at most; above that, the CASP splits it into numbered parts. A file whose name departs from the naming convention is rejected as a whole. Uploads take place every two weeks, unless another frequency is agreed with ESMA’s technical provider for MIDAS and the authorities.

STEP 1
Onboarding request
The CASP writes to ESMA’s MIDAS support and provides its IP addresses and SSH keys.
STEP 2
Testing
The CASP uploads a sample, then the full data set, to a test environment.
STEP 3
Go-live
Once the AMF has approved, the CASP receives production access and starts uploading on the agreed date.
STEP 4
Uploads and checks
Three levels of validation: transmission, file structure and the content of each record.
STEP 5
Feedback file
MIDAS places a feedback file on the CASP’s server, with no email or other notification.

The feedback file is the only source of information. A rejected record is not kept: a CASP that does not read its folder may believe it is compliant while its data have never been taken into account. The timing of this feedback calls for caution, as the instructions contradict themselves: they first announce it within two hours as a rule, then provide for a single file per CASP per day, produced once all the day’s uploads have been processed.

Duplicate checks run against the whole MIDAS history: a file sent again unchanged without at least three business days’ notice to support is discarded. A record already accepted is corrected by a new submission, announced to support before upload.

Which data errors should be fixed first?

What we see in practice is that data quality is still approximate: CASPs have only just set up their record-keeping processes, and MIDAS will make their gaps visible. The instructions leave it to the AMF to decide how to follow up an alert or a data quality issue.

Automated checks focus first on:

  • the timestamp, expected to the millisecond in a single format throughout the file, with a high share of midnight timestamps flagged;
  • the DTI, checked against ISO 24165-2, and official currencies, checked against ISO 4217;
  • the trading platform code, checked against the ISO 10383 list, except where the XOFF and XXXX codes apply;
  • prices, where a gap of 1,000% or more between two consecutive executions on the same pair is flagged;
  • for trading platforms, the share of cancelled orders, the balance between buys and sells and the distribution of order statuses, compared with the CASP’s history.

How should a CASP prepare before the AMF’s request?

In our view, nothing requires a CASP to request onboarding before the AMF sets its timetable. Waiting for that signal to start development work, however, risks not being ready on the date set. Preparation involves six workstreams:

  1. map, service by service, the transactions and orders to report, including back-to-back trades and orders routed outside the Union;
  2. clean up reference data: the DTI of each crypto-asset, the MIC codes of the platforms used, ISO currency codes and the CASP’s LEI;
  3. generate the JSON files from the source systems and validate them against ESMA’s schemas before any upload;
  4. organise file splitting and naming, and keep a copy of what has been uploaded;
  5. automate the collection of feedback files, the analysis of rejections and the resubmission of corrected records;
  6. review the market abuse detection procedure (Article 92 of MiCA; Commission Delegated Regulation (EU) 2025/885), to handle a MIDAS alert on behaviour that the internal system did not detect.

The same transaction records also feed the DAC8 tax reporting that CASPs have been collecting since 1 January 2026, so the work on reference data serves both.

To check that your records will pass MIDAS validation: MiCA compliance support for authorised CASPs.

What remains uncertain?

Still open:

  • the act by which the AMF will make reporting mandatory for each CASP, and therefore the breach that a failure would constitute;
  • how to handle a period with no transactions, for a CASP that executes few or none;
  • how to report back-to-back trades executed on a platform established outside the Union;
  • the price to report for an exchange service paid through its margin, given that the reported price excludes commissions and other charges;
  • the timetable for later phases, which may include personal identifiers.

Preparing for MIDAS reporting?

We map the data flows to report service by service, review your records against the record-keeping RTS and the MIDAS fields, and update your market abuse procedure. We also assist you in your discussions with the AMF on the data collection timetable.

A question about your situation: speak with a partner.

MiCA compliance for authorised CASPs

MIDAS: frequently asked questions

MIDAS (MiCA Digital Assets Surveillance) is ESMA’s system that collects CASPs’ transactions and order books to calculate market abuse alerts. National competent authorities have delegated these tasks to ESMA and remain solely responsible for investigations and sanctions.

Not yet: the AMF has not set its data collection timetable. Each CASP goes live after a test phase and the AMF’s approval, on a date set for it. Preparing data extraction and testing now is the prudent course.

All CASPs send their executed transactions: timestamp, identifiers, price currency, DTI, side, quantity, price and trading platform. Trading platforms also send the full life cycle of each order in their order book.

Yes, in our view. The instructions provide for the XOFF code for a crypto-asset admitted to trading on a platform but exchanged outside it, and the XXXX code for a crypto-asset not admitted on any platform.

No, not in the first phase. The instructions exclude personal data, and buyer and seller are replaced by a default value. ESMA announces later phases that may include personal identifiers, with no date set.

No email is sent: the rejection appears only in the feedback file placed on the CASP’s SFTP server. A rejected record is not kept and is not used for surveillance.

We also advise CASPs on their anti-money laundering framework (AML/CFT compliance for CASPs in France) and on DORA (DORA for CASPs in France).

Sources: Regulation (EU) 2023/1114 (MiCA), Articles 68, 76, 92 and 94; Regulation (EU) No 1095/2010, Article 28; Commission Delegated Regulations (EU) 2025/1140, 2025/416 and 2025/885; ESMA, MIDAS reporting instructions (ESMA65-955014868-17690); ESMA, statement on MiCA data standards and formats (ESMA75-1303207761-6284).

Our latest posts
ESMA opinion non-MiCA stablecoins
Articles
7 November 2026
ESMA’s opinion on services linked to non-MiCA stablecoins
Articles
3 November 2026
Can the French tax authorities seize your crypto? The SATD explained
Urne transparente d’où s’échappe un bulletin rouge, illustrant la fuite du vote d’un jury exploitée sur un marché de prédiction
Articles
2 November 2026
Insider trading on Polymarket: what Ballon d’Or bettors risk