What MIDAS rejects — and what it means for your records

For most of MiCA's first year, record-keeping was something a CASP did for a future inspection. The records had to exist, be complete and be producible on request. Nobody read them on a schedule.

The MIDAS Reporting Instructions change that for a subset of those records. They are an 85-page technical document (ESMA65-955014868-17690), dated 21 October 2026, and they turn part of what a CASP keeps under Article 68(9) and Article 76(15) of MiCA into a feed that is validated every two weeks.

What MIDAS is, in one paragraph

MiCA gives supervision to national authorities, not to ESMA. But crypto markets are cross-border, and no single authority can watch them alone. So the national authorities signed delegation agreements under Article 28 of the ESMA Regulation and handed ESMA a set of tasks: collecting the data, checking its quality, calculating indicators of suspicious behaviour, and sending the resulting alerts back. The supervisory decisions stay national. A specialised provider, chosen by public procurement, runs the system. The data scope is a subset of what the record-keeping standard (RTS 2025/1140) requires, and ESMA says it will grow in phases.

The mechanics

• Cadence: files every two weeks by default, to a dedicated SFTP endpoint. A different frequency can be agreed.
• Format: plain-text JSON only. Anything else is rejected automatically. Each file is capped at 500 MB, and larger datasets are split into parts.
• Two file types: CryptoAssetRecordKeeping for executions (message auth.117) and CryptoAssetOrderBook for orders (auth.118), each validated against a JSON schema ESMA published in November 2025.
• Naming: <FileType>_<DDMMYYYY>_<partN>_<partM>.json, checked before a single record is read.
• Feedback: a CSV written to the CASP's SFTP response directory, typically within two hours. No email and no notification: ESMA recommends polling. The feedback files are kept for seven years.
• Onboarding: an email to MIDAS support, a kick-off with ESMA and the provider, a UAT endpoint, then production. It is open now.

Three levels of “no”

The document separates what kills a whole file from what kills one record and what only raises a flag.

File rejected, nothing processed. Two rules. FIL-101: the name does not match the convention. FIL-102: the file is not valid JSON, or it breaks the published schema anywhere. One malformed record inside a 300 MB file means the whole file comes back, and you resubmit it in full.

Record rejected, the rest processed. Sixteen rules, MET-001 to MET-016: missing mandatory values, wrong data types, values out of range, zero or negative quantities and prices, duplicates, timestamp format drift, validity-period logic, and a cluster of dependencies around fills. You resubmit only the corrected records.

Warning. Eight qualitative checks, QUA-001 to QUA-008: field lengths, MIC and DTI validity against the ISO registries, cancelled-order and buy/sell ratios, isolated price prints 1,000% away from both neighbours, and a suspicious share of timestamps at exactly midnight.

Five things worth checking before your first submission

1. The timestamp format. The prose and Annex 1 describe YYYY-MM-DD HH:mm:ss.fff and give examples like 2026-03-15 14:25:36.125, with a space. The published JSON schema's date-time pattern requires a T between date and time. A file that follows the prose example fails the schema, which is FIL-102, which is the whole file. ESMA's own sample files use the T. Follow the schema. Then make sure every timestamp in a file uses the same mask with milliseconds: dropping the sub-second part on one record is MET-006 for that record.

2. The fill dependencies. Most record-level rules are about the relationship between status and trade fields. A transaction identification code must be present on FILL and PARF events and absent on every other status. Traded quantity and transaction price exist only when that code exists. A filled limit order needs both a limit price and a transaction price, and the fill must sit inside the limit. These are easy to get wrong when the order book and the trade log live in different systems and are joined late.

3. Duplicates are checked against history. Not just within the file. If an operational problem forces you to resend an unchanged file, ESMA asks for at least three business days' notice; otherwise the records are treated as duplicates and dropped. A correction to an accepted record goes in as a new record in the next feed, with advance notice to MIDAS support.

