ESMA MIDAS Reporting Instructions: The CASP Feed and Its Feedback File

ESMA’s MIDAS reporting instructions (ESMA65-955014868-17690, dated 21 October 2026) set out how crypto-asset service providers feed the MiCA Digital Assets Surveillance system, the EU-level system that runs detection algorithms on crypto-asset trading data and generates market abuse alerts for national competent authorities (NCAs). Article 68(9) of MiCA imposes a record-keeping obligation, while Article 94 provides the competent-authority information-request powers. The instructions state that executed-transaction data is mandatory for all CASPs within the Article 68(9) obligation and that order-book data is mandatory for CASPs operating a trading platform for crypto-assets. They specify JSON files delivered over SFTP every two weeks, with a different frequency possible by agreement with the MIDAS provider and the NCAs. ESMA’s MiCA page states that CASP onboarding is open. The applicable transmission scope, commencement date and submission procedure for a given CASP follow from its competent authority’s collection arrangements together with the instructions.

The operational stakes sit in Annex 5 of the document. A record that fails validation is not held in MIDAS and will not appear in any surveillance output, and the feedback file is the only channel that tells the CASP it happened. MIDAS sends no email and raises no alert when that file lands. A firm that uploads on schedule but never parses the feedback CSV could carry a hole in its supervisory data for as long as nobody reads it.

Related reading: MiCAR Reporting Obligations

Dates and documents behind the MIDAS feed

The instructions sit on top of two technical standards and a message specification that ESMA published a year earlier. The reference points worth keeping in the project file:

• 3 April 2025: Commission Delegated Regulation (EU) 2025/416, the order-book RTS, entered into force and applies from that date.
• 30 June 2025: Commission Delegated Regulation (EU) 2025/1140, the record-keeping RTS, entered into force and applies from that date.
• 28 November 2025: ESMA published the MiCA order book and records keeping message specifications (ESMA65-955014868-15160). ESMA’s MiCA page records the NCAs’ expectation that they would start requesting data in the new JSON format within six months of that publication, a window that ended in May 2026.
• 21 October 2026: cover date of the MIDAS Reporting Instructions, which ESMA’s MiCA page lists together with a record-keeping JSON file, an order-book JSON file and a sample feedback file in CSV.

No EU-wide start date appears anywhere in the instructions. Each CASP moves its feed to production after its own NCA approves the release, and uploads then begin on a set date.

Where the MIDAS reporting instructions sit in MiCA

The instructions anchor MIDAS in three MiCA provisions. Article 94 gives NCAs the power to require any person to provide information and documents relevant to their duties. The instructions read it together with two record-keeping duties. Article 68(9) requires CASPs to arrange for records of all crypto-asset services, activities, orders and transactions, sufficient for competent authorities to supervise and enforce, kept for five years and for up to seven where the competent authority asks before the five years run out. Article 76(15) requires CASPs operating a trading platform to keep at the disposal of the competent authority, for at least five years, the relevant data on all orders advertised through their systems, or to give the authority access to the order book. RTS 2025/1140 specifies the first set of records; RTS 2025/416 specifies the content and format of the second.

The institutional set-up explains why an ESMA document carries a CASP obligation. NCAs remain responsible for supervising authorised CASPs and for market-abuse investigations and enforcement in their jurisdictions, while ESMA operates MIDAS under delegated arrangements. ESMA also has specific statutory powers under MiCA, including those provided by Article 110(5) in defined cases concerning non-compliant entities. The NCAs delegated tasks to ESMA through Delegation Agreements under Article 28 of the ESMA Regulation, Regulation (EU) No 1095/2010: collecting the data, processing it, running quality checks, calculating alerts and distributing those alerts back to the relevant NCAs. ESMA contracted a specialised third-party provider for the delegated project after a public procurement. The NCA still decides whether an alert or a data quality issue leads anywhere.

