MiCA Compliance: Verifying ESMA JSON Transaction Records

Regulators do not forgive gaps in the record. When a National Competent Authority (NCA) requests your order-book data for a specific 48-hour window from eight months ago, "we have it somewhere" is not an acceptable answer. Under the Markets in Crypto-Assets regulation, that answer can cost your CASP its operating license.

MiCA entered into force in June 2023 and became fully applicable to Crypto-Asset Service Providers across the EU in December 2024. It is the most thorough crypto-regulatory framework any major jurisdiction has produced, and its record-keeping obligations are precise, demanding, and non-negotiable.

Most compliance teams initially underestimate the scope. Before getting into technical mechanics, let's be direct about what the law actually requires.

MiCA Article 68 establishes the core record-keeping obligation for CASPs. It requires that your firm keeps all records of its services, activities, and transactions for at least five years. For transactions specifically, those records must be sufficient to enable the NCA to verify compliance with MiCA's conduct-of-business rules, including best execution, order handling, and conflict-of-interest management. This is not a data-retention policy you can satisfy with a backup drive and good intentions.

The legal basis matters because it defines the purpose of the records. You are not just storing data for your own operational use. You are creating evidence that your firm acted lawfully, treated clients fairly, and did not engage in market abuse. Every record is a potential exhibit.

RTS 2025/1140 is the Regulatory Technical Standard that operationalizes Article 68. It specifies what your records must contain, how they must be structured, and what your firm must be able to demonstrate about their integrity. Under RTS 2025/1140, your transaction and order records must capture:

RTS 2025/1140 also requires that your records be stored in a format that prevents unauthorized alteration, and that you can demonstrate this to an NCA on request. Storing data is necessary but not sufficient. Proving the data has not changed since it was first written is the actual obligation.

RTS 2025/416 addresses the specific technical format for order-book data submissions: machine-readable, schema-validated JSON that NCAs can process programmatically. This is the format your team will be working with day-to-day.

Two things are worth noting about the regulatory timeline. NCAs will begin issuing ad-hoc data requests and expecting periodic reporting submissions from mid-2026 onward. The five-year retention window means that records you create today will need to be verifiably intact in 2030. The window for getting your infrastructure right is narrowing.

For compliance teams and CTOs at CASPs, the question is no longer whether to comply. It is how to build infrastructure that makes compliance provable, repeatable, and defensible under audit.

The ESMA JSON schema for order-book records is not a suggestion. It is a technical contract between your firm and the regulator. Think of it less like a filing cabinet and more like a court transcript: every field is a sworn statement, and omissions are their own kind of testimony. Understanding its structure is the first step toward building a compliant reporting pipeline.

Under RTS 2025/416, every order-book record your team submits to an NCA must contain a defined set of data fields. At minimum, each record must capture:

The precision requirement on timestamps is not bureaucratic pedantry. It is the mechanism by which regulators detect front-running, wash trading, and market manipulation. A timestamp rounded to the nearest second is operationally useless for that purpose, and if your logging layer rounds timestamps, your submission will fail scrutiny even if every other field is perfect.

Here's the engineering challenge. At a high-volume exchange, maintaining this level of granularity across thousands of transactions per second cannot introduce latency into the trading engine itself. Your logging layer must be asynchronous, non-blocking, and capable of handling burst volumes without dropping records.

ISO 20022 messaging standards provide a reference framework for financial message structuring that informed parts of the ESMA schema design. If your team has a background in traditional financial market infrastructure, you will recognize the conceptual lineage, though the MiCA JSON schema is crypto-specific and not directly interchangeable with ISO 20022 formats.

Consistency across trading pairs is a frequently underestimated challenge. If your CASP offers 200+ trading pairs, you need to ensure that the same field names, data types, and encoding conventions apply uniformly across all of them. Schema drift, where different pairs are logged with slightly different field structures due to legacy code paths, is one of the most common sources of validation failures during regulatory submission. I have seen this catch teams off guard even when their individual pair implementations looked clean in isolation.

The practical implication: your team needs a canonical data model that sits between the raw trading engine output and the regulatory submission layer. Every internal log must be normalized to this model before archiving begins. Skip this normalization step and go straight from raw logs to submission, and you are betting that your trading engine's output format never drifts. That is not a bet worth taking.

A compliant MiCA reporting workflow is not a single export job. It is a multi-stage pipeline where each step introduces potential for data loss, transformation error, or integrity failure. Here is how your team should think about each stage.

Stage 1, Capture: Raw order events are written to an internal database or message queue at the point of execution. This is the T+0 record, the ground truth of what happened on your platform.