4. Silence is not acceptance. A rejected file produces a feedback file, not an email. If nobody polls the response directory, the first sign of trouble may be a gap your authority notices before you do.

5. Do not copy the sample file names. Annex 4 attaches samples named CryptoAssetRecordKeeping_21052026_part1.json. That name fails the convention in section 3.3, which wants _1_1.

What happened when we ran ESMA's own samples

We wrote the published rules into a checker and pointed it at the two sample files ESMA published with the instructions.

The record-keeping sample, 637 executions across ETH/USDC, HYPE/USDC and RAY/USDC, passes the schema and every record-level rule.

The order-book sample is 40 order events. Read literally, 16 of them would be rejected:

• 14 under MET-013. One order is classified as a limit order (LMTO), but every one of its fills reports the limit price as “no price”. The rule says a filled limit order needs a limit price.
• 3 under MET-008 (one overlaps with the above). Three orders end — filled or cancelled — at exactly their validity time. The rule says the validity time must come after the event time. Equal is not after.
• 4 warnings under QUA-006. New and cancelled orders carry a segment MIC without a transaction identification code. MET-011 names the segment MIC in its title but, in its outcome column, rejects only on traded quantity and price; QUA-006 makes the MIC case a warning. We report it as a warning.

This is not a criticism of ESMA. A sample shows structure, not conformance, and nobody expects a demonstration file to be a test fixture. But it is useful in two ways. It shows that the rules have edges you only find by running them. And it suggests where to ask questions during UAT: is MET-008 strict or inclusive? Does an LMTO fill without a limit price really reject? Better to know before the first production cycle than from the first feedback file.

What this changes for a CASP

Three things, in order of how often we expect them to bite.

Ownership. Somebody has to own the mapping from the matching engine and the custody ledger to auth.117 and auth.118, and keep it working every two weeks. In many firms that falls between compliance, which owns the obligation, and engineering, which owns the data. The feedback file lands in neither team's inbox.

Validation before submission, not after. ESMA itself says CASPs should verify their data against the schema before submission. The rejection rules are public, so they can run on your side, on every file, before it leaves. A rejected record you caught is a fix. A rejected record ESMA caught is a data-quality history.

The record is now evidence in motion. Under MiCA, records exist so that authorities can check what a CASP did. MIDAS makes part of that check continuous. The same discipline we apply to AI systems in regulated workflows — prove it from the record, not from intent — now applies to the order book.

The checker, free

We published the checker as a page: MIDAS pre-check. Drop your CryptoAssetRecordKeeping or CryptoAssetOrderBook files and it runs the naming rule, the official schemas, the MET rules and the QUA checks, and gives you a CSV in the layout of ESMA's feedback file. Everything runs in your browser; nothing is uploaded. Or open it with ESMA's order-book sample already loaded to see the findings above. The same engine runs from the command line, and as a gate in CI, from github.com/intellectumlab/midas-precheck (Apache 2.0).

For the half software can’t check — who owns the mapping, who polls the feedback folder, how corrections and resubmissions work, what to ask in UAT — there is a two-page MIDAS readiness checklist (22 items, free PDF).

What it does not prove: it is our reading of public rules, not ESMA's validator. It does not query the MIC or DTI registries, it cannot see your submission history, and where ESMA does not publish a threshold (midnight timestamps, order ratios) we chose one and say so. A clean result is a good sign, not a guarantee.

Sources

• ESMA, Reporting Instructions — MIDAS System, ESMA65-955014868-17690, 21 October 2026, with the record-keeping, order-book and feedback-file samples. ESMA MiCA page.
• ESMA, MiCA order book and records keeping message specifications, ESMA65-955014868-15160, November 2025, including the auth.116, auth.117 and auth.118 JSON schemas.
• Commission Delegated Regulation (EU) 2025/1140 (record-keeping RTS); Regulation (EU) 2023/1114 (MiCA), Articles 68(9), 76(15) and 94.