Calling this feed “MiCA transaction reporting” imports the wrong mental model. In its October 2023 consultation paper on the second MiCA package, ESMA observed that MiCA contains no transaction reporting obligation equivalent to Article 26 MiFIR and that the Article 68(9) records would be the main information source for competent authorities. A footnote in the MIDAS instructions makes the same point in its own terms: “reporting” there describes submitting data in response to requests from competent authorities. Teams arriving from MiFIR transaction reporting will recognise the ISO 20022 lineage, the MIC and the timestamp rules. The cadence, the scope and the legal trigger are different.

MIDAS also takes only part of what CASPs record. The first phase collects a limited set of on-chain and off-chain data elements needed for EU-level market abuse monitoring. It excludes personal data, non-public CASP transaction and supervisory data, and information gathered for enforcement or investigations, with suspicious transaction and order reports (STORs) and requests for information named as examples. The Delegated Project Board later widened the subset to pre-trade fields: order side, buy or sell indicators and order quantities, including cancellations. Future phases are to add supervisory data, personal identifiers included, where supervision requires it.

My reading is that STORs keep their own route to the competent authority, since the instructions place them outside the first phase and say nothing about replacing them; our MiCAR STOR reporting guide covers that filing. The full record-keeping duties under Articles 68(9) and 76(15) also stay exactly where they were. MIDAS draws a defined subset from records that still have to exist in full.

Executions for every CASP, order books for trading platforms

The instructions split the feed into two message types. Executions (record keeping), message auth.117, is stated in section 1.2 of the instructions to be mandatory for all CASPs under the Article 68(9) record-keeping obligation, with fields taken from Table 3 of the Annex to RTS 2025/1140. Order book, message auth.118, is mandatory only for CASPs operating a trading platform for crypto-assets, with fields taken from Table 2 of the Annex to RTS 2025/416. A trading platform therefore submits both. A broker or an exchange-for-funds service without a platform submits executions only.

MiCA permits crypto-asset services through Article 63 CASP authorisation or, for eligible financial entities, the Article 60 route subject to its conditions. Our guide to the end of the MiCA transitional period on 1 July 2026 covers providers that lost the grandfathering cover.

The leg rule is where platform and non-platform CASPs part ways. A trading platform puts both matched sides of a trade into one execution record, with the Buyer and Seller objects both populated, and a record missing either side is rejected. Every other CASP includes only its own buy or sell leg. Annex 4 says it plainly: the sample execution file shows both legs, as a trading venue would report them, and a broker dealer would report one of the two.

The field called Buyer / Seller identification code invites the wrong build. Its name suggests an LEI or a national client identifier, and RTS 2025/1140 does deal with client identification in separate articles. Under the first MIDAS phase the field carries a fixed code: the default value BUYI goes into the buyer element and SELL into the seller element, and the instructions state that buyer and seller identification elements are not to be reported for the purpose of deriving the side. This MIDAS-specific mapping is distinct from the statutory record-keeping requirement: Table 3, fields 6 and 15 of RTS 2025/1140 concern identification of the buyer and seller, and the CASP must continue to maintain the identification data that RTS requires. Mapping real client identifiers into that path could push personal data into a feed whose first phase excludes it.

For trading venues the side rule also feeds a file-level test. Across a submitted execution file, the count of buy and sell trades must sit within plus or minus 0.1% of each other. The worked example in Annex 5 shows what a breach looks like: 620 BUYI against 17 SELL out of 637 records, which the instructions read as only one leg of each trade reaching MIDAS.

What the files carry, field by field

The execution field list below identifies ten separately numbered fields from Table 3 of RTS 2025/1140, grouped into nine data categories: Trading date time [3.27], Transaction Record Number [3.2], the trading platform transaction identification code [3.3], Price Currency [3.32], Crypto Asset Identification Code [3.38], the buyer and seller side elements [3.6 and 3.15], Quantity [3.29], Price [3.31] and Trading platform for crypto-asset [3.33]. The order-book file has 18 business fields tied to Table 2 of RTS 2025/416. The ones tested by the order-book consistency rules MET-009 to MET-015 are Status, with its 13 four-letter event codes from NEWO through FILL; Transaction identification code; the three quantities (initial, remaining, traded); and the pair of Limit price and Transaction price.