Stage 2, Normalization: Your pipeline transforms raw records to match the ESMA JSON schema. Field names are mapped, timestamps are standardized to UTC, identifiers are pseudonymized according to GDPR requirements, and data types are validated.

Stage 3, Validation: The normalized JSON runs against the ESMA schema definition. Validation failures at this stage, including missing required fields, out-of-range values, and malformed identifiers, must be caught and corrected before submission, not after. Build your validation step to fail loudly, not silently.

Stage 4, Archiving: The validated JSON export is written to long-term storage. This is where most CASPs introduce their first major compliance risk: they store the file, but they do not prove its integrity. More on this shortly.

Stage 5, Submission: When an NCA requests data, your team extracts the relevant records from the archive and submits them through the designated channel.

The concept of the "Golden Record" is central to this entire process. The Golden Record is the validated JSON file as it existed at the moment it was archived, the definitive state of the data at T+0. Any divergence between what was archived and what you submit to the NCA is a compliance failure, regardless of intent.

BaFin's MiCA guidance makes clear that your firm bears the burden of demonstrating that submitted records are authentic and unaltered. Saying "we stored it correctly" is not the same as proving it. In a regulatory examination, that distinction is everything.

Common pipeline failures your team should actively test for: timezone conversion errors that shift timestamps by hours, character encoding issues that corrupt identifiers, and batch-processing jobs that silently skip records during high-load periods. Each of these can produce a submission that looks valid but does not accurately represent the underlying trading activity on your platform.

NCAs are not passive recipients of data. They cross-reference submissions against market surveillance data, flag statistical anomalies, and issue follow-up requests. If your records cannot withstand that scrutiny, the consequences go well beyond a fine.

Here's the thing. Submitting a clean JSON file to an NCA today solves today's problem. MiCA's record-keeping obligations extend for five years from the date of each transaction, and what happens to your data over those five years is where most CASPs are underprepared.

Simple storage, writing files to an S3 bucket or a network-attached storage system, does not constitute compliant archiving. Storage proves that data exists. It does not prove that the data has not been modified since it was written.

The risks in cloud storage environments are well-documented. Silent data corruption, including bit rot, hardware failures, or software bugs that alter stored data without triggering alerts, is a real operational hazard at scale. More concerning for regulatory purposes is the risk of authorized-but-undocumented administrative changes: a database administrator corrects what appears to be an error, a migration script overwrites a field, a backup restoration replaces a newer version with an older one.

None of these events are necessarily malicious. All of them can render a five-year-old record non-compliant if your team cannot demonstrate the record's integrity at the time of original archiving.

This is where audit-proof archiving for MiCA compliance becomes operationally essential, not optional. An audit-proof archive does not merely store your data. It seals data at the moment of ingestion, creating a verifiable proof that the stored record matches the original exactly.

KRM (Kompetenzzentrum Records Management) standards and ISO 27001 provide the governance framework for information security and records management that underpins compliant long-term archiving. If your CASP operates in DACH markets, note that GoBD (Germany) and GeBüV (Switzerland) establish legal standards for electronic record-keeping that align closely with MiCA's intent. If your archiving infrastructure already satisfies those standards, you are well-positioned for MiCA, but you still need to close the integrity-proof gap that neither standard fully addresses on its own.

The gap between active reporting and immutable long-term storage is not a technical gap. It is a process gap. Closing it requires your team to define clear handoff points between the reporting pipeline and the archiving system, with integrity verification at every transition.

For compliance officers, this translates into one practical requirement: every file that enters your archive must carry a verifiable proof of its state at the moment of archiving. Without that proof, your archive is a liability, not an asset. And when an NCA comes knocking three years from now, you will want an asset.

The solution to the integrity problem is mathematically elegant and operationally straightforward: hash the file, timestamp the hash on a public blockchain.

This approach, what I call the "Integrity Wrapper," works as follows. When your validated ESMA JSON export is ready for archiving, you compute a SHA-256 cryptographic hash of the file. This hash is a unique 256-bit fingerprint of the file's exact contents at that moment. Change a single byte anywhere in the file, a timestamp digit, a quantity field, a client identifier, and the hash changes completely. There is no partial match, no fuzzy comparison. The hash either matches or it does not.

That hash is then anchored to the Bitcoin and Ethereum blockchains through a timestamping process. The blockchain entry creates an immutable, publicly verifiable record that a file with this exact fingerprint existed at this exact point in time. The blockchain does not store the file itself, only the hash. Your data never leaves your own infrastructure.

The result is mathematically provable data integrity that is entirely independent of any storage provider, any administrator, and any internal system. The proof lives on Bitcoin and Ethereum, two of the most resilient and widely audited public ledgers in existence.

This achieves digital sovereignty in a precise sense: your team can prove the integrity of your records without relying on any third party to vouch for them. When an NCA requests records from three years ago, you do not need to assert "our systems are trustworthy." You can demonstrate, cryptographically, that the submitted file is identical to the file that was archived on a specific date.

NIST's SHA-256 standard establishes this hash function as collision-resistant and suitable for data integrity verification, meaning that finding two different files that produce the same hash is computationally infeasible with current technology. This is not proprietary technology or a vendor claim. It is peer-reviewed, publicly audited cryptographic infrastructure.

The timestamping process also closes the backdating risk. Your team cannot produce a hash for a file created today and claim it was archived two years ago. The blockchain timestamp anchors the hash to a specific block height and time, which anyone can verify independently.

For CASPs building MiCA-compliant infrastructure, the Integrity Wrapper is not an add-on. It is the foundation of a defensible record-keeping posture. Everything else in your compliance stack depends on being able to prove that your records are what you say they are.

The Integrity Wrapper is only valuable if your team applies it consistently and automatically. A manual hashing process applied intermittently is not a compliance control. It is a liability waiting to surface during an audit.

Integrating timestamping directly into your reporting pipeline requires three components:

1. API-level integration: A timestamping API call is embedded as the final step of the archiving job. When your validated JSON file is written to storage, the hash is computed and submitted to the timestamping service in the same transaction. No human intervention required, no opportunity for the step to be skipped under operational pressure.

2. Proof Certificate generation: For every submission, your pipeline automatically generates a Proof Certificate, a structured document containing the file hash, the blockchain transaction ID, the block height, and the timestamp. This certificate is stored alongside the original file and serves as the audit artifact your team hands to an NCA or internal auditor.

3. Daily manifest aggregation: For high-frequency trading environments generating thousands of order-book snapshots per day, individual file timestamping can be supplemented by daily manifest files. A manifest lists the hashes of all files archived during a 24-hour period, and the manifest itself is timestamped. This approach reduces blockchain transaction volume while maintaining per-file verifiability, a practical trade-off worth discussing with your engineering team.

ETSI TS 101 733 provides the technical framework for electronic signatures and timestamp tokens that underpins this approach in European regulatory contexts.

The audit tax reduction is significant. When a regulator or internal auditor asks for evidence that a specific file was not altered between archiving and submission, your answer is a Proof Certificate. Not an explanation, not a chain-of-custody narrative, not a request to trust your systems. Verification takes seconds, and that is a meaningful operational advantage when you are responding to an NCA information request under time pressure.

This is the operational value of OriginVault's audit-proof archiving backend: it transforms a complex, multi-step integrity verification process into a single automated workflow that generates defensible proof at every step. Your compliance team stops explaining and starts demonstrating.

For compliance officers, the shift is from "we believe our records are accurate" to "here is mathematical proof that they are." That is not a subtle difference. It is the difference between passing an audit and failing one.

MiCA has established a new baseline for what it means to operate a compliant crypto-asset service in Europe. The European Commission's Digital Finance Strategy signals that this baseline will only rise. More granular reporting, shorter response windows, and deeper NCA scrutiny are the direction of travel. Your compliance infrastructure needs to be ahead of that curve, not catching up to it.

CASPs that treat MiCA compliance as a checkbox exercise, storing data and hoping it holds up, will find themselves exposed when the first serious audit arrives. CASPs that build verifiable, tamper-evident record-keeping infrastructure now will find that investment pays dividends well beyond regulatory compliance: faster audits, lower operational risk, and a credible data integrity posture that differentiates them in an increasingly scrutinized market.

The strategic shift is from reactive compliance to proactive data integrity. Every ESMA JSON export your team produces should be sealed the moment it is created. Every archival file should carry a blockchain-anchored proof of its state. Every NCA submission should be backed by a Proof Certificate that makes verification instantaneous.

This is not a future capability. It is available infrastructure today. As explored in our dedicated guide on proving data integrity under MiCA's record-keeping rules, the technical building blocks are mature, the regulatory requirements are clear, and the cost of inaction is rising.

The single source of truth that MiCA demands is not just a database. It is a tamper-proof, time-anchored, cryptographically verifiable record that no administrator can alter and no regulator can doubt.

If you are building or upgrading your CASP's compliance infrastructure, explore how OriginVault's white-label audit-proof archive handles the full lifecycle, from ESMA JSON ingestion to blockchain-sealed long-term storage, without adding operational complexity to your team.