Even under MiCAR, timestamps do not have email addresses
Why Article 3 of Commission Implementing Regulation (EU) 2024/2861 needs a corrigendum
Commission Implementing Regulation (EU) 2024/2861 determines how inside information must be disclosed and how a decision to delay disclosure must be documented and notified under the Markets in Crypto-Assets Regulation (MiCAR). Most of its architecture is coherent. Article 3 distinguishes between a comprehensive internal record of the delay process and a more concise notification to the competent authority. That distinction is familiar from the Market Abuse Regulation (MAR).
One part of Article 3, however, cannot be applied as written. In the procedure under which the written explanation for a delay is supplied only at the competent authority’s request, Article 3(3) requires the “identity and contact details” of persons referred to in Article 3(2)(e). Article 3(2)(e) does not refer to a person. It refers to the date and time of the decision to delay disclosure.
Even under MiCAR, timestamps do not have email addresses.
Issuers, offerors and persons seeking admission to trading must translate Article 3 into governance arrangements, notification forms, data fields and auditable workflows. They should not have to guess whether a provision means what it says, whether the reference to point (e) should instead be to point (f), or whether the request-only procedure was deliberately intended to demand more information than the ordinary procedure.
Let's see how the provision should be applied pending a formal correction.
1. The legal framework: disclosure is the rule, delay the exception
Article 88(1) MiCAR requires issuers, offerors and persons seeking admission to trading to inform the public as soon as possible of inside information that directly concerns them. Disclosure must enable fast access and a complete, correct and timely assessment by the public. The disclosed information must also remain available on the relevant entity’s website for at least five years.
Article 88(2) permits disclosure to be delayed on the entity’s own responsibility only where all three conditions are satisfied:
immediate disclosure is likely to prejudice a legitimate interest of the issuer, offeror or person seeking admission to trading;
the delay is not likely to mislead the public; and
the confidentiality of the information can be ensured.
These are continuing conditions. It is not sufficient for them to be satisfied only when the delay is initially approved. The entity must be able to monitor them throughout the delay and disclose the information once a condition is no longer met.
Article 88(3) then establishes two possible transmission regimes after the delayed information has been disclosed:
Under the default regime, the entity informs the competent authority that disclosure was delayed and immediately provides a written explanation of how the three conditions were met.
A Member State may instead provide that a record of the explanation is supplied only if the competent authority requests it.
The second option changes when the explanation is transmitted. It does not remove the need to make a reasoned delay decision, monitor the conditions or maintain a contemporaneous record capable of supporting a later explanation.
2. Why the internal record is broader than the notification
Article 3(1) of Implementing Regulation 2024/2861 requires the relevant entity to maintain, in an accessible and readable durable medium, a detailed record covering three categories of information.
First, it must record the relevant dates and times: when the inside information first existed, when the decision to delay was made, and when disclosure was expected.
Second, it must record the positions or functions responsible for deciding on the delay, monitoring the delay conditions, deciding on disclosure, and communicating with the competent authority.
Third, it must preserve evidence showing that the Article 88(2) conditions were initially satisfied and remained satisfied. This includes the information barriers used to protect confidentiality and the arrangements in place should confidentiality cease to be ensured.
Article 3(2), by contrast, lists a narrower dataset for the notification of the delay. It includes the identity of the regulated entity, the notifier and the relevant contact point; the identification and publication time of the delayed disclosure; the time of the delay decision; and the functions of the persons responsible for that decision.
The difference is not, in itself, an inconsistency. The two datasets serve different purposes:
Comprehensive internal record under Article 3(1) | Notification under Article 3(2) |
Establishes when the inside information first existed | Identifies the entity and the relevant disclosure |
Records the decision time and expected disclosure time | Records the decision time and actual publication time |
Allocates responsibility for decision-making, monitoring, disclosure and authority contact | Identifies the notifier, contact point and responsible functions |
Preserves evidence supporting all three delay conditions | Enables the authority to identify the case and calculate the duration of the delay |
Records changes in the conditions during the delay | Does not automatically transmit the complete evidentiary file |
The expected disclosure time is a forward-looking control datum. Once the information has actually been published, the actual publication time is more useful for the notification. The point at which the inside information first arose may be important in a supervisory investigation, but it need not be transmitted as part of every routine notification. Similarly, evidence concerning information barriers, monitoring and continuing confidentiality belongs in the audit trail and in the substantive explanation, not necessarily in every initial notification.
Recitals 7 to 9 of the Implementing Regulation reflect this division. Recital 7 addresses the recording of key information about the delay process; recital 8 distinguishes the notification from the explanation required in the applicable national regime; and recital 9 focuses on identifying the relevant persons and the duration of the delay for supervisory purposes.
This two-level structure also follows the MAR precedent. ESMA expressly explained that it had largely based its MiCAR draft on the MAR implementing standards in order to use the experience developed under MAR and streamline the two regimes.
3. The request-only explanation: repetition can be justified
Article 3(3) applies where a Member State has exercised the option under Article 88(3) MiCAR and the written explanation is therefore transmitted only when requested by the competent authority.
Its first sentence requires the later explanation to include the information listed in Article 3(2). Read in isolation, that might appear to impose a higher standard on the request-only route. In functional terms, however, the repetition is understandable.
Under the default regime, the authority receives the notification and the explanation together. Under the request-only regime, it receives the notification first and may request the explanation weeks, months or potentially years later. Repeating the notification metadata makes the later explanation self-contained and allows it to be linked unambiguously to the original disclosure and delay decision.
The total information was therefore presumably intended to be equivalent:
one combined package under the default regime; or
an initial notification followed, if requested, by a self-contained explanation under the alternative regime.
The MAR predecessor uses the same technique. Article 4(4) of Implementing Regulation (EU) 2016/1055 requires a later, request-based explanation to include the ordinary notification information. It does not, however, add an impossible cross-reference or impose a separate, unexplained category of personal details.
4. Where Article 3 becomes internally inconsistent
The difficulty lies in the final sentence of Article 3(3). It provides:
“Such notification shall also include the identity and contact details of person(s) referred to in paragraph 1(b) and 2(b) and (e).”
That sentence presents several problems.
4.1 Article 3(2)(e) does not refer to a person
Article 3(2)(e) requires “the date and time of the decision to delay the disclosure of the inside information”. A date and time cannot have an identity or contact details. On its face, the cross-reference is incapable of literal application.
Article 3(2)(f), by contrast, refers to “the functions of the persons responsible for the decision to delay”. It is therefore plausible that point (e) was intended to be point (f). That is the most obvious textual correction, but it cannot be treated as legally certain without a corrigendum or authoritative clarification.
4.2 Article 3(1)(b) records functions, but the notification requires identities
Article 3(1)(b) requires the durable record to contain the “positions/functions” responsible for the relevant steps. Yet the unnumbered subparagraph later in Article 3(1) states that the notification must also include the identity and contact details of the persons referred to in Article 3(1)(b).
The Regulation therefore requires information to be transmitted that it does not clearly require to be included in the underlying durable record. A workable compliance system must nevertheless record the name-to-function mapping and professional contact details. Otherwise, the entity cannot reliably fulfil the transmission requirement.
4.3 Article 3(2)(b) is partly duplicated
Article 3(2)(b) already requires the identity, name, surname and position of the person making the notification. Article 3(2)(c) separately requires that person’s professional email address and telephone number. Requiring the identity and contact details of the person “referred to” in Article 3(2)(b) therefore largely duplicates information already contained in the Article 3(2) dataset that the first sentence of Article 3(3) imports.
4.4 “Such notification” is ambiguous
Article 3(3) addresses a written explanation supplied after a request. Its second sentence nevertheless refers to “such notification”. It is unclear whether this means:
the original notification already submitted after disclosure;
the later written explanation;
or a new notification accompanying that explanation.
The context suggests that the additional information is intended to accompany the later explanation. The text should say so.
4.5 The request-only route appears formally more extensive
Under the ordinary route, Article 3(1) expressly adds the identity and contact details of the persons responsible for the functions in Article 3(1)(b). Under the request-only route, Article 3(3) appears to add the persons in Article 3(1)(b), Article 3(2)(b), and the impossible Article 3(2)(e).
There is no apparent policy reason for a Member State’s decision to permit explanations only upon request to result in a formally broader personal-data submission when a request is eventually made. The more convincing interpretation is that both routes were intended to produce equivalent information overall, with the request-only explanation merely repeating the metadata needed to make it self-contained.
5. The drafting history shows where the problem arose
The legislative history is particularly revealing. ESMA’s July 2024 final draft was materially more coherent than the text ultimately adopted by the Commission.
ESMA’s July 2024 draft, Article 4 | Adopted Regulation, Article 3 |
The internal record contained the identity of the persons responsible for the relevant functions | The internal record contains only the positions/functions responsible |
The notification identified all persons responsible for the delay decision | The notification records the functions of the responsible persons |
A later request-based explanation included the ordinary notification information | The later explanation includes the ordinary notification information plus an additional sentence referring to persons under points 1(b), 2(b) and 2(e) |
No additional defective cross-reference appeared | Point 2(e) refers only to a date and time |
ESMA’s consultation record does not disclose a policy request for the additional sentence. Respondents generally supported the proposed technical means. The only specific comment reported on the request-only mechanism asked ESMA to clarify that the explanation need not be transmitted unless the authority actually requests it. ESMA considered Article 88(3) MiCAR sufficiently clear and left its draft unchanged.
The problematic wording therefore appeared after ESMA submitted its final draft. The available materials do not explain why the Commission changed the allocation between identities and functions or why the additional sentence in Article 3(3) was inserted.
The most plausible explanation is a drafting error introduced while reorganising the data fields. ESMA’s draft stored the identities of the responsible persons internally and included the identities of the delay decision-makers in the notification. The final Regulation replaced those identity fields with functions in Articles 3(1)(b) and 3(2)(f), then attempted to reintroduce identities and contact details through additional sentences. During that process, the reference to point (e) appears to have been inserted where point (f) was probably intended.
That reconstruction is compelling, but it remains an inference. A market participant cannot amend an EU regulation by inference.
6. This is more than legislative aesthetics
An incorrect cross-reference may appear minor on paper. Its effects become clearer when the rule is implemented operationally.
At DAAvern, the issue became apparent when translating the Regulation into a delay-documentation workflow. Software requires each legal obligation to map to a defined field, an accountable role and a reproducible output. A system can ask for the identity and contact details of a decision-maker. It can record the date and time of a decision. It cannot meaningfully ask for the contact details of the date and time itself.
The ambiguity creates practical questions for every entity designing its own process:
Which persons must be identified in the original notification?
Must the full identities and contact details of monitoring, disclosure and authority-contact personnel be transmitted in every case?
What additional information must accompany a later explanation?
Is point (e) to be disregarded, read as point (f), or treated as evidence of a broader requirement?
How should a notification template be designed when the legal source does not yield a logically valid data field?
Different entities, advisers, competent authorities and software providers may answer those questions differently. That undermines the uniformity that implementing technical standards are intended to achieve.
7. The most defensible interpretation pending correction
Until the text is corrected or authoritatively clarified, Article 3 should be applied in a way that respects Article 88 MiCAR, the recitals, the MAR precedent and the evident function of each dataset.
First: maintain a complete contemporaneous audit trail
The full Article 3(1) record should be created when the delay is decided and updated throughout the delay. It should include the relevant time points, the reasoning and evidence for each Article 88(2) condition, confidentiality measures, monitoring reviews, changes in circumstances and the allocation of responsibilities.
Although Article 3(1)(b) refers only to positions or functions, the prudent approach is also to record the identity and professional contact details of every person occupying those roles during the relevant period. Changes in personnel should be traceable.
Second: distinguish the notification from the evidentiary record
The Article 3(2) notification should be generated as a separate regulatory output containing the prescribed identifying and timing information. The broader internal file should remain available to support the written explanation and any later supervisory inquiry.
Third: treat both national regimes as equivalent in substance
Under the default regime, the entity should submit the notification together with an explanation showing how all three delay conditions were met throughout the relevant period.
Under the request-only regime, it should submit the initial notification, retain the complete explanation and supporting record, and be able to produce a self-contained package promptly if requested. Repeating the Article 3(2) metadata in that later package is sensible and consistent with the MAR model.
Fourth: do not invent contact details for Article 3(2)(e)
The reference to Article 3(2)(e) should be recognised as manifestly inapplicable. That field is exclusively a timestamp. A compliance system should not create a fictitious person or meaningless contact-data field to satisfy the literal wording.
It is prudent, however, to include the identities, functions and professional contact details of the relevant decision-makers and role-holders. That approach captures the information the Regulation was evidently trying to obtain without pretending that the defective cross-reference is legally coherent.
8. What should be corrected
A minimal corrigendum could replace the reference to Article 3(2)(e) with Article 3(2)(f) and replace “such notification” with “such written explanation”. That would remove the literal impossibility.
A cleaner correction would also resolve the underlying allocation problem. Article 3(3) could, for example, state:
“Where the written explanation of a delay in the disclosure of inside information is provided only upon request of the competent authority in accordance with Article 88(3) of Regulation (EU) 2023/1114, the electronic means referred to in paragraph 1 shall ensure that the written explanation includes the information referred to in paragraph 2 and the identity and professional contact details of the persons responsible for the functions referred to in paragraph 1(b).”
Article 3(1)(b) could also be amended expressly to require the identity and function of the relevant persons, rather than functions alone. Article 3(2)(f) should then specify whether the authority requires only the functions of the decision-makers or also their identities.
The objective should be a single coherent model:
a complete internal record;
a clearly defined notification dataset;
a substantive explanation supported by the internal evidence; and
equivalent total information under the default and request-only transmission regimes.
9. A call for a formal corrigendum
Legal certainty matters most where rules must be operationalised. Article 3 is not merely descriptive. It is intended to govern real decisions, real notifications and real supervisory records. An invalid cross-reference should not be left to divergent market practice.
A formal corrigendum would be the cleanest solution. At a minimum, ESMA or the European Commission should clarify:
which persons must be identified and which contact details must be supplied;
whether Article 3(3)’s reference to Article 3(2)(e) was intended to refer to Article 3(2)(f);
whether “such notification” means the later written explanation or a separate accompanying notification; and
whether the default and request-only regimes are intended to require the same information overall.
At the time of writing, no official corrigendum or authoritative clarification resolving these points has been identified. Legal practitioners, compliance teams, affected market participants, industry associations and competent authorities should support a joint request for correction. The defect is narrow, the practical need is clear, and the solution should not be controversial.
After all, the purpose of a technical standard is to make legal obligations implementable. It should not require a compliance team to find an email address for a timestamp.