The venue field follows MiFIR-style MIC logic with two crypto-specific defaults. A transaction executed on a trading platform uses the ISO 10383 segment MIC, or the operating MIC where no segment MIC exists. XOFF covers crypto-assets admitted to trading, traded on a platform or subject to an admission request, where the transaction itself was not executed on a platform. XXXX covers crypto-assets with no admission, no platform trading and no request. In the execution file the field must always be populated.

Price conventions follow the RTS wording. Price Currency is a pair, base first and quote second, using the ISO currency code for fiat and the DTI short name registered under ISO 24165-2 for a crypto-asset, or the alternative identifier allowed by Article 15 of RTS 2025/1140. Price expresses the quantity of the quote currency for one unit of the base currency, in the major currency unit where it is monetary, and in decimal notation of whole units even where the crypto-asset trades in sub-components. The sample pairs in Annex 4 (ETH/USDC, HYPE/USDC, RAY/USDC) show the format.

The extra JSON fields that alerts never use

Section 3.4.2 lists fields that MIDAS does not process for alert generation and does not yet run content checks on: the buyer and seller branch indicators in the execution file, and in the order-book file the reporting entity LEI, the report header date, the report identification, the order book identification, the sequence number and the trading capacity (DEAL, MTCH or AOTC). Five more order-book elements are fixed at NOAP, among them the client exception identification and the pending stop, additional limit and pegged prices.

“Not used for alerts” reads like “optional”, and that reading costs a whole file. The fields are required by the message specification and the JSON schema, and the instructions state that any submission omitting them fails schema validation and is rejected. A schema failure is FIL-102, which discards every record in the file. The instructions also flag that dedicated content rules for these fields will arrive in future releases.

Two points the text leaves open

The Price field description says the value shall be NOAP where a price is not applicable, while the validation rules for the same field require a value that is not null and greater than zero, and MET-004 rejects zero or negative values in strictly positive fields. Separately, the trading platform transaction identification code is mandatory “only if MIC code is populated in the venue field”, yet the venue field is always populated, sometimes with XOFF or XXXX. The instructions do not say whether those two codes count as a populated MIC. Both questions decide whether an off-platform execution file passes, and the document does not settle either.

File names, size limits and the two-week cadence

All submissions are plain-text JSON in UTF-8, pre-validated by the CASP against the published schema. No single file may exceed 500 MB; larger datasets are split into parts, and the onboarding section adds that processing runs more efficiently when parts are roughly equal in size, ideally 50 to 300 MB, than when a dataset arrives as many small files. Files go to a designated SFTP location every two weeks.

The naming convention is strict and checked on upload: FileType, then the date in DDMMYYYY, then partN, then partM, separated by underscores and ending in .json. FileType is CryptoAssetRecordKeeping or CryptoAssetOrderBook. The date is the record-keeping date the data refers to. PartN counts up from 1 and resets for each date; partM gives the total number of files for that FileType and date, so a single-file submission ends in _1_1 and a three-part one runs from _1_3 to _3_3. A wrong date format, a missing part number, an unrecognised FileType or the wrong extension triggers FIL-101 and rejects the file before its contents are read. The sample feedback file includes exactly that case: a file named CryptoAssetRecordKeeping_06082026_1_1.csv, rejected on its extension, which would have been accepted for processing as .json.

Two date formats sit side by side in this process. Submitted files carry the data date as DDMMYYYY. Feedback files are named [CASP NAME]_MIDAS_Feedback_File_yyyymmdd.csv, and that date is the day MIDAS processed the batch. A script that parses one with the other’s pattern will mis-date the feedback silently.

The naming section also shows “incomplete submission” examples, a three-part set with part two missing, next to a statement that MIDAS requires complete submission. Annex 3 has no rule code for a missing part, and every feedback row is tied to a file MIDAS actually received. I read this as putting part-count reconciliation per FileType and date on the CASP’s side, because the published rule set gives no code that would report a part that never arrived.

How MIDAS validates: FIL, MET and QUA rules

Validation runs in three layers, and each layer has its own consequence. The two transmission and file rules, FIL-101 (naming) and FIL-102 (schema), reject the whole file and no record in it is processed. The 16 content rejection rules, MET-001 to MET-016, reject the individual record while the rest of the file is processed. The eight qualitative rules, QUA-001 to QUA-008, raise warnings and leave the record in MIDAS. Of the 26 published rules, 12 apply to both message types, 13 to the order book only and one, the price outlier check QUA-005, to executions only.

The rules that bear most directly on whether a feed passes validation:

• Timestamps. RTS 2025/416 defines its date-time format as an ISO 8601 UTC timestamp with six fractional-second digits, while Annex 1 of the MIDAS instructions defines the date-time type as YYYY-MM-DDThh:mm:ss.dddddd (UTC) or YYYY-MM-DD HH:mm:ss.fff, so the mask a CASP’s adapter expects should be confirmed in onboarding. Under the instructions, all date and time values are expected at millisecond precision, and each CASP’s ingestion adapter is configured to one format. A record that drops the sub-second part, YYYY-MM-DD HH:mm:ss where the adapter expects YYYY-MM-DD HH:mm:ss.fff, is rejected under MET-006. A significant share of midnight timestamps in a file triggers the QUA-008 file warning.
• Positive values. Quantity, Price and Initial quantity must be greater than zero (MET-004). Remaining quantity and Traded quantity may be zero but never negative.
• Fill logic in the order book. Transaction identification code is populated if and only if Status is FILL or PARF (MET-009, MET-010). Traded quantity and Transaction price stay empty when there is no transaction identification code (MET-011). Neither traded nor remaining quantity may exceed the initial quantity (MET-012, MET-014). For a filled limit order, a buy may not execute above its limit and a sell may not execute below it (MET-015).
• Validity. A Good-Till-Date order (GTDV) needs a Validity period and time (MET-007), and that timestamp must fall after the order’s Date and time (MET-008).
• Reference data. A MIC that does not resolve against ISO 10383 is a warning (QUA-002), and so is a DTI that does not resolve against ISO 24165-2 (QUA-003). An empty DTI field is a different matter: the sample shows it rejected as a missing mandatory field under MET-001.
• File-level ratios. QUA-004 checks that cancelled orders fall between 5% and 95% of total orders, that the order buy and sell split is not extreme (the example given is more than 90% buys) and, for trading venues, the 0.1% execution balance described above. QUA-005 looks for a variance of 1,000% or more between consecutive execution prices in the same price currency and platform, and flags a price that departs from both neighbouring executions while those neighbours agree with each other.

The body text also describes a comparison of each file’s mix of Status values against the CASP’s own reporting history, flagging files where a normally present status goes missing. That check has no code of its own in Annex 3. In ESMA’s sample feedback file it appears only inside the QUA-004 ValidationReason text, which says the file’s Status mix is also compared against the CASP’s own historical reporting pattern; the instructions say that column is not a stable parsing target.

Warnings carry no resubmission duty, which makes them easy to file and forget. They are also where upstream capture failures show first: a one-leg feed under QUA-004, defaulted timestamps under QUA-008, a price feed glitch under QUA-005. The corrective actions published for those three codes all point at the upstream source, and none asks for the file to be corrected.

Reading the MIDAS feedback file without miscounting

Annex 5 describes one feedback file per CASP per day, produced once MIDAS has processed everything that CASP submitted in that day’s cycle and covering both message types. Six part files for one date produce one feedback file; an execution file and an order-book file sent on the same day produce one feedback file. It lands on the same SFTP endpoint the CASP submits to, nothing announces it, and the instructions recommend an automated polling job on a fixed interval. It stays in that folder for seven years.

Section 3.5.3 in the main body describes the delivery differently: a feedback file generated after each uploaded file, typically within two hours of receipt, written to a “response” directory. Annex 5 puts the file in the same root folder where submissions are deposited. The document does not reconcile the two descriptions, so a poller that watches both locations and expects several submissions per feedback file covers either reading until onboarding confirms the actual behaviour.

The file itself is CSV, UTF-8, comma-delimited with RFC 4180 quoting, one header row and 17 columns in fixed order. SubmittedFileName is the only column that ties a finding to the file it came from. RecordRef carries the Transaction Record Number for executions and the Order identification code for order-book records. JSONLineNumber gives the opening line of the record object in the submitted file, which is why the instructions recommend pretty-printed JSON: a minified file, with the whole document on one line, returns 1 on every row.

The governing principle is one row per finding. A record that breaches three rules produces three rows with the same RecordRef and line number. Records that breach nothing are reported as a single aggregate row carrying the accepted count. The instructions give the reconciliation formula: total records submitted equals the accepted-without-warning count, plus the number of distinct records accepted with a warning, plus the number of distinct records rejected. Counting rows overstates the rejected population, and RecordRef alone is not unique in the order book, where every event in an order’s life shares the same code. The grouping key for automated handling is SubmittedFileName plus RecordRef plus JSONLineNumber.

Three parsing rules in Annex 5 decide whether automated handling works. An empty cell and a hyphen mean different things: empty says the field was absent or null in the submission, which on a mandatory-field rule is the finding itself, while a hyphen says the column does not apply to that row. Any other string is literal data, including values that look like placeholders; the sample reports a SubmittedValue of N/A on a MET-002 row because a CASP put that text into a numeric price field. And the stable contract covers the column set, the ErrorCode and Label values and the enumerations of FeedbackType, FileVerdict, Outcome, Severity and AppliesTo. The wording of ValidationReason and CorrectiveAction and the row order sit outside that contract, and the instructions say not to parse them.

The published sample covers four submitted files and fires all 26 rules plus one accepted-record row. Its values are constructed and unrepresentative of a real submission. As a parser test fixture it still exercises every row shape the specification allows.

Corrections, resubmissions and the duplicate check

The correction cycle in section 3.5.4 has four steps: review the feedback file after every submission, identify each rejected record and the rule it broke, fix the problem at source, then resubmit. Record-level rejections are resubmitted as the corrected records only; a file-level rejection is resubmitted as the corrected file in full. Where a record fails several rules, every finding has to be cleared first. The Annex 5 walkthrough shows one order-book record producing eight rows, six rejections and two warnings, and notes that fixing one and resubmitting simply returns seven findings on the next cycle.

The duplicate check matters for any team used to “resend the day” as a recovery step. MIDAS checks duplicates against its entire historical database, using the keys in the comparison table above; for replaced orders with the same exact transaction time, Initial quantity and Limit price are also compared. MET-005 is the one rejection that calls for no resubmission, because its existence proves the original was accepted. Warned records follow the same logic: the instructions state that resubmitting a record accepted with a warning causes it to be rejected as a duplicate.

Two situations need advance contact with MIDAS support at support@esma.europa.eu, using a subject line built as [MIDAS][CASP][CASPName][Topic:Operations xxxx]:

• Correcting a record MIDAS already accepted, such as a fat-finger price. The correction goes in as a new record in the next data feed, the CASP gives advance notice of the records to be overridden, and MIDAS keeps the prior version for audit purposes.
• Resubmitting an unchanged file after an operational issue. The instructions ask for at least three business days’ notice identifying the files concerned. Without it, the records are treated as duplicates and dropped.

Annex 5 adds a third case and a different format. Its triage order says a CASP resubmitting a file that came back FILE_REJECTED must notify the support desk, using a header that strings MIDAS, CASP, the CASP name and the topic together with hyphens in place of the bracketed tags, and describes this as the same channel used for corrections under section 3.5.4. Section 3.5.4 itself does not list file-level resubmissions among the notification cases.

Onboarding: SFTP access, UAT and the NCA sign-off

A CASP starts onboarding by emailing support@esma.europa.eu with the subject [MIDAS][CASP][CASPName][Topic:New Onboarding Request], listing the email addresses of the team members involved, the IP addresses it will upload from and its public SSH keys. ESMA and the relevant NCAs oversee the process and the MIDAS system provider runs it, starting with a meeting that sets up a separate technical channel for the project.

The stages are fixed. The provider whitelists the CASP’s IP addresses and provisions two dedicated SFTP endpoints, one for user acceptance testing (UAT) and one for production; uploaded files land in a private AWS S3 bucket and are collected automatically for ingestion. The CASP prepares a small representative sample covering its common trades and asset types and uploads it to UAT, where the provider and the CASP work through validation and error handling together. Testing with the full dataset follows. Questions about the instructions themselves go to the same address with [Topic:Reporting Instructions] in the subject.

Production depends on the NCA. Once UAT succeeds, the MIDAS provider receives approval from the CASP’s relevant NCA to move the feed to production, then communicates the production endpoint, and the CASP begins uploading on a set date.

Frequently Asked Questions

We provide custody and transfers only and execute no trades. Do we send an empty file?

A CASP should not assume that the absence of buy and sell trades means it has no transactions to record. Article 1, point (3)(e) of RTS 2025/1140 lists the transfer of crypto-assets to or from accounts among the services and activities that fall within executing a transaction when they result in a transaction. A provider offering custody and transfers should therefore assess whether its activities generate transaction records before treating a reporting period as nil. The instructions state that the executions file is mandatory for all CASPs under the Article 68(9) obligation, describe no nil return, and refer to each file containing at least one record. Whether such transfer records fall within the MIDAS surveillance extract, and how a genuinely nil period is handled, should be confirmed with the relevant NCA and with MIDAS support under [Topic:Reporting Instructions] during onboarding.

Does a two-week cadence mean one file per fortnight?

The file name carries a single data date, part numbers reset for each date, and the order-book report header date is limited to a single date. My reading is that a fortnight’s data goes up as a set of per-date files, each with its own part sequence. Another frequency can be agreed with the MIDAS provider and the NCAs; with daily uploads, the one-file-per-processing-day design means each day’s uploads come back in their own feedback file.

One of our listed tokens has no DTI yet. Will its records bounce?

A DTI that does not resolve against ISO 24165-2 produces the QUA-003 warning and the record is accepted. Leaving the field empty is a MET-001 rejection. ESMA’s 28 November 2025 statement on MiCA data standards says CASP trading platforms should retrieve the DTI from the DTIF registry where no white paper exists and, if none is available, request its creation through the DTIF.

The feedback file is kept for seven years. Does that change our MiCA retention period?

The seven years describe how long MIDAS leaves the feedback file in the CASP’s SFTP folder, stated as the same period as the records and orders it relates to. MiCA sets the CASP’s own duty: Article 68(9) requires five years, extended up to seven where the competent authority asks before the five years elapse, and Article 76(15) requires at least five years for order data. The instructions do not amend either article.

If MIDAS has our data, can we answer an NCA information request by pointing to it?

The instructions keep requests for information outside the first phase and leave every follow-up decision with the NCA, including whether to request additional information. MIDAS holds a subset of fields with no personal data, so I read an NCA request for the full records under Article 68(9) or 76(15) as something the CASP still answers from its own record-keeping.

We are authorised in one Member State and passport elsewhere. Which NCA signs off production?

The instructions refer only to the CASP’s “relevant NCA” approving the move to production and do not address cross-border cases. They also state that onboarding is overseen by ESMA and the relevant NCAs, plural. The onboarding meeting is the natural point to confirm which authority gives that approval.

Related Articles

• MiCAR Reporting Obligations: the wider set of reporting duties that CASPs and token issuers carry under MiCA.
• MiCAR STOR Reporting: How CASPs File Suspicious Transaction and Order Reports Under Article 92: the market abuse notification route that sits outside the first MIDAS phase.
• MiFIR Transaction Reporting: Complete Guide to Article 26 Compliance: the financial-instrument regime whose MIC, timestamp and ISO 20022 conventions MIDAS borrows.
• MiCA CASP Wind-Down: What Unauthorised Providers Must Do as the Transitional Period Ends on 1 July 2026: the authorisation cut-over for providers that relied on national grandfathering.

Key Takeaways

• Before UAT, map every MIDAS business field to its numbered field in RTS 2025/1140 Table 3 or RTS 2025/416 Table 2; the instructions give the reference for each business field.
• Populate the buyer and seller side elements with the BUYI and SELL defaults only; client identifiers stay out of the first phase.
• Treat the NOAP-coded and header fields as mandatory for schema purposes: omitting them is FIL-102 and costs the whole file.
• Fix one timestamp mask across every file before go-live, confirmed against the instructions and onboarding configuration; under the instructions, a single record without the millisecond part is a MET-006 rejection.
• Run the feedback poller from the first UAT upload and key it on ErrorCode or Label, never on the reason text or row order.
• Keep a resubmission log against the MIDAS duplicate keys: MET-005 rows and warned records are never resent, and an unchanged file replay needs three business days’ notice.
• Reconcile part counts per FileType and data date on your own side; no published rule reports a part MIDAS never received.

Sources and References

• ESMA, Reporting Instructions, MIDAS System, ESMA65-955014868-17690 (21 October 2026): MIDAS Reporting Instructions (PDF)
• ESMA, MIDAS feedback file sample, ESMA65-955014868-17734: MIDAS Feedback File Sample (CSV)
• ESMA, MIDAS crypto-asset record keeping JSON, ESMA65-955014868-17735: MIDAS CryptoAssetRecordKeeping (JSON)
• ESMA, MIDAS crypto-asset order book JSON, ESMA65-955014868-17736: MIDAS CryptoAssetOrderBook (JSON)
• ESMA, Markets in Crypto-Assets Regulation (MiCA) page, sections on MIDAS and MiCA order book and record keeping: ESMA MiCA page
• ESMA, MiCA order book and records keeping message specifications, ESMA65-955014868-15160: Message specifications
• ESMA, Statement to support the smooth implementation of MiCA data standards and format requirements, ESMA75-1303207761-6284 (28 November 2025): ESMA statement (PDF)
• Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA), Articles 68, 76 and 94: EUR-Lex
• Commission Delegated Regulation (EU) 2025/1140 of 27 February 2025 on records to be kept of all crypto-asset services, activities, orders and transactions undertaken (OJ L, 2025/1140, 10.6.2025): EUR-Lex
• Commission Delegated Regulation (EU) 2025/416 of 29 November 2024 on the content and format of order book records for CASPs operating a trading platform for crypto-assets (OJ L, 2025/416, 14.3.2025): EUR-Lex
• Regulation (EU) No 1095/2010 establishing ESMA, Article 28 (delegation of tasks), consolidated version cited by the instructions: EUR-Lex
• ESMA, MiCA Consultation Paper, second package of technical standards, ESMA75-453128700-438 (5 October 2023): Consultation paper (PDF)

Before the first MIDAS upload

The instructions leave each CASP’s start date to its own onboarding, so the timetable begins with one email to support@esma.europa.eu under [Topic:New Onboarding Request], carrying the team contacts, upload IP addresses and public SSH keys. Behind it sit the pieces UAT will test: a representative JSON sample built against the published schema, a fixed millisecond timestamp mask, the BUYI and SELL side defaults, a feedback poller tested on the ESMA sample CSV, and written answers from MIDAS support on the NOAP price and XOFF transaction-code questions. Production follows only after the CASP’s NCA approves the release.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.