JC 2024 74
29 10 2024

Final Report on draft Implementing Technical Standards

specifying certain tasks of collection bodies and certain functionalities of the European single access point under Regulation (EU) 2023/2859

JOINT COMMITTEE OF THE EUROPEAN SUPERVISORY AUTHORITIES

ESMA European Securities and Markets Authority

eiopa European Insurance and Occupational Pensions Authority

eba European Banking Authority

1. Executive Summary 2

2. Acronyms and definitions 3

3. Background 4

4. Feedback from the Public Consultation 5

5. Draft ITSs 38

6. Impact assessment 75

7. Advice by the SMSG 89

1. Executive Summary

Reasons for publication

1. The ESAP Regulation1 tasks the JC of the European Supervisory Authorities (hereafter, the JC) to develop draft implementing technical standards (ITSs) specifying certain tasks of collection bodies (hereafter, CBs) (Article 5) and certain functionalities of ESAP (Article 7).

2. In order to fulfil its mandate, the JC ran a public consultation between 8 January and 8 March 2024 (JC 2023 782 ). The Final Report summarises the outcome of that consultation and proposes draft ITSs to fulfil the mandate set in the ESAP Regulation.

Content

3. The draft ITSs specify the following topics, as requested in the mandate:

With respect to tasks of the CBs:
- How the automated validations are to be performed for each type of information submitted by entities
- The characteristics of the Qualified Electronic Seal (QES)
- The open standard licenses
- The characteristics of the (data collection) application programming interface (API)
- The characteristics of the metadata identified in the mandate
- The time limits
- The indicative list and characteristics of formats that are acceptable as data extractable formats and as machine-readable formats
With respect to functionalities of ESAP:
- The characteristics of the (data publication) API
- The specific legal entity identifier
- The classification of the types of information
- The categories of the size of the entities
- The characterization of industry sectors

Next steps

[1] Regulation (EU) 2023/2859 of the European Parliament and of the Council of 13 December 2023 establishing a European single access point providing centralised access to publicly available information of relevance to financial services, capital markets and sustainability

[2] https://www.esma.europa.eu/sites/default/files/2024-01/JC_2023_78_CP_on_ITS_on_ESAP_tasks_of_collection_bodies_and_ESAP_functionalities.pdf

4. The draft ITSs are submitted to the Commission for adoption. From the date of submission, the European Commission shall decide on whether to adopt the ITSs within three months. The Commission may extend that period by one month.

2. Acronyms and definitions

API	Application Programming Interface
CB	Collection body
DORA	Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
EBA	European Banking Authority
EIOPA	European Insurance and Occupational Pensions Authority
EMIR	Regulation (EU) No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories (European Market Infrastructure Regulation)
ESAs	European Supervisory Authorities
ESAP	European Single Access Point
ESAP Omnibus Directive	Directive (EU) 2023/2864 of the European Parliament and of the Council of 13 December 2023 amending certain Directives as regards the establishment and functioning of the European single access point
ESAP Omnibus Regulation	Regulation (EU) 2023/2869 of the European Parliament and of the Council of 13 December 2023 amending certain Regulations as regards the establishment and functioning of the European single access point
ESMA	European Securities and Markets Authority
GLEIF	Global LEI Foundation
Historical information	Information as defined by Article 2(9) of Regulation (EU) 2023/2859 that CBs which are Union bodies, offices or agencies may make available to ESAP, as per Article 1(3) of Regulation (EU) 2023/2859
ISO	International Organization for Standardization
JC	Joint Committee of the ESAs

MIFID
Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Directive 2002/92/EC and Directive 2011/61/EU (MiFID II) OAM Officially Appointed Mechanisms designated under
article
21(2) of
Directive 2004/109/EC
ITS
Implementing Technical Standards
NCA
National Competent Authority
QES Qualified Electronic Seal as defined in Article 3, point (27), of Regulation (EU) No 910/2014 Transparency Directive Directive 2004/109/EC of the European Parliament and of the Council of 15 December 2004 on the harmonisation of transparency requirements in relation to information about issuers whose securities are admitted to trading on a regulated market and amending Directive 2001/34/EC UCITS Undertakings for collective investments in transferable securities

3. Background

5. Regulation (EU) 2023/2859 of the European Parliament and of the Council of 13 December 2023 (hereafter, the ESAP Regulation) mandates ESMA to establish and operate by 10 July 2027 a single access point (“ESAP”), whose aim is to facilitate access to information disclosed by companies.

6. Information is expected to come into scope of ESAP in three phases. The first phase is expected to begin in July 2026, the second phase in January 2028, the third phase in January 2030. Sectoral legislation (as amended by the ESAP Omnibus Directive/ Regulation) specifies the start of the reporting date for each type of information.

7. The ESAP system as conceived in the ESAP Regulation is a two-step reporting system: as a first step, when making public certain information, entities should submit that information at the same time to a collection body (hereafter, CB); as a second step, CBs should provide ESAP with this information. CBs are Union or national bodies/authorities/registers which are designated in the legal Acts in scope of ESAP (as amended by the ESAP Omnibus Directive / Regulation) or by Member States. There may be therefore different CBs for different types of information and for different Member States. All such CBs will be expected to provide ESAP with the information they collect from entities to ESAP. Article 5 specifies the tasks of CBs and empowers the JC to draft ITSs to specify certain aspects of those tasks.

8. Article 7 of the ESAP Regulation requires that ESMA ensures that the ESAP portal provides a minimum set of functionalities, such as a user-friendly web portal taking into account access needs of persons with disabilities, an API to enable access to information, a search function in all EU languages on the basis of a predefined set of metadata, an information viewer, a machine-translation service and a download service and a notification service. Article 7 empowers the JC to specify certain aspects of those functionalities.

9. This Report sets out how the JC is proposing to fulfil its mandate with the draft ITSs presented in the next section, which are submitted to the Commission.

10. The Feedback statement summarises the input received on all questions asked in the Public Consultation and describes how the JC addressed the points raised by stakeholders. Certain points were not addressed because that was deemed not relevant or necessary. The Feedback Statement explains in detail why that is the case.

11. Finally, the Impact assessment provides an overview of the choices considered by the JC and the considerations made when reaching the preferred solution which are reflected in the draft ITS.

4. Feedback from the Public Consultation

4.1.1 Tasks of CBs

(i) Automated validations

1) Do you agree with the preferred approach outlined above, under which the validations will be defined on a cross-cutting basis without specifying explicitly the types of information to which a given validation should be applied (and understanding that they should be performed always when relevant for a given type of information as set out in the ITS on tasks of CBs or sectoral ITS)?

12. 31 respondents provided input to this question. The majority of the respondents supported the approach to validations where the ITS would not specify explicitly the types of information to which a given validation should be applied (and understanding that they should be performed always when relevant for a given type of information as set out in the ITS on tasks of CBs or sectoral ITS). The respondents highlighted that this approach provides the necessary flexibility and avoids the risk that ITS would easily become obsolete and require constant updates. A few respondents that opposed the proposed approach either suggested more farreaching data quality arrangements (which would however go beyond the ESAP mandate) or specifying the validation directly in the ITS to ensure better data standardisation.

13. Generally, several respondents flagged a need for transparency and certainty regarding the validations that will be performed by the CBs. In this regard JC clarifies that the relevant validations will be specified in the L3 documentation and made public in advance of the start of reporting. Furthermore, the respondents highlighted the importance of ensuring that the validations are applied in a standardised and harmonised manner across the CBs. JC confirms that CBs are expected to apply the same checks across the EU, as defined in the ITS. That would be consistent with the aim to achieve a single EU data space, where quality of data does not vary depending on the Member States and where cross-border entities do not need to adapt their reporting depending on the Member State they are operating in. Consequently, the wording of the ITS has been adjusted to refer to a ‘harmonised set of validations’, thus stating explicitly that all CBs should perform the same checks for the same type of information.

14. Furthermore, two respondents flagged that the envisaged validations are rudimentary and would not ensure sufficient minimum data quality. In this regards JC reminds that the content validations are out of scope of ESAP mandate.

15. Some respondents suggested to consider options to support the CBs in the uniform application of validations (e.g. sharing source code/API/library). While not relevant for the finalization of the ITS, JC takes note of this feedback. Possibility of providing such tools may be further assessed in the future.

16. Respondents have also requested to consider the GDPR aspects. In this regard JC recalls that the personal data flag is one of the metadata elements set out in the ESAP Regulation and the CBs are expected to validate the presence of this element (as part of metadata validations).

17. Some respondents commented that a failure or delay of the validation process should not lead to transmission restrictions or that warnings issued pursuant to the validation process should be transmitted by CBs and made available on ESAP. In this regard it should be noted that ESAP Regulation envisages that CBs reject the information which does not pass validation rules and send the rejection feedback to submitting entities. No additional warnings (as part of automated validations under ESAP) are envisaged. Subsequently, submitting entities should resubmit the rejected information without undue delay. This ensures that the information published on ESAP conforms with minimum data quality requirements.

Proposed way forward

18. Based on the received feedback, JC intends to maintain the proposed approach and intends to provide further clarifications in the L3 documentation.

2) Do you agree with the above proposal how the CBs shall verify that the information is data-extractable? In case of any challenges foreseen, please propose alternatives.

19. 28 respondents provided input to this question. The proposed way of validating the data extractability was overall supported by the respondents.

20. A few respondents flagged that inclusion of some non-extractable information (such as pictures or charts) should not result in qualifying the submissions as not data-extractable and consequently lead to rejections. The JC agrees with this assessment and acknowledges the limitations flagged by the respondents. In particular, ideally all regulatory information (as required to be publicly disclosed by the sectoral legislation) should be data extractable. However verifying it by the CBs would require validations which do not appear feasible to be performed in an automated manner and which would constitute in practice content validations. Consequently, the JC maintains its original proposal under which the CBs should verify if the text content of the information can be extracted. This is without prejudice to the responsibility of a submitting entity to ensure that all relevant information is contained in an extractable format and any non-extractable elements are provided merely for visualization purposes rather than informational purposes.

21. Two respondents suggested to specify the possible validation steps, such as automated opening of the documents and automated identification of existence of text (characters, numbers etc.). Given that overall the current wording of the ITS appeared clear to most of the respondents, the JC refrains from defining further in the ITS the exact steps to verify that the ‘text content of the information can be extracted’ since it is deemed preferable at this stage to keep a flexible approach which will allow CBs and ESMA to evolve their practices on the basis of concrete implementation experience if needed in the future, without amending the ITSs.

22. Two respondents proposed to develop the functionality centrally and make available for CBs for their implementation. The JC takes note of this comment but highlights that the development of any such tool is out of scope of this ITS.

23. One respondent suggested that the format should be specified by the submitting entity as one additional metadata element, on which the CBs could rely for the purpose of format validation. This approach however would not ensure data extractability or machine readability if the submitting entity reports the metadata element incorrectly. Furthermore, the expected format should be derived by CB on the basis of the type of information, since each type of information will generally be expected to be submitted consistently in the same format with the exception of information prepared pursuant to the Transparency Directive and the Accounting Directive where information might be prepared in different formats on the basis of national law. In that case the expected format should be known by the CB on the basis of applicable national legislation. Consequently, the validation of the data extractability or of a specific machine-readable format used by entities is necessary and such data element would constitute an additional reporting burden without a clear added value in terms of optimisation of the validation process.

Proposed way forward

24. Based on the received feedback, JC intends to maintain the proposed approach.

3) Do you agree with the above proposal how the CBs shall verify that the information is machine-readable? In case of any challenges foreseen, please propose alternatives.

25. 27 respondents provided input to this question, where the majority of respondents supported the proposed specification of the validation of machine-readability and some respondents requested clarifications. Having considered the received feedback, the JC decided to maintain the proposed approach.

26. One respondent suggested that the list of accepted formats should be made available in a machine-readable form. In this regard ESMA clarifies that it is not intended to accommodate for an extensive list of formats, but rather rely on a limited number of machine-readable formats that are prescribed in the sectoral legislation or will be prescribed in the ITS pursuant to the ESAP mandate.

27. Two respondents strongly supported the interpretation that in the case of information to be submitted in a common schema, such as XML, the automated validation should also verify compliance with the schema. Furthermore, these respondents suggested that this would apply also to XBRL files and the relationships or semantic assertions contained in the schema. The JC confirms that also in the case of XBRL the validation of compliance with the taxonomy is expected, however these checks will inevitably be limited to those checks which can be performed by a machine without human intervention. Additional controls (i.e. checks for the correctness of the tags or for the relevance of an extension taxonomy element) may be performed ex-post where appropriate depending on the legal framework by the relevant competent authority and not included in the automated validations.

28. Two respondents proposed to facilitate the validation by relying on the metadata, noting however that the results of these checks may not always be consistent. Indeed, it does not appear satisfactory to rely on an indication of the format within the metadata which may not necessarily reflect the actual format used.

29. Two respondents commented that the validation method should be disclosed and definition of the validation should be provided.

Furthermore, it has been proposed that standardized machine executable rules to verify
machine-readability are made available for each format of file collected and made accessible on ESAP. The JC takes note of this proposal, which is nonetheless out of scope of the ITS. As flagged in response to the feedback on the preceding questions, it may be further explored if any such tools should be developed to support the implementation of the validations.
Respondents also flagged that a distinction should be made between ESEF annual financial
reports prepared pursuant to the Transparency Directive and PDF annual financial reports prepared pursuant to the Accounting Directive for the purposes of technical validation. JC clarifies that CBs will be expected to validate that the information is submitted in one of the accepted formats for a given type of submission.
Finally, one respondent asked how to validate a specific machine-readable format applicable
under national law. JC clarifies that verification of a machine-readable format required under national law is out of scope of the automated validations set out by this ITS.

Proposed way forward

Based on the received feedback, JC intends to maintain the proposed approach.

4) Do you agree with the above proposal for the validation of the metadata? In case of any challenges foreseen, please propose alternatives.

29 respondents provided input to this question. Respondents have largely supported the
proposal, indicating the importance of good quality metadata.
One respondent opposed the validation of metadata mainly due to the high cost of
standardising the metadata and defining the allowable values as well as the issue of reliance on external sources for the validation purposes. According to that respondent the value of metadata for stakeholders is low. Another respondent, which is an OAM, pointed out that currently the metadata is provided to them via web form or at the moment of subscription and the change to that model, as well as additional validations for example relying on the GLEIF database, will result in significant implementation effort.
Additionally, a few respondents commented that CBs should not be required to rely on
external interfaces (e.g. GLEIF). Should such external interfaces be inaccessible, the CBs would not be able to perform the validations within the specified timelines. One respondent suggested that submitting entities should provide a link to the external sources against which the validation should be performed. The JC takes note of this concern, but highlights that, based on experience, temporary disruption of the GLEIF database would not occur frequently. In such cases, workarounds could be applied, e.g. relying on the version of the data as of the previous day. The JC will consider if such clarifications need to be included in L3 guidance.

37. Respondents have also flagged that CBs would not be able to verify the status of the LEI before the submission to them or after providing the information to ESAP. JC takes note of this clarification and confirms that CBs should only validate the LEI at the time of submission of the information to ESAP. Furthermore, the CBs would be required to verify only the validity of the LEI, that is whether the LEI is compliant with the ISO 17442 standard and included in the GLEIF database, irrespective of whether it was duly renewed.

38. One respondent expressed concern about the proposal not to allow for optional metadata noting that they have been used in the market for many years to classify documents. The respondent suggested to allow for optional metadata and request the CBs to provide them to ESAP. This proposal was taken on board in order to allow classification of documents on the basis of additional metadata should that be relevant or necessary.

39. One respondent argued that if the latest version of metadata cannot be reached, older versions should be available. The JC highlights that the metadata which are required to be submitted by the entities should always be provided with the information in a comprehensive manner and are the responsibility of entities. This is without prejudice to certain metadata not being required from the entities by the ESAP Omnibus Directive and being sourced by CBs instead.

40. Another respondent requested that it is made clear who is responsible for correcting any inaccuracies in the data. JC clarifies that for metadata to be submitted to the CBs the ESAP Regulation already assigns the responsibility to the submitting entity.

41. One respondent suggested that checks should be done on metadata to avoid filing of the same document through multiple circuits, resulting in duplicates in the ESAP (e.g. due to multi-jurisdictional virtual filing or filing in various languages). In this regard it should be noted that the same information should not be submitted more than once to the same CB, however it is possible to have official filing in various languages.

42. Finally, one respondent asked about the mandatory nature of the requirements proposed in the consultation paper (notably, with regards to the use of verb ‘should’ rather than ‘must’). JC clarifies that ‘should’ language has been used in the explanatory text, however the actual requirements will be set out in the ITS (which use verb ‘shall’). The checks to be performed by the CBs will be therefore of a mandatory nature.

43. Proposed way forward

44. Based on the received feedback, JC intends to mainly maintain the proposed approach. However the prohibition to include additional metadata was removed from the proposed validations.

5) Do you agree with the proposed approach to the validation of the electronic seal? In case of any challenges foreseen, please propose alternatives.

45. 22 respondents provided input to this question. The vast majority of the respondents that commented on the proposed manner for validating the seal for ESAP purposes, supported the proposal.

46. One respondent stated that CBs should also verify that the Qualified Electronic Seal (QES) includes the LEI. It is confirmed that this validation was already envisaged in the draft ITS, where Article 4a requires the CBsto verify if the QES complies with the specified characteristics (which in turn a.o. refer to the use of LEI within the seal).

47. Respondents commented on a number of related issues:

Some respondents flagged that the request for the use of the seal remains optional for CBs to the extent that their Member State permits it and welcome the discretion given to the CBs in this regard.
Three respondents suggested that the CB should be able to sign on behalf of entities, two of those respondents argued also that seal must be added by the submitting entity just before publication to avoid potential issues with reading or parsing the file. JC notes that this proposal is not in line with L1, according to which the CB should verify that the QES was provided with the submitted information.
One respondent clarified that in line with national requirements they are currently signing the files uploaded by submitting entities as part of the workflow, therefore no additional validation is required. JC notes that this workflow would not fall under the scenario of a QES required, given that the QES requirement under ESAP applies to submitting entities (where the MS permits, and the CB requires the QES).

Proposed way forward

48. In light of the received feedback JC intends to maintain the approach proposed in the CP. Additionally, the wording of Article (1(4) is streamlined to refer to the Article 32 of eIDAS (on validations) instead of listing the validations envisaged under eIDAS.

6) Do you agree that the format of rejection feedback to the submitting entities should be standardised?

49. 26 respondents provided input to this question. The majority of respondents supported standardisation of the format of the rejection feedback, noting a.o. that it will allow for a faster resubmission of information and limit complexity for entities submitting information to multiple CBs.

A few respondents who commented specifically on the use of ISO 20022 methodology for that
purpose were rather supportive, however two respondents flagged potential costs for small and medium enterprises.

51. One respondent who objected the proposal stated that the existing channel works and that they do not expect numerous rejections.

52. Two respondents proposed to allow for flexibility in the choice of the format and focus rather on interoperability. Another respondent explained that the practical implications of the standardisation are not clear to them and that it should not result in additional requirements for submitting entities in terms of new IT interfaces.

53. One respondent proposed a phased approach, noting also that CBs already have arrangements in place to notify rejections and any mandatory transition to another format will take time

54. Respondents have also commented that the rejection feedback should be sent only to entities, not to ESMA. JC confirms that the feedback on the results of the automated validations should only be sent to the submitting entities.

Proposed way forward

55. Having considered the received feedback, JC is of the view that the rejection feedback should be standardized and proposes a phased approach in order not to impose on the CBs and entities too high burden that would be disproportionate to the benefits obtained from the standardization. Notably, as a first step it is proposed that rejection feedback for all new dataflows or dataflows which currently do not envisage rejection feedback should be fully standardized.

7) Do you agree that the rejection feedback should be provided in a common format in accordance with ISO 20022 methodology? If not, please propose suitable alternatives.

56. 22 respondents provided input to this question. The respondents supported ISO 20022 as the methodology to be used for the purpose of standardising the format for rejection feedback under ESAP, noting its wide use in financial service as well as consistency with some other reporting frameworks.

57. One respondent flagged that ISO 20022 is a methodology rather than format and that currently it does not support APIs (and ESMA is planning to use API for the purpose of communicating with CBs). The JC notes that this aspect is not relevant for the provision of rejection feedback from the CBs to the entities, which is the subject of the ITS.

58. One respondent advocated for a phased approach noting that CBs already have processes in place to provide rejection feedback.

Proposed way forward

59. Based on the received feedback JC intends to pursue the standardization of the rejection feedback in accordance with ISO 20022 methodology with regards to new reporting frameworks for which there is currently no collection of information as well as the dataflows which currently do not envisage rejection feedback. As flagged under the previous question, this phase-in will ensure that very limited changes are implemented with regards to the reporting flows where feedback messages already exist. ISO20022 will therefore be implemented for feedback messages on new reporting frameworks and the frameworks which currently do not require a rejection feedback and on the basis of Level 3 legislation rather than on the basis of this ITS.

8) Do you agree that the rejection feedback should be provided as soon as possible? Should an exact timeline be specified in the ITS and, if so, do you consider the proposed timeline adequate? Please clarify potential scenarios in which the proposed timeline could create challenges?

60. 24 respondents provided input to this question. The majority of the respondents supported the timelines for the provision of the rejection feedback as set out in the ITS.

61. Two respondents opined that the maximum delay of 60 minutes is rather tight. On the other hand, three respondents advocated for minimising the time lag.

62. One respondent flagged that the feedback should be provided in all cases before the information is published on ESAP. The original proposal aimed at aligning the timelines for provision of the rejection feedback and the timelines for provision to ESAP. However, the JC acknowledges this comment and has amended the draft proposal to specify that the feedback on the results of the automated validations should in all cases be provided maximum 60 minutes after the information has been submitted. This will allow for a swift resubmission of the information where needed.

63. One respondent proposed to extend the timeline to allow for more detailed validations. JC reminds that the content validations are out of scope, therefore this proposal was not considered.

Proposed way forward

64. Based on the received feedback, JC intends to maintain the proposed maximum delay of 60 minutes and to clarify that it should always be counted from the moment when the information was submitted. The JC has also provided for certain derogations for the 60 minutes maximum delay when exceptional circumstances arise.

(ii) The characteristics of the QES

9) Do you agree that QES under ESAP should be in XAdES, CAdES or PAdES format?

65. 19 respondents provided input to this question. Most of the respondents agreed with using the three proposed formats (XAdES, PAdES and CAdES).

66. One respondent disagreed with the proposal and suggested that other eIDAS compliant formats such as dTrust should be taken into account, which would however make the use of seals more complex. The example mentioned by the respondent is in fact a qualified trust service provider under eIDAS offering a.o. the service of qualified electronic seals. ESAP is a pan-European project thus use of the formats standardised under eIDAS is important to ensure that the seals can be issued and validated in all Member States.

67. Two respondents expressed a preference for using detached CAdES, linking the use of other formats in embedded form to security risks, however the respondents did not provide further details on the nature of these risks. It is worth noting that if a document could be manipulated, the embedded seal could be altered too, but if this last is not produced with the legitimate QES and this one is not compromised, then the verification of the altered document and seal would fail. A similar risk concerns a detached file, if the attacker can alter both detached files (file and seal). Furthermore, XadES, similarly to CAdES, also allows for both embedded and detached seals.

68. One respondent flagged that the more formats that are approved, the higher the costs.

69. One respondent flagged that use of QES generates technical issues for submitting entities, thus use of QES will need to be duly tested when required.

70. One respondent, while agreeing with the choice of the proposed three formats, highlighted that the manner in which they are used should not be unnecessarily constrained. In particular, it should be allowed to use e.g. multiple electronic signatures for different parts of an iXBRL document. While additional use of electronic signatures is outside the scope of ESAP requirements, the JC notes that the proposed seal specifications do not seem to prevent in any way such use of the signatures.

Proposed way forward

71. Having considered the received feedback, JC intends to maintain the proposed approach allowing for the use of XAdES, PAdES and CAdES formats.

10) Do you agree that there is no need to use ASiC format under ESAP?

18 respondents provided input to this question, where the majority of the respondents agreed
with not using ASiC format under ESAP. One respondent stressed the importance of maintaining the granularity of a QES for each individual document to ensure the transparency and accuracy and flagged that this approach would also limit the impact on information availability in case of a QES rejection.

73. One respondent flagged that ASiC, in addition to providing a way to associate one or more signatures with one or more signed files, has also an added value of combining the detached signature file with the file being signed. Furthermore, the respondent flagged that where documents may require multiple signatures for different purposes, ASiC provides a way to combine all of these into a single container file. The JC acknowledges this point but reminds that use of signatures is outside of scope of these ITSs, which only deal with qualified electronic seals. Use of CAdES/PAdES/XAdES for sealing specific files as it may be required by a CB pursuant to ESAP, should not prevent from use of ASiC container for multiple signatures, which are indeed a permissible way in which collection bodies may ensure appropriate levels of authenticity of the information submitted by entities (as required by Article 5 paragraph 9).

Proposed way forward

74. Based on the received feedback, JC intends to maintain the proposed approach, that is not to add ‘ASiC’ as one of the QES formats to be used under ESAP.

11) Do you agree that QES under ESAP should be at least at conformance level LT?

75. 19 respondents provided input to this question, where the majority of respondents supported the proposal. It has been flagged that the information may be accessed not only immediately or in a short run, but also long time after it has been uploaded (for example financial statements with financial years dating several years back)

76. Among those who disagreed two respondents considered it not necessary that the seal remains valid beyond the date of submission, while other two respondents expressed a strong preference for using LTA only as soon as technically possible due to additional features allowing for better verification.

77. Additionally, three respondents asked to clarify how to address revocation and how older documents should be signed. With regards to the first question, JC clarifies that after revocation, the seal would not be considered valid anymore (and this would be transparent to ESAP users). Concerning the use of seals for older documents, JC understands that this refers to the historic information, and clarifies that, as per L1, only “CBs that are Union bodies, offices or agencies may make available to ESAP historical information”. At this stage use of the seals for signing historical documents is not expected.

78. Finally, one respondent suggested to consider proactive determination of revocation which could trigger timely updates of the documents. Such proposal is however out of scope of ITS mandate and has not been considered.

Proposed way forward

79. In the light of the received feedback the JC intends to maintain the proposed approach

12) Do you agree with the requirement to include ISO 17442 LEI code as an attribute in the digital certificates whenever the information submitted to ESAP is accompanied by a QES?

80. 28 respondents provided input to this question and most of the respondents expressed a strong support for using LEI as part of digital certificates. Among the benefits mentioned by the respondents it would provide for a globally interoperable identifier in the certificates, facilitate straight-through-processing, provide an additional layer of trust and security, ensure an audit trail as well as provide a link to the entity reference data.

81. A few respondents who expressed some doubts questioned about the feasibility of integrating the LEI by the seal providers and the potential implementation burden.

82. One respondent commented that they are currently using signatures to identify natural persons. In this regard the JC clarifies that digital signatures are out of scope of ESAP proposal, and the requirement to use LEI in the certificate would concern only QES when allowed by the MS and required by the CB.

Proposed way forward

83. Based on the support received, the JC intends to maintain the approach proposed in the CP.

13) Are there any other characteristics of the QES that should be defined under ESAP?

84. 13 respondents provided response to this question.

85. One respondent commented that collection bodies should also be eligible as trusted bodies. The JC clarifies that while nothing in principle prevents an entity that is designated as a CB to be also a QTSP under eIDAS, this is outside of ESAP policy work.

Proposed way forward

86. Based on the feedback received, the JC does not intend to define any other characteristics of the QES.

(iii) The open standard licenses

14) Do you agree with the proposed approach to the open standard licences which shall be applied by CBs to the datasets to be made available to ESAP? If not, why not and what alternative approach would you suggest?

87. 25 respondents provided input to this question. The vast majority of respondents supported the JC proposal to require CBs to apply CC0 open standard license or equivalent.

88. Two respondents from the credit rating industry raised concerns about the application of CC0 by all CBs because they feared that copyrights-covered data (most notably ratings issued by credit rating agencies) would not be adequately protected against commercial use. These respondents argued that the use and re-use of credit ratings for commercial purposes should not be allowed and that adequate protections should be ensured. However, the respondents seemed to accept the use for regulatory and non-commercial purposes.

89. One of these respondents in particular suggested that Creative Commons Licence BY-NC-ND would more adequately protect the rights of the submitting entities when applicable as it limits use of information and protects against commercial use. In alternative, if CC0 is retained, this respondent recommended that it should be made clear that CC0 does not waive the intellectual property (IP) rights of the credit rating agencies.

90. The JC agrees that for credit ratings, for which CRAs have claimed intellectual property rights, it would be appropriate to mandate the use of the Creative Commons Licence BY-NC-ND in order to ensure that such disclosures are not used and-reused for commercial purposes. ESMA as CB for the type of information “credit ratings” will therefore be expected to apply Creative Commons Licence BY-NC-ND to this specific data set.

91. The JC also wishes to take this opportunity to clarify, as requested by one respondent, that credit ratings which are exclusively produced for and disclosed to investors for a fee (so called investor-pays ratings) in accordance with article 11a of the CRA Regulation are not in scope of ESAP.

92. One respondent suggested to mandate MIT Open-Source License, another responded suggested Open Data Commons Public Domain Dedication and License. The JC notes that CBs under the draft rules will be able to apply any open standard license which is equivalent to CC0 and therefore it is not deemed relevant to explicitly specify additional alternative licenses in the draft ITSs to achieve the desired outcome.

93. Another respondent suggested that access to ESAP should be limited to contributors or to EU-entities. The JC notes that non-EU actors can legitimately contribute to EU capital markets and no need has been identified to restrict access of data to EU actors or contributors. It is beyond the scope of ESAP to control how the data will be processed by data providers, but since ESAP will make available to users the same information, there will be a level playing field between domestic and foreign data providers to use this data. One respondent also raised the concern that data will become available to users who are not the intended users, for example prospectuses which are offered only in certain jurisdictions will be available also to investors who are in other jurisdictions. It should be highlighted that ESAP, just like the Prospectus Register, is intended to make available all prospectuses it receives to all users and there is no provision which limits the accessibility of prospectuses only to national investors.

94. Several respondents raised questions about whether ESMA intends to raise fees for ESAP. Please note that this point is addressed under Question 21.

95. Three respondents asked the JC to provide for specific safeguards when it comes to personal data. Please note that this is due to the fact that the ESAP Regulation already extensively includes specific requirements applicable to personal data in line with relevant EU legislation, therefore it would not be appropriate and it would be beyond the scope of the JC mandate to specify additional requirements on the same topic. 164

96. One respondent asked the JC to clarify that ESAP will only be receiving from CBs raw data, and not data which has been processed, enhanced or transformed. Indeed, the ESAP Regulation requires that CB transmit to ESAP the same information they receive from submitting entity, and therefore there is no expectation that the information will be transformed in any shape or form. Please note that this does not apply to metadata, some of which will be generated and/or processed by CBs.

Proposed way forward

97. Based on the feedback received, the JC has maintained the initial proposal for all types of information, but amended the open standard license applied to the type of information covered by IP rights in order to ensure that commercial use of this type of information is restricted and the IP rights of entities are respected, as requested by the majority of credit ratings agencies themselves in response to this Consultation.

(iv) The characteristics of the (data collection) application programming interface (API)

15) Do you agree with the proposed characteristics of the API for data collection? If not, what alternative characteristics would you recommend?

98. 22 respondents provided comments to this question. Of these, the vast majority supported the approach proposed by the JC.

Of those who did not support the approach, it is worth noting in particular that the OAMs
expressed concerns about the API in light of the fact that the proposed model (i.e. a push model, whereby CBs would be sending data to ESMA for further processing and publication) would imply storage both at the level of the CB and at the level of ESMA. They suggested that a model such as BRIS1, the EEAP2 or BORIS3 would be adequate for ESAP, i.e. a system based on an aggregation of links at central level, redirecting to information stored exclusively at national / CB level.

100. However, if CBs were to provide ESMA with links to the information stored on their portals only, they would not be providing ESAP with “the information and the metadata for that information” and would therefore be in breach of Article 5 paragraph 1(d) of the ESAP Regulation. Furthermore, ESAP would not be able to provide access to the information but rather would act as a collection of links - this would be in breach of Article 1 of the ESAP Regulation and would not fulfil the objectives of the ESAP Regulation specified in Recital 3. Article 1 and 1(a) of the ESAP Regulation, mandates ESMA to offer centralised electronic access to the information made public by companies. The ESAP is conceived of as a platform containing the information itself, along with the associated metadata, while the EEAP, BRIS and BORIS are a collection of links to information.

101. Some respondents, while supporting a push model, noted that a pull model would also be possible. The JC wishes to highlight that the suggested push model is in line with the existing methods for data collection which ESMA and other authorities have developed considerable experience developing and running. A pull model, albeit technically possibly, would require a complete re-design of several existing registers. ESAP Regulation (for example, recital 7 and 10) requires ESMA to build as much as possible on existing mechanisms of data collection. For that reason, a push approach is deemed most appropriate.

102. The JC took note of the request that any changes of the API should give sufficient adaptation time not only for CBs but also for entities and aims to ensure that this will indeed be the case. Similarly, the API specifications will not lead to disruption in reporting, which is a concern expressed by one stakeholder. It should also be highlighted, as mentioned already in this Final Report, that the data which CBs will share with ESMA is only the information prepared by entities and that no transformation or modification of that information is currently expected. Furthermore, the JC can confirm that any sectoral ITSs which will be proposed by the ESAs jointly or individually depending on the reporting framework will be duly consulted upon.

103. Finally, one respondent argued that proposing data via an API would be of limited use if the actual processing of data required after extraction is prohibitive for most actors. Such concerns are addressed in the response related to Q21 on the publication API.

104. Based on the feedback received, the JC intends to retain the proposed approach.

(v) The metadata

16) Do you agree with the proposed approach to the format, list and characteristics of the metadata? If not, what alternative approach would you recommend?

105. 26 respondents provided views on this question. Of these, half fully supported the draft proposals and the other half raising questions, mostly without disagreeing with the overall approach.

106. Four respondents asked for clarification as to which metadata is the responsibility of CBs and which metadata is the responsibility of the submitting entity. Another respondent suggested that information is provided by the submitting entity whereas the metadata are provided by the CBs. It should be noted that entities are responsible for the metadata mandated by the sectorial legislation as amended by the Omnibus Regulation/ Directive. CBs will be responsible for transmitting that metadata accompanying the submitted information and for all other metadata listed in this ITSs. In some instances, metadata will be sourced by CBs from the submitted information.

107. One respondent further believed that it is unclear how the beginning/end of the publication period fields must be completed for certain mandates (such as the Prospectus Regulation) where the information is not periodic but “permanent” over the life of an entity/product. The JC notes that in its original proposal this field was linked to the period over which CBs and ESMA are allowed to publish a certain document. After further reflection and in light of the feedback received, the JC has decided to remove this metadata since the period of which information can be published on ESAP should be derived entirely from the presence or absence of a personal data metadata, i.e. 5 years in case of information containing personal data, 10 years in other cases, unless Union legislation requires otherwise. This is notwithstanding the fact that some information may need to be removed from ESAP due to the fact that it is no longer relevant or valid (such as net short positions which may be depublished after a certain threshold is passed), regardless of the presence or absence of personal data. For this type of information, other arrangements will need to be made as a metadata would anyways not be useful for the purpose of establishing the publication period. As of today, no such other requirements have been identified. Therefore whilst remaining flexible for the future, the JC will implement this rule with regards to the publication period without need for an additional metadata field.

108. Another respondent questioned the field description: “The collection body responsible for the collection of the submitted information” in Table 1 of the Annex. The JC notes that this description comes from Article 7(3)(i) of the ESAP Regulation and as such has been updated to “the collection body responsible for the collection of the information”.

109. One respondent asked what should be reported for “the legal framework” metadata in the case where one disclosure obligation is required by one regulation but is embedded in the disclosure of another. One respondent also encouraged the JC to clarify that CBs should provide this field rather than reporting entities since reporting entities normally are aware of the national transposition of the law and not of the Directive / Regulation from which that national law stems. Another respondent suggested that reference to the Directives should be added by the CB, as submitting entities often do not know its reference. The JC confirms that indeed this field will be populated by CBs and not by reporting entities. Level 3 guidance might be provided in due time to ensure consistency in the way this field will need to be reported whenever a certain type of information fulfils obligations pursuant to various legislations.

110. One respondent asked that further guidance should be provided as to how to fill in the field Home Member State and Host Member State. The JC notes that sectorial legislation (Transparency Directive, Prospectus Regulation, AIFMD, etc) clarifies how to establish the Home Member State and Host Member State and that this might differ under each legislative framework.

111. One respondent asked for an option of the post-reporting enhancement of data submitted by contributing bodies for “the instrument or product identifier” metadata field, especially where data required in the current regulation is not specifically open or license-free. The JC notes that it is currently not foreseen that CBs will enhance the information submitted by entities in light of the responsibility of submitting entities in terms of data quality set by the ESAP Regulation. With regards to the proposal to adopt the FIGI identifier, please refer to Question 14.

112. Another respondent suggested that certain static data (such as size of the issuer) must be stored via the LEI and should not be subject to separate reporting. The JC notes that ESMA intends to source as much information as possible from the GLEIF database, but that not all data required by ESAP Level 1 is available on GLEIF. Size, for example, is not available. However, we share the consideration that double reporting should be avoided and pragmatic solutions will be considered not to request the same information more than once whenever possible. This is without prejudice to the responsibility of submitting entities over the information submitted to the CBs and the accompanying metadata.

113. A respondent suggested that the CB for the submission of information to ESAP shall be the national competent authority since several metadata information are currently already submitted to national competent authorities. It should be clarified that Level 1 ESAP Regulation determines who is the CB, depending on the legislative framework. In some cases, Member States can choose the CB.

114. One respondent stated that embedding metadata in every document appears overly burdensome, especially when documents are prepared in PDF since only the producer of a PDF can embed metadata therein. However, on the basis of the draft JC ITS, when the information

is in PDF (i.e. a non-machine-readable format), the metadata should be mandated to be in ISO20022 format.

115. Another respondent proposed that the metadata should include the identity of the software vendor (a code or LEI), software application (a string) and a version number of the software package(s) used to prepare the filing where that information is provided in digital (non-PDF) format. The JC considers these metadata to be excessively specific and not required for the ESAP search function.

116. Another respondent asked for a field disclosing when the information is released to the public. The JC notes that since information is required to be sent to CBs at the same time as it is made public by the entities (Article 1(a) of the ESAP Regulation) and that a metadata is required for “the data and time when the information was submitted by the entity to the collection body” this need will be addressed without adding a specific metadata.

Proposed way forward

117. Based on the feedback received, the JC intends to remove the “publication period” metadata and maintain the proposed approach in other regards.

(vi) The time limits

17) Do you agree with the proposed approach with regards to time limits? If not, what alternative approach would you suggest?

118. 19 respondents provided input to this question. A majority of respondents agreed with ESMA’s general proposed approach when it comes to time limits. In doing so, they clarified that the use of data contained in ESAP will most likely be used for post-trade services, and that therefore a 60-minute maximum delay will be fast enough for the data to be relevant for its purported use. They also highlighted that NCAs should have enough flexibility with this approach to ensure content approval before the information is made available to the public. The JC notes however that content checks and validations are outside the scope of this ITS and that the time limits will only be triggered after approval of the information whenever competent authorities have a mandate to approve information.

119. A minority of respondents disagreed with the approach in two main ways: some believed the time limits were allowing too much time for validations, whereas others believed that there could be longer delays for some/all of the information in ESAP.

120. Those former respondents, representing large investor associations, believed the time limits should be shorter and argued that the validation rules being the same at the national and EU level should allow for the delay to be minimal or non-existent. These respondents signaled that it should be feasible and desirable for CBs to provide information to ESAP in real time. They also argued that all future validations should all happen at the ESAP level to avoid conflicts of interest, since CBs may perceive their own business model threatened by the existence of ESAP.

121. The JC notes that L1 established that ESAP should be a two-tier system where information is first submitted to a CB and then submitted to ESAP. Therefore real-time submission of information is technically very complex to achieve, if not impossible also in light of the requirement to leverage as much as possible on existing reporting systems and infrastructures. With regards to the proposals that all validations should happen on ESAP directly rather than at CB level, please refer to the summary of responses to Question 19.

122. On the other hand, those respondents who believed longer time should be allowed for the publication in ESAP, argued that ESAP information, especially information that is updated annually or semi-annually, does not need to be subject to the 60-minute delay and that a longer time limit would be sufficient. This would mean that the JC ITS should make a distinction between different types of information based on the time-sensitiveness and potential use. Others argued that more generally a full day delay between publication by entities (which shall be simultaneous to submission to CBs) and by ESAP would be necessary given the size of the files. While the notion of making the distinction between the time limits of different types of information could seem appropriate, the JC believes that ESAP should be as aligned as possible in the time limits of publication of all information within its remit. Withholding certain types of information from ESAP based on potential uses by retail investors would necessitate further evidence from the market which was not sought nor spontaneously provided during this consultation and that it is not possible to seek given the timeline for the development of this draft ITS specified in ESAP L1.

123. Respondents generally stressed the importance of aligning the timing in which information is published on ESAP with the time of publication by entities (either on their website or at CB level, depending on the dataflow).

Proposed way forward

124. Given the overall support to the JC’s proposed approach and the clarifications in other parts of this consultation concerning the envisaged use of ESAP data, the JC suggests maintaining the current 60-minute time limit for the publication in ESAP.

125. Nevertheless, in order to clarify what the JC’s initial idea with its proposed approach was, the relevant article was redrafted to clarify that the reference point from which the time limit should apply is the time when the information is successfully submitted to the collection body for the purpose of it being made accessible on ESAP.

126. Furthermore, the draft ITS has been amended to clarify that the time limits may be derogated in case of certain limited and exceptional circumstances.

18) [for users of information only] Do you currently access price and time-sensitive information via
the Officially Appointed Mechanisms or other (private or public) databases? If so, which ones?
If not, how do you access such information?

127. 16 respondents provided input to this question aimed at better understanding the current data use of investors. Most respondents agreed that they currently access time-sensitive information either via private databases or via specific announcements and financial documents reports directly accessible via companies’ websites, at investor events or in press releases.

128. Respondents confirmed as well that they expect this to continue to be the case after ESAP and that the proposed time limit delay does not affect the usefulness of the data as they do not see it as time sensitive. They suggested that most time sensitive information already has in place communication means through the companies that are readily available to data users.

129. Most respondents also believed that the majority of information contained in ESAP is not time-sensitive and therefore ESAP will not be primarily used for accessing time-sensitive information.

130. A few respondents indicated that the information is currently accessed via the national OAM. One respondent in particular argued that the OAMs will continue to be the only official source of information and therefore will continue to be their primary source of information. The JC points out that this latter is not accurate and that with the entry into force of ESAP, ESAP also will become an official source of public information alongside the OAM and the other CBs. This means that the information made available on ESAP, in the original language in which it was prepared, is to be considered as official information disclosed to the public. Specific requirements have been introduced by the European co-legislators with the aim to guarantee authenticity and integrity of the information available on ESAP.

131. A couple of respondents highlighted that while they currently access time-sensitive information via private databases, they do so at very high cost and they believe the overall approach to ESAP should be more ambitious, i.e. go beyond the current mandate and be less focused on the current limited importance tasks of the OAMs and more on creating better and faster access to the potential use of ESAP data for investors.

132. Some respondents argued that the current delay for accessing certain information via private databases or OAMs is not only too long and costly, but also unevenly distributed across the EU. These respondents argued that real time access of all ESAP information would be the only solution to ensuring a level playing field across the EU. Please refer to Question 17 for the JC response to this point.

Proposed way forward

133. Given the fact that most respondents confirmed that they do not see ESAP primarily as a source of time sensitive information and that they believe the current 60-minute time limit does not affect the value of the data in any significant manner (see Question 19), the JC suggests keeping its approach to the time limits as it is in the proposal , which best seems to balance the needs of data users while keeping an eye on the technical needs of CBs when it comes to processing the information and/or any obligation they might have (stemming from sectorial legislation) to also publish the information at their level.

19) Do you expect that a maximum time delay of sixty minutes between when information is available at the level of the collection body and when it is available on ESAP will diminish the usefulness of ESAP? If so, what maximum time delay would you consider acceptable?

134. 23 respondents provided input to this question. The vast majority of respondents agreed that the proposed 60-minute delay for publication in ESAP will not affect the usefulness of the data. They clarified that given the current scope of information in ESAP and the frequency of publication of most of the data, no data user expects to have this information immediately as a source of information. They also clarified that for information that might be time-sensitive, there are other more direct sources that will remain the golden “go-to source”. For these time-sensitive purposes urgent needs, one respondent suggested that ESAP should include links to the OAMs websites directly. However, the JC wishes to highlight that including a link on the ESAP platform to a CB website would also not be immediate and therefore would provide no significant advantage over the proposed approach.

135. Certain respondents argued that there might be value in having different time limits depending on the types of information, given the difference in frequency and use of the data. However, no specific suggestion on how this decision should be made was raised in this regard within the responses.

136. Three respondents, however, explained that the proposed delay would be problematic, two of them arguing that this would greatly harm stakeholders and distort the market and one stating that the current approach risks making ESAP a “secondary” or “cold storage environment”. These respondents seemed to assume that the proposed time delay is due to the need to validate the data twice, once at national and once at ESAP level, which they believed could be solved by having a uniform EU quality assurance rules engine that would validate all data centrally at ESAP without going through the national validations.

137. In these regards, the JC wishes to highlight that the ESAP Regulation’s Article 5 paragraph 1(c) establishes that the task of automatically validating data submitted by entities is attributed to the CBs. The proposed time delay is not due to ESMA needing to revalidate the data, but rather aims to minimise implementation costs for CBs and to leverage as much as possible on existing reporting systems, which mostly do not require real-time transmission of information to ESMA but rather allow NCAs some flexibility. Furthermore, although the JC agrees that information should be provided by CBs to ESAP as soon as possible as indicated in the draft ITS, it is deemed appropriate to specify that the maximum allowed delay would be one hour so as to set a maximum expected delay, without which implementation would risk lacking uniformity across the EU.

Proposed way forward

138. Given the majority view that the proposed time limits do not affect the quality or usefulness of the data, the JC suggests proceeding with the current approach concerning the time limits.

(vii) The indicative list and characteristics of formats that are acceptable as data extractable formats and as machine readable formats

20) Do you agree with the indicative list of formats and characteristics proposed? If not, what alternative formats or characteristics would you recommend?

139. 26 respondents provided input to this question. Of these, 24 provided explicit support to the JC proposals.

140. One respondent did not agree because it feared that it would no longer be possible to include graphs and images in data extractable documents because graphs and images are not, themselves, extractable. It should be noted however that the proposals do not intend to require graphs and images to be removed from documents. As also explained in the section regarding Question 1 of the Consultation (on technical automated validations), graphs and images will be accepted in both data extractable and machine-readable documents. However, graphs and images should not substitute regulatory disclosures but rather complement them. Graphs and images should not contain regulatory information which is not provided also in textual or in another type of machine-processable format. In light of that, it is deemed that no conversion effort will be necessary to meet the proposed requirements.

141. Several respondents suggested other formats should be included in the proposed list. However, the mandate requires the JC to specify an “indicative” list, therefore not a complete or definitive list. For that reason, the JC proposes that the list should include for now the data extractable and machine-readable formats in scope of ESAP as of today, but that any other data extractable or machine-readable format required by sectorial legislation to be submitted to ESAP in the future should also be acceptable. The indicative list included in the draft ITS only covers formats which are currently mandated for any of the information currently required by sectorial legislations. For that reason, XBRL-JSON is not explicitly included in that indicative list and JSON and xHTML have been removed compared to the list included in the Consultation Paper. Furthermore, HTML has been added since submission of data extractable information might take place via web forms as it is the case already today.

142. One respondent disagreed with the definitions of machine-readability and data extractability. However, as discussed in the CP, it should be noted that these definitions stem from Level 1 legislation and therefore it would not be appropriate for the JC to provide a different or alternative definition.

143. Several stakeholders strongly suggested that proposal for mandating additional disclosures in a machine-readable format should be consulted upon and, if mandated, enough time should be given for implementation. A couple of respondents mentioned that with regards to PRIIPS/UCITS information it would be essential that the machine-readable format mandated is consistent with that which already exists in the market. The JC confirms that, on the basis of the respective founding regulation, any draft ITS/RTS by the three ESAs will be consulted with the public and that existing practice will be duly taken into account. Furthermore, the Omnibuses require the ESAs to carry out cost/benefit analysis in relation to all sectorial RTS/ITS in the context of ESAP.

144. Finally, several stakeholders, whilst agreeing with the proposal, mentioned the fact that the medium-term value of ESAP will be significantly impaired if ESAP mainly gives access to PDF documents, which are difficult to consume on a large-scale basis, thus encouraging the JCs to consider mandating additional disclosures in a machine-readable format.

Proposed way forward

145. In light of the feedback received, the JC intends to maintain its proposed approach in the final ITSs.

4.1.2 Functionalities of ESAP

(i) The characteristics of the (data publication) API

21) Do you agree with the proposed characteristics of the API for data publication? If not, what alternative characteristics would you recommend?

146. 24 respondents provided input to this question. Of these, over half fully endorsed the JC approach. No one disagreed with the proposals put forward.

147. Some respondents provided additional comments. One respondent noted that ESMA should guarantee a maximum availability of the API during the day. It is worth highlighting in these regards that ESMA is mandated by the ESAP Regulation Article 11 to "ensure that ESAP is accessible for at least 97 % of the time per month”. Although there is no requirement towards the API specifically, ESMA is setting up ESAP to ensure that it is accessible for at least

97 % of the time per month, and therefore the API component will also benefit from the high availability design of the system.

148. Several respondents noted that it would be useful if ESMA made available the information not only in the same format in which it is received, but also in additional formats and especially in Excel / csv. The JC notes that there is no obligation in the ESAP Regulation to provide such functionality but the possibility of doing so might be considered in the future.

149. It is also worth clarifying in this regard that only a few disclosure regimes are mandated in a specific format, and in practice PDF is commonplace wherever no format requirement is specified. As such there is no expectation that the same information will be sent to ESAP by different preparers in different formats, with the exception of financial reports pursuant to the Accounting Directive and/or to the Transparency Directive for which format requirements might be established at national level.

150. Some respondents highlighted the need for ESMA to ensure that information can be downloaded also in bulk and without human intervention (i.e. machine-to-machine). It is worth noting that ESMA has an obligation to ensure a download functionality, also of large quantity of data, by Article 7(f) of the ESAP Regulation. We also take note of the fact that users consider it important that data can be downloaded without human intervention.

151. One respondent pointed to the API implemented by the SEC EDGAR system and by the UK Company House as best practices to look at. Two stakeholders suggested in particular the use of open technical standards like HTTP REST API. The JC notes that it goes beyond the scope of this ITS to indicate which API will be implemented but that the ITSs set out only the characteristics. The recommendations will be duly taken into consideration during IT implementation if deemed relevant.

152. One respondent also asked that a rendering service is made available on ESAP. It is worth noting in this respect that there is no mandate for the JC to specify this in this ITS, but that an information viewer for ESAP information is already required by the ESAP Regulation under Article 7 paragraph 1(d).

153. Several stakeholders asked for clarifications about fees. It should be clarified that ESAP will not charge fees for the basic functionalities of ESAP and that the ESAP Regulation only requires ESMA to charge fees for specific services with high maintenance and support cost or that involve searches for and downloads of large volumes of information (Article 8(2)). For that reason, ESMA has decided not to prioritise for the time being the development of the RTS envisaged by Article 8 (5) of the ESAP Regulation since no specific services are expected to be offered for now.

154. One respondent argued in response to Question 15 that proposing data via an API would be of limited use if the actual processing of data required after extraction is prohibitive for most actors. In these regards however it is worth highlighting that data for users will not only be accessible via the API, but also via an online search function as required by Article 7 of the ESAP Regulation, which includes also a description of the core features of such online platform. Therefore access to data will be possible not only via an API but also via the online search function, which is expected to be accessible even to people without advanced technical skills, such as retail investor.

155. One respondent suggested that it would be useful to add a feature allowing to select only filings that have been added after a certain point in time, in order to make it easier for users to incrementally obtain new filing. The JC notes that this is beyond the scope of the ITSs but it will be considered as a feature.

Proposed way forward

156. In light of the feedback received, the JC intends to maintain the approach proposed in the CP.

(ii) The specific legal entity identifier

22) Do you agree with the proposal to specify that the legal entity identifier should be the ISO 17442 LEI code? If not, what other identifier would you suggest and why?

157. The vast majority of respondents to this question supported the use of ISO 17442 LEI as the sole legal entity identifier for the purpose of ESAP. Three respondents suggested to consider using the VAT identifier, as an addition or as an alternative to the LEI. One respondent representing a national Ministry of an EU Member State recommended the use of EUID at least for entities not having an LEI.

158. The JC believes that the LEI is a more appropriate identifier for ESAP than the VAT identifier or the EUID at this stage. In terms of reporting costs, the use of LEI would minimise the reporting burden on entities and supervisors, because the majority of entities in scope of ESAP, and most notably all entities in scope of phase 1, should already have an LEI. Some entities in scope of phase 2 and 3 may not have an LEI. However, since phase 2 and 3 reporting will only start in 2028 and 2030 respectively, adopting a different identifier at this stage and especially for phase 1 would entail additional efforts for entities because entities would need to use an additional identifier compared to the one they already report today. Furthermore, it would entail additional effort for phase 1 CBs since their systems are already set up to receive the LEI and would need to be modified to accept a different identifier. The LEI is also well known to investors, including cross-border investors, as it is adopted in a wide variety of legislative frameworks. The use of a new, non-global identifier might impair the visibility of entities towards cross-border investors, including non-European ones, and limit their exposure to new funding sources.

159.
Furthermore, the LEI database has strict data quality protocols to ensure that its reference data is reliable and that there are no duplicates (the existence of which would impair the searchability of entities). All LEIs can be downloaded in bulk and therefore users (including investors and supervisors) are able to obtain a golden copy of the reference data pertaining to all entities on which basis the quality and reliability of data can be easily verified. The same cannot be achieved at this stage for VAT identifiers nor with the EUID.

160. The use of the LEI would also ensure that different information reported pursuant to different legislations can be “linked” to the same entity, since they all use the same identifier which acts as a “key” across different databases. If multiple identifiers are introduced for ESAP, the information on ESAP will not be fully interoperable with information reported under other financial markets legislations. Finally, ESAP will be able to source additional information from the GLEIF database without adding extra metadata requirements to offer further search functionalities on the basis of other criteria specified under Article 7 paragraph 3 of ESAP. VAT number and EU ID reference data cannot be used for the same purpose at this stage.

161. The JC acknowledges that the LEI is a paid-for identifier (approximately 60 euros per year) but also notes that none of the market participants responding to the consultation indicated that this cost would be an issue.

162. The JC takes this opportunity to clarify, in response to a point raised by a respondent, that LEIs need to be renewed by entities once a year at least - however, if an entity needs to update the LEI data in between renewal dates it can do so free of charge and the GLEIF database will reflect that change swiftly. Automated validations will be put in place in ESAP whenever appropriate on the basis of requirements included in sectorial legislation in order to ensure that entities have renewed their LEI status whenever relevant.

163. The JC notes that some entities submitting information to CB for ESAP purposes in phase 2 and 3, including entities submitting information on a voluntary basis may not all have an LEI, contrarily to entities in scope of phase 1. However, the JC deems it inappropriate to introduce an alternative identifier for entities in scope of ESAP in phase 1, also considering how quickly the landscape of legal identifiers is moving both at EU level and at international level. The JC believes it would be more opportune to re-assess whether an alternative or an additional identifier could or should be introduced for ESAP phases 2 and 3 after phase 1 reporting has started in Q3 2026.

164. Finally, one respondent expressed concerns about the fact that no specific provision is made for the safeguard of personal data. For more information as to why the JC did not provide for additional safeguards on personal data please refer to paragraph 95.

Proposed way forward

165. In light of the comments received, the JC intends to maintain its proposed approach.

(iii) The classification of the types of information

23) Do you agree with the proposed approach with regards to types of information? If not, what additional/ alternative type of information do you recommend?

166. 27 respondents provided views on this question. Of these, over half supported the draft proposals, with the remaining mainly raising questions or making suggestions to improve the draft without disagreeing with the overall approach.

167. One respondent disagreed with the category of “other”, as it argued that such category would prevent any predictability. The JC notes that this is necessary to facilitate filing of new types of information that may not yet been captured in the ESAP ITS. Since new types of information will only be included in ESAP if Level 1 legislation requires it, and Level 1 legislation is subject to negotiations and normally gives ample time for implementation, stakeholders will be informed in due time that a new type of information will have to be submitted and thereafter will be available in ESAP, which in turn will ensure predictability.

168. Another respondent wished to clarify that the responsibility for the metadata “type of information” must lie with the submitting entity. The JC confirms that “type of information” is consistently one of the new metadata that sectoral legislation requires reporting entities to report to CBs.

169. One respondent pointed out that since 1 January 2023 a key information document that meets the requirements of the PRIIPs Regulation is considered equivalent to key investor information. The JC notes that indeed for UCITS marketed to retail investors, it is mandatory to produce a PRIIPs KID for all PRIIPs investment funds, including UCITS, and therefore a KII no longer has to be produced. For UCITS marketed to professional investors only, it is still possible for managers to produce a KII and not a KID. Therefore, both types of information included in the CP are relevant.

170. Another respondent suggested that the CRA Regulation types of information should be subject to some drafting changes, which have been taken onboard in the final draft ITS. This respondent also suggested clarifying which information should be provided by whom. The JC highlights that the information that needs to be submitted by entities is specified in sectorial legislation as amended by the Omnibus Directive or Regulation and should not be further specified in this ITS.

171. One respondent suggested that the type of information “statement of the persons responsible for these reports” for the Transparency Directive (Directive 2004/109/EC) is not necessary as it is a constituent of the financial statement. The JC agrees, and both types of information relating to this have been removed.

172. Another respondent asked for clarification regarding interactions between the Transparency and the Accounting Directives since the categories included in the consultation paper for these two directives are similar as regards periodic filings. The JC takes this opportunity to point out that Article 9 of the Omnibus Directive has introduced a new article 33a to the Accounting Directive. Paragraph 2 therein clarifies that “Where an undertaking has submitted the information referred to in paragraph 1 of this Article to an Officially Appointed Mechanism pursuant to Article 23a of Directive 2004/109/EC in order to make that information accessible on ESAP, that undertaking shall be deemed to have fulfilled its obligations under paragraph 1 of this Article, provided that this information complies with all requirements on metadata set out in paragraph 1 of this Article”. Therefore, when an issuer submits information to the OAM to fulfill its reporting obligations under the Transparency Directive, they shall not resubmit it to also fulfil their requirements under the Accounting Directive as those requirements will be considered already fulfilled.

173. A response suggested providing end users with information on who is the relevant CB. The JC clarifies that level 1 already requires ESMA to provide a search function on the basis of the relevant CB, and that this information will be provided to ESMA by the CBs themselves as metadata.

174. Another respondent asked for clarification regarding the interactions between CRAs, ERP, RADAR, and periodic reporting. The JC takes note of this request but highlights that it is beyond the scope of this Final Report and of the ITSs to provide such information.

175. Another respondent suggested that there should be no category for the translation of the appendix to the URD and for the translation of the summary. The JC disagrees with this suggestion, as issuers are required to prepare a translation of the appendix according to Article 26(4) of the Prospectus Regulation. In fact, translation of the appendix is already a type of document included in the Prospectus Register.

Proposed way forward

176. In light of the responses received, the JC intends to maintain the overall approach as proposed in the Consultation. Some drafting changes were made in order to align the terminology with the L1 requirements. Furthermore, certain types of information (namely the various components of the annual and half-year financial reports) were removed in order not to create an unnecessary burden on issuers. However, in light of the increasing attention for sustainability information and the fact that one of the objectives of ESAP is to facilitate accessibility to such information in particular, in order to facilitate searchability of the sustainability statements of issuers, a specific type of information is proposed with regards to the management report (which includes the sustainability statement) to ensure that the sustainability information prepared by issuers are easily identifiable regardless of whether it is

included within a stand-alone annual financial report or whether it is included as part of a separate management report. Further guidance may be provided in L3 if deemed necessary.

24) Do you think that information required at national level pursuant to Article 3(1) of the Transparency Directive (so-called gold plating) should be captured by certain specific types of information? Or would you prefer such information be captured by one generic category, namely “Additional regulated information required to be disclosed under the laws of a Member State”?

177. 24 respondents provided responses to this question. There was mixed support, with ten in favour of the generic category "Additional regulated information required to be disclosed under the laws of a Member State”, ten against and the rest not expressing a clear view.

178. Several respondents suggested that it would be more predictable and user-friendly to create specific categories for certain specific types of information mandated only at national level rather than having one generic category that would encompass a wide and less defined area of application. At the same time, several respondents encouraged the simplicity of having a generic category as it standardizes reporting across jurisdictions that may not have harmonized terminology and does not create additional burden on entities by maintaining the status quo.

179. Given the divergence of views on this question, it is proposed that a generic category will be maintained at this stage and this decision will be re-assessed in the future if justified by feedback from users and from submitting entities. In light of the feedback received, the JC intends to maintain its proposed approach.

(iv) The categories of the size of the entities

25) Do you agree with the proposed approach with regards to the categories of the size of the entities? If not, what alternative approach would you suggest and why?

180. 21 respondents provided input to this question. A majority of respondents supported the proposed approach to only specify size categories when Level 1 legislation already foresees these. They also agreed that this should be done in a manner that allows to specify the legislation relevant for the search and thereafter the specific size category. Certain respondents put into question the general usefulness of this criteria as a search function and explained that most users will rather search by specific entity rather than by legislation-related size.

181.
When it comes to those respondents who agreed with the overall approach, certain clarified the size categories that they see as relevant or not for search purposes. One respondent suggested that only definitions by size contained in the Accounting Directive concerning undertakings should be included, while another suggested that size of investment firms should be expanded to distinguish between those subject to CRR/CRD, those small and non-interconnected ones and those subject to IFR/IFD.

182. When it comes to those respondents who disagreed with the proposed approach, two respondents suggested that there should not be any size category included whatsoever, due to the lack of use for this functionality in the search function. Another respondent suggested that each individual company providing data to ESAP should be allowed to identify itself by size by choosing the threshold it sees more relevant based on the data they are providing to the ESAP.

183. With regards to these points, the JC highlights that this ITS responds to a mandate set out in L1. Furthermore, which entities need to report a category by size is specified in sectorial legislation as amended by the ESAP Omnibus Directive or Regulation. Therefore, it is beyond the scope of this ITS to establish whether this field should be reported, and which entities should report it.

Proposed way forward

184. Given the fact that most respondents agreed with the JC’s proposed approach and that no other alternative approach was identified that would allow for the JC to fulfil the mandate, we suggest proceeding with the original proposal of including those categories by size that are already defined in Level 1. The JC has included all those that are in force at the moment of approval of the Final Report.

185. Certain changes have been made to reflect the fact that not all entities in scope of ESAP are mandated to report a category by size on the basis of the Omnibus Directive /Regulation to ensure alignment between Level 1 and Level 2 legislation. Consideration will be given to adapt those thresholds in the future, if needed, based on inflationary or otherwise relevant reasons.

26) Do you agree that it would be disproportionate to the purpose of the ESAP search function to introduce new categories by size for reporting regimes where currently no size category is foreseen in level one legislation? If not, for what additional categories of entities would you add a size category and on the basis of what thresholds?

186. 16 respondents provided input to this question. All respondents agreed that it would be disproportionate to introduce new categories by size only for the purpose of the ESAP search function. Respondents signaled the fact that not only is size category not very relevant for the search function but also that any attempt to introduce a new one is bound to fail due to the lack of existing metadata. One respondent argued that for those regimes where no existing definition by size exists already, attempting to introduce one is likely to fail.

187. Two respondents suggested no size category should exist in general for the search function.

188. Several respondents noted that if no size category is already foreseen for certain reporting regimes in Level 1, size is likely to be not relevant for those entities. One respondent supported the approach since it respects the principle of not adding new information requirements to entities.

Proposed way forward

189. In light of the feedback received, the JC intends to maintain its proposed approach.

27) Do you think it would be useful to leverage on the thresholds introduced by DORA for the classification by size of at least some entities in scope of ESAP, such as IDD intermediaries and PRIIS manufacturers? If not, why not? If yes, are there other entities in scope of ESAP for which you think the thresholds defined in DORA would be applicable and/or useful?

190. 14 respondents provided input to this question. Respondents expressed mixed views about this question. Overall, the majority expressed the view that the introduction of any additional classification by size would not be necessary and that it might introduce problems of interpretation of the size categories for users i.e. how to distinguish data flows for which the size category is defined in the Level 1 pursuant to which the information is prepared and those for which the size category comes from the DORA definitions.

191. Respondents also highlighted problems this might introduce when it comes to data quality and use of data for comparative purposes. Some respondents noted that introducing the DORA categories would create practical problems that would outweigh the benefits of a search functionality.

192. Two respondents agreed on the usefulness of introducing these DORA thresholds for the purpose of data provided to ESAP. One respondent highlighted their usefulness only for the purposes of IDD intermediaries and PRIIPS manufacturers.

Proposed way forward

193. The feedback to this question in conjunction with the responses to other questions concerning the size categories makes it clear that the usefulness of ESAP data is based on its reliability and comparability. This, alongside the fact that most respondents agree that the search by size is not a function that is seen as fundamental for the user for all categories of entities in scope, leads the JC to suggest that no changes should be made to its initial proposal.

194. Most respondents agreed the best approach is to rely on Level 1 definitions existing for the relevant data provided under each regime. The introduction of certain definitions not stemming from that approach and that applies only to certain data would risk creating confusion for users.

(v) The characterization of industry sectors

28) Do you agree with proposed approach with regards to the categorisation of industry sectors? If not, what approach would you suggest and why?

195. 18 respondents provided input to this question. Of these, two thirds agreed to the proposed approach of using NACE code for non-financial industry, but some provided suggestions regarding the classification for the financial service sector.

196. One respondent suggested the JC to integrate EMIR reporting identification of financial entities into the NACE classification system to minimize the complexity. However, this is beyond the JC mandate. Another respondent suggested to leverage on Regulation (EU) No 549/2013 on the European system of national and regional accounts (with subsectors S.121 to S.129) to add a second layer for the classifications of financial entities. One respondent suggested using the STOXX600 sector approach for capital markets industry classification. They also suggested separating financial and banking activities. Another respondent suggested using the ICB model industry classification, which is owned by FTSE Russel/ LSEG. However, NACE is deemed more appropriate to use since it is non-proprietary and is widely used in the European Union. Given the majority of respondents supported the JC initial proposal, these suggestions were not taken onboard.

197. Three respondents suggested adding a second layer of the classification code since the first level NACE code might be too generic. However, it was deemed preferable to maintain the proposed approach and avoid using the second level of the NACE code in order to minimize the burden on entities.

198. One respondent highlighted that Commission Delegated Regulation (EU) 2023/137 introduced a new NACE Rev. 2.1 classification and suggested the JC to use it instead. This suggestion was deemed relevant and taken onboard.

199. One respondent mentioned that ESAP should facilitate the assignment of the NACE code to LEI-identified companies, thereby mapping the link between enterprise (LEI/ISIN) and sector (NACE). It should be highlighted however that the GLEIF database as of today does not include the NACE code and therefore this proposal is not practicable for now.

200.
Two respondents mentioned that the classification needs to be in line with the classification used for ESG reporting. Although both systems adopt the NACE code and are therefore consistent with each other, it should be noted that in the context of ESAP the sectors are only needed for the search function. Therefore it is deemed overly burdensome for entities, especially those not in scope of ESG reporting, to adopt the same level of granularity of classification used under ESG reporting by issuers.

201. One respondent mentioned that there is a need for providing an EU taxonomy-related mapping. However, this is outside the scope of the present mandate.

202. Finally one respondent suggested to add ESG rating providers to the list of sectors as well, since they shall report to ESAP. Separating ESG rating providers from other sectors would improve the search function while also increasing the visibility of smaller ESG rating providers. Therefore this recommendation has been adopted, and a change has been made in the draft ITS.

Proposed way forward

203. In light of the feedback received, the JC proposes to:

Add ESG rating providers to the list of categories;
Adopt the use of the NACE Rev 2.1 since the Commission Delegated Regulation (EU) 2023/137 has amended the previous Regulation (EC) No 1893/2006 which established NACE Rev 2;
Maintain the approach unchanged in other regards.

29) Do you think additional or fewer sectors would be appropriate for the ESAP search function? If so, which ones would you propose to add and/or remove?

204. 17 respondents provided input to this question. The majority agreed with ESMAs approach and did not think there is a need to add or remove sectors for the ESAPs search function.

205. Two respondents encouraged the JC to add the second level code of the NACE classification in ESAP to achieve a higher degree of granularity. Also, they believed that the numerical classes are better known by companies than the letter codes, thus leading to less misunderstandings.

206. One respondent suggested that if there are other financial products with possible public disclosures in ESAP, directly or through other regulation such as Transparency or Prospectus or PRIIPS, these products should also be identified in Table 3. At minimum, it was suggested that “PRIIPS product – other than UCITS” should be added. It should be highlighted however that the list of sector does not include products as such and therefore it would be not appropriate to list types of financial products in that list.

Proposed way forward

207. In light of the feedback received, the JC intends to maintain overall approach unchanged since the majority of respondents did not believe that there was a need to add or remove sectors for the ESAP search function. As already mentioned, adding the second-layer of the NACE categorisation is deemed to be overly burdensome for entities.

5. Draft ITSs

5.1 ITSs specifying certain tasks of collection bodies

COMMISSION IMPLEMENTING REGULATION (EU) 202X/XXX of XXXX laying down implementing technical standards with regard to certain tasks of the collection bodies pursuant to Regulation (EU) 2023/2859 of the European Parliament and of the Council

(Text with EEA relevance)

THE EUROPEAN COMMISSION,

Having regard to the Treaty on the Functioning of the European Union,

Having regard to Regulation (EU) 2023/2859 of the European Parliament and of the Council of 13 December 2023 establishing a European single access point providing centralised access to publicly available information of relevance to financial services, capital markets and sustainability, and in particular Article 5 paragraphs 10 and 11 thereof,

Whereas:

(1) It is important to ensure that collection bodies make information available on the European Single Access Point (ESAP) in a harmonised fashion, drawing to the extent possible upon existing collection procedures and infrastructures in place at Union and at national level. To this purpose, Article 5 paragraph 10 of Regulation (EU) 2023/2859 mandates the European Banking Authority, the European Insurance and Occupational Pensions Authority and the European Securities and Markets Authority (European Supervisory Authorities) to specify how certain tasks of collection bodies should be performed.

(2) Article 5 paragraph 1 point (c) of Regulation (EU) 2023/2859 requires collection bodies to perform technical automated validations to verify that the information has been submitted using a data extractable or, where required by Union law, a machine-readable format, that the metadata is available and complete and that the information contains, where required, a qualified electronic seal. The aim of these validations is to ensure a uniform quality of information in ESAP. In order to ensure that the technical automated validations are performed by the collection bodies in a consistent manner and thus, that the overarching goal of a uniform quality of information is achieved, this Regulation clarifies how the collection bodies should carry out the validations required by ESAP. Article 5 paragraph 4 of Regulation (EU) 2023/2859 requires collection bodies to notify entities of the rejection or of the removal of the information and the reasons thereof within a reasonable timeframe. In order to ensure that this requirement is applied consistently by the collection bodies and that entities submitting the information receive the rejection notification in a timely manner, this Regulation sets out the maximum period within which collection bodies should notify the entities of the rejection of information. In exceptional circumstances, such as major accidents and errors, deliberate attacks and natural events, collection bodies may notify the entities beyond that maximum period.

(3) Where allowed by the Member States, the collection bodies may require a qualified electronic seal as a means to ensure appropriate levels of authenticity, integrity and non-repudiation of the information submitted to ESAP. In order to facilitate the cross-border interoperability of the qualified electronic seals accompanying the information submitted to ESAP, the qualified electronic seal required by a collection body should comply with the characteristics set out in the Commission Implementing Decision (EU) 2015/1506. In order to ensure that the qualified electronic seal remains adequate over a long period of time, it should be at conformance level Long-Term (LT) or higher. Furthermore, to further strengthen the authentication of the information submitted to ESAP, the digital certificate accompanying the seal should contain the ISO 17442 LEI code identifying the entity using the seal.

(4) Directive (EU) 2019/1024 on open data and the re-use of public sector information aims to promote the use of standard public licences available online for re-using public sector information. The Commission’s Guidelines on recommended standard licences, datasets and charging for the re-use of documents (3 ) identify Creative Commons (‘CC’) licences, and in particular the most recent version (4.0) as an example of recommended standard public licences. CC licences are developed by a non-profit organisation and have become a leading licensing solution for public sector information, research results and cultural domain material across the world.

(5) Since the purpose of ESAP is to facilitate the use and re-use of information available, it is appropriate to refer in this Regulation to Creative Commons public domain dedication (CC0) for all types of information, except for those to which copyright and other related rights are attached. Accordingly, with regards to the type of information covered by copyrights or other related rights, Creative Commons Licence BY-NC-ND should be applied, in order to restrict the

[3] Commission notice — Guidelines on recommended standard licences, datasets and charging for the reuse of documents OJ C 240, 24.7.2014, p. 1.

commercial use of that information. A licence equivalent to the Creative Commons suite may be used by collection bodies.

(6) The ESAP is conceived of as a platform providing direct and easy access to information, which should be collected by collection bodies. Information should be thereafter provided to ESAP via an application programming interface (API). Therefore, it is relevant that this Regulation describes the data exchange method through which information should be provided to ESAP, the data formats supported, the type of protocols on which the API relies, the access control applied in order to allow ESAP to collect data from the designated collection bodies and the ownership of the API update or modification process. Any changes to the API should be identified in due time, and a clear timetable should be set out for implementation.

(7) This Regulation should specify the allowable characteristics of the metadata provided to ESAP, in order to ensure convergence and facilitate implementation. Directive (EU) 2023/2864 and Regulation (EU) 2023/2869 of the European Parliament and of the Council of 13 December 2023 specify the metadata elements which entities should make available to collection bodies when submitting information. All such metadata should be made available to ESAP by collection bodies. Furthermore, certain metadata should be provided by collection bodies on the basis of information provided by entities to ensure that the relevant metadata is available for the ESAP search function. Additional metadata which are technical in nature should be provided by collection bodies to ESAP in order to ensure the functioning of ESAP.

(8) The Global Legal Entity Identifier Foundation (GLEIF) database is an online global source for open, standardized and high-quality legal entity reference data maintained by the Global LEI Foundation. In order to ensure that the ESAP can provide a search function on the basis of the criteria set out in Article 7(3) of the ESAP Regulation without creating an additional burden on entities, ESMA and collection bodies could derive certain metadata from the GLEIF Database on the basis of the legal entity identifier specified by Article 2 of Commission Implementing Regulation xx/xxx [ITS on ESAP functionalities] which is provided to them. This would limit the burden of reporting, since entities would be making available metadata to the Global LEI Index and update it only when relevant rather than providing it alongside each submission to collection bodies. These metadata are: the names of the entity that submitted the information, the names of the legal person to which the information relates, the country of the registered office of the legal person to which the information relates.

(9) Information should be made available on ESAP as soon as possible for it to be valuable to users. For this reason, the time delay for collection bodies to make available the information to ESAP should be as short as possible. The time limit should strive to limit the delay between the information being available to the public and it being accessible on ESAP. For this purpose, the point of reference should always be the moment when information has been submitted to the collection body for the purpose of making that information accessible on ESAP and the submission of the information has passed the technical automated validations.

(10) The time limit should be triggered only when the purpose of the submission of the information is making that information accessible on ESAP. Therefore, when information is submitted to the competent authority in its capacity of competent authority for other purposes such as approval of that information or when the information is under embargo, information should not be deemed to have been submitted to the collection body for the purpose of making it accessible on ESAP.

(11) The time limits should be without prejudice to other obligations that might apply to collection bodies stemming from other binding Union legislative acts, such as the obligation to perform additional data validations or the obligation to make information accessible to ESMA within different time limits than those specified in this Regulation.

(12)
In duly justified exceptional circumstances such as major accidents, errors, deliberate attacks and natural events, collection bodies may provide the information beyond the time limits specified in this Regulation provided that ESMA is duly informed. Since this process cannot be carried out fully automatically, collection bodies should not be required to inform ESMA of such circumstances outside of their working hours.

(13) Article 2 paragraph 1, point (3) of Regulation (EU) 2023/2859 defines the data extractable format. Article 2 paragraph 1, point (13) of Directive (EU) 2019/1024 defines the machine- readable format. Consistently with these definitions, and in light of the current technological options and of the formats used for the preparation of the information in scope of the ESAP, information in HTML, PDF and txt format should be accepted as data extractable as long as the text contained therein can be extracted. Information in XBRL, XBRL-xml, XBRL-csv and XML and Inline XBRL formats should be accepted as machine readable because software applications can easily identify, recognise and extract specific data contained therein. These formats are included in the indicative list of acceptable formats because these are the formats currently required for disclosure frameworks in scope of ESAP. The list is not a closed list of formats and additional data extractable and machine-readable formats should be accepted where mandated for information in scope of ESAP. Since machine-readable formats also fulfil the requirements of data extractability, all machine-readable formats should be deemed acceptable also as data extractable formats.

(14) This Regulation is based on the draft implementing technical standards submitted to the Commission by the European Securities and Markets Authority, the European Banking Authority and the European Insurance and Occupational Pensions Authority.

(15) The Joint Committee of the European Supervisory Authorities referred to in Article 54 of Regulation (EU) No 1093/2010 of the European Parliament and of the Council4 , in Article 54 of Regulation (EU) No 1094/2010 of the European Parliament and of the Council5 and in Article 54 of Regulation (EU) No 1095/2010 of the European Parliament and of the Council6 has conducted open public consultations on the draft implementing technical standards on which this Regulation is based, analysed the potential related costs and benefits and requested the advice of the Banking Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1093/2010, the Insurance and Reinsurance Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1094/2010, and the Securities and Markets Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1095/2010.

[4] Regulation (EU) No 1093/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Banking Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/78/EC (OJ L 331, 15.12.2010, p. 12).

[5] Regulation (EU) No 1094/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Insurance and Occupational Pensions Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/79/EC (OJ L 331, 15.12.2010, p. 48).

[6] Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331, 15.12.2010, p. 84).

HAS ADOPTED THIS REGULATION:

Article 1

Technical Automated validations

1. Where a specific-machine readable format is required in any binding Union legislative act referred to in Article 1 paragraph 1, point (a) of Regulation (EU) 2023/2859, collection bodies shall verify that the information submitted to them pursuant to that act is compliant with the machine-readable format specified therein.

2. Collection bodies shall verify that the information submitted to them, other than the information referred to in paragraph 1:

a) is submitted in one of the formats referred to in Article 7(1) of this Regulation or in other data extractable format mandated by any binding Union legislative act, and

b) that the text contained in the submitted information can be extracted by a machine.

3. Collection bodies shall verify that:

a) the metadata required by the binding Union legislative act under which the information is provided is available and compliant with the characteristics specified in the Annex to this Regulation;

b) the metadata is consistent with the other metadata provided by the same entity;

c) where provided, the metadata indicating the legal entity identifier of the submitting entity is valid at the moment of submitting the information to ESAP;

d) where provided, the metadata indicating the legal entity identifier of the entity to which information relates is valid at the date or period to which the information relates.

4. Where a qualified electronic seal is required pursuant to the Article 5 paragraph 9 of Regulation (EU) 2023/2859, collection bodies shall:

a) perform the validations set out in the Article 32(1) of the Regulation (EU) 910/2014, and

b) verify that the qualified electronic seal accompanying the information submitted to them complies with the characteristics defined in Article 2 of this Regulation.

5. Collection bodies shall reject information that does not comply with any one of the requirements set out in paragraphs 1 to 4.

6. Collection bodies shall provide the submitting entities with detailed information on the results of the automated validations referred to in paragraphs 1 to 4 within sixty minutes after they have received the information. Collection bodies shall provide those results on the basis of a common template.

7. In duly justified exceptional circumstances, such as major accidents and errors, deliberate attacks and natural events, collection bodies shall be allowed to provide the results of the automated validations beyond the maximum period set out under paragraph 6. In the event of those circumstances arising, collection bodies shall provide the results of the automated validations to the submitting entities within sixty minutes after the resolution of the relevant exceptional circumstance.

Article 2

Characteristics of the Qualified Electronic Seal

1. The qualified electronic seal accompanying the information shall comply with the list of technical specifications set out in the Annex to the Commission Implementing Decision (EU) 2015/1506 and shall be at conformance level LT or higher.

2. The qualified electronic seal shall be based on a qualified certificate in which the submitting entity is identified with the ISO 17442 LEI.

Article 3

Open Standard Licence

The use and re-use of the information made available to ESAP by the collection bodies shall be subject to the conditions of the Creative Commons public domain dedication (CC0) or any equivalent open licence allowing for unrestricted use and re-use of data. This is without prejudice to information covered by copyright and other related rights, the use and re-use of which shall be governed by the conditions of the Creative Commons Licence BY-NC-ND or any equivalent open license.

Article 4

Characteristics of the data collection API

The API for the collection of ESAP data shall:

a) allow collection bodies to send the information, the metadata for that information and, where required, the qualified electronic seal to ESAP and receive feedback on the data exchanged;

b) support the formats for the information specified in Article 7 of this Regulation;

c) support the formats for the metadata specified in Article 5 of this Regulation;

d) rely on secure internet protocols such as SFTP or HTTPS to exchange data via the transfer of files;

e) allow ESMA to implement access control procedures;

f) incorporate any changes or update requested by ESMA to ensure compliance with points (a), (b), (c), (d) and (e).

Article 5

Characteristics of metadata

1. When providing ESAP with the information required by Article 1 paragraph 1, point (a) of Regulation (EU) 2023/2859, collection bodies shall make available to ESAP the relevant metadata in accordance with Table 1 set out in Annex to this Regulation.

2. Collection bodies shall provide the metadata in a common format in accordance with the ISO 20022 methodology. Whenever information is prepared in a machine-readable format pursuant to any of the Union legislative acts under Article 1, paragraph 1, point (a), the

metadata for that information shall be provided either in accordance with the ISO 20022 methodology or in the same format as the information.

Article 6

The time limits

1. Without prejudice to other legal obligations stemming from binding Union legislative acts, collection bodies shall provide to ESAP the information, the metadata for that information and, where required, the qualified electronic seal as soon as possible, and no later than sixty minutes after the information has been submitted to the collection body for the purpose of making it accessible on ESAP and the submission of the information has passed the technical automated validations specified in Article 1 of this Regulation.

2. In duly justified exceptional circumstances, such as major accidents and errors, deliberate attacks and natural events, collection bodies shall be allowed to provide the relevant information beyond the time limits set out under paragraph 1. In the event of those circumstances arising, collection bodies shall inform ESMA as soon as possible during their working hours and provide the information within sixty minutes after the resolution of the relevant exceptional circumstance.

Article 7

Indicative list and characteristics of acceptable formats for the information

1. HTML, PDF and txt formats shall be accepted as data extractable formats, as defined in Article 2 paragraph 1, point (3) of Regulation (EU) 2023/2859, where these allow extraction of text by a machine and are human-readable.

2. XML, XBRL, XBRL-csv, XBRL-xml and inline XBRL formats shall be accepted as machine-readable formats, as defined in Article 2 paragraph 1, point 4 of Regulation (EU) 2023/2859, where these are structured so that software applications can easily identify, recognise and extract specific data, including individual statements of fact, and their internal structure contained therein.

Article 8

Entry into force and application

1. This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.

2. This Regulation shall apply from 10 July 2026.

This Regulation shall be binding in its entirety and directly applicable in all Member States.

Done at Brussels, xx xx xxxx

For the Commission
The President

ANNEX

Table 1: List of metadata

Number	Field	Form
1.	Name(s) of the entity that submitted the information	Free text field up to 500 alphanumeric characters.
2.	Name(s) of the natural or legal person to which the information relates	Free text field up to 500 alphanumeric characters.
3.	Legal entity identifier of the entity that submitted the information	ISO 17442 Legal Entity Identifier (LEI) 20 alphanumeric character code
4.	Legal entity identifier of the legal person to which the information relates	ISO 17442 Legal Entity Identifier (LEI) 20 alphanumeric character code
5.	Type of information submitted by the entity	Taxonomy in accordance with the common list of types of information as set out in Table 1 of Annex to Commission Delegated Regulation xx/xxxx (ITS on ESAP functionalities)
6.	Size of the entity by category that submitted the information	Taxonomy in accordance with the common list of categories of entities by size as set out in Table 2 of Annex of Commission Delegated Regulation xx/xxxx [ITS on ESAP functionalities]
7.	Size of the legal person to which the information relates	Taxonomy in accordance with the common list of categories of entities by size as set out in Table 2 of Annex of Commission Delegated Regulation xx/xxxx [ITS on ESAP functionalities]
8.	Country of registered office of the legal person to which the information relates	ISO 3166 - 2-character country code
9.	Industry sector(s) of the economic activities of the natural and legal person to which the information relates	Taxonomy in accordance with the common list of industry sectors as set out in Table 3 of Annex of Commission Delegated Regulation xx/xxxx [ITS on ESAP functionalities]
10.	Personal data flag	‘true’ – the information submitted contains personal data ‘false’ – information submitted does not contain personal data
11.	Voluntary or mandatory nature of the information submitted	‘true’ – voluntary ‘false’ – mandatory
12.	Date and time when the data was submitted by the entity to the collection body	ISO 8601 date in the Coordinated Universal Time (UTC) time format YYYY-MM-DDThh:mm:ssZ
13.	Beginning of the date or period to which the information relates	ISO 8601 date in the Coordinated Universal Time (UTC) format YYYY-MM-DD
14.	End of the date or period to which the information relates	ISO 8601 date in the Coordinated Universal Time (UTC) format YYYY-MM-DD
15.	Collection body responsible for the collection of the information	Name of the collection body designated for the collection of the data as published on ESMA’s website pursuant to Article 4 of Regulation (EU) 2023/2859
16.	Home member state, where applicable	ISO 3166 - 2 characters country code
17.	Host member state, where applicable	ISO 3166 - 2 characters country code
18.	Instrument or product identifier, where applicable	ISIN or up to 52 alphanumeric characters
19.	Unique data record identifier	Free text up to 140 alphanumeric characters
20.	Data file reference	Free text up to 500 alphanumeric characters
21.	Qualified electronic seal file reference, where applicable	Free text up to 500 alphanumeric characters
22.	Type of submission	NEWT = New (to be used for new information) MODI = Modify (to be used for modifications in light of newly available information) EROR = Error (to be used in case of errors leading to removal of the entire record) CORR = Correction (to be used when information previously reported is found to be incorrect and should be corrected)
23.	Version of the dataset (data and metadata)	Integer number
24.	Legal framework	Taxonomy in accordance with list of Union Legislative acts under Article 1(1) point (a) of Regulation (EU) 2023/2859

25.
Historical information flag
‘true’ – Yes
‘false’ – No
26. Language in which the information was
submitted
ISO 639-1 – 2 characters language code

5.2 ITSs specifying certain functionalities of ESAP

COMMISSION IMPLEMENTING REGULATION (EU) 2024/XXX of XXXX laying down implementing technical standards with regard to the functionalities of the European single access point pursuant to Regulation (EU) 2023/2859 of the European Parliament and of the Council

(Text with EEA relevance)

THE EUROPEAN COMMISSION,

Having regard to the Treaty on the Functioning of the European Union,

Having regard to Regulation (EU) 2023/2859 of the European Parliament and of the Council of 13 December 2023 on establishing a European single access point providing centralised access to publicly available information of relevance to financial services, capital markets and sustainability, and in particular Article 7 paragraph 4 thereof,

Whereas:

(1) In order to provide the public with an easy centralised access to information about entities and their products that is made public in relation to financial services, capital markets, sustainability and diversity, the European Securities and Markets Authority (ESMA) has been given the task of establishing and operating a European single access point (ESAP) and to ensure that the ESAP provides for the functionalities specified in Article 7 paragraph 1 of Regulation (EU) 2023/2859. To this purpose, Article 7 paragraph 4 of Regulation (EU) 2023/2859 mandates the European Banking Authority, the European Insurance and Occupational Pensions Authority and the European Securities and Markets Authority (European Supervisory Authorities), through the Joint Committee, to specify certain technical features of the system.

(2) ESAP is conceived as a portal providing stakeholders with easy access to information via an API. Therefore, the data publication API should ensure accessibility of the data, support a variety of formats for the information and incorporate any necessary changes or updates requested by ESMA. Any changes to the API should be identified in due time, and a clear timetable should be set out for implementation. Furthermore, the API should guarantee the basic functionalities of ESAP for free, notwithstanding ESMA’s obligation to charge fees for specific services with high maintenance and support cost or that involve searches for and downloads of large volumes of data on the basis of Article 8 paragraph 3 of Regulation (EU) 2023/2859.

(3) In order to ensure certain and efficient identification, entities that submit information and the legal persons to which the information relate should be identified using the ISO 17442 legal entity identifiers (LEI). The LEI should correspond to the entity it is intended to correspond to, comply with the ISO 17442 standard and be included in the Global Legal Entity Identifier database maintained by the Central Operating Unit appointed by the Regulatory Oversight Committee of the Global LEI Foundation.

(4) A classification of the types of information should enable stakeholders to search through the information available on ESAP in an efficient way. Each information which is made available on ESAP should correspond to at least one type of information.

(5) It is important that users are able to easily find sustainability information. For that reason, a specific type of information should be required to identify the management report as referred to in Directive 2004/109/EC since the management report contains the sustainability statement drawn up pursuant to 2013/34/EU.

(6) ESAP should increase opportunities for visibility and growth of small and medium-sized entities (SMEs). For SMEs to be easily identifiable on ESAP, information made available on ESAP should be accompanied by a specific size category. In order to minimise the reporting burden on companies, ESAP should rely on existing size categories defined by the Regulations and Directives pursuant to which the information is submitted.

(7) ESAP should allow for the searchability of information by industry category. Commission Delegated Regulation (EU) 2023/137 amending Regulation (EC) No 1893/2006 of the European Parliament and Council establishing the statistical classification of economic activities, provides the main sectors which are sufficiently granular for the classification of non-financial entities in the scope of ESAP. With respect to financial entities, it is appropriate that additional categories are included to reflect financial sector industry categories which are deemed relevant for ESAP purposes.

(8) This Regulation is based on the draft implementing technical standards submitted to the Commission by the European Securities and Markets Authority, the European Banking Authority and the European Insurance and Occupational Pensions Authority.

(9) The Joint Committee of the European Supervisory Authorities referred to in Article 54 of Regulation (EU) No 1093/2010 of the European Parliament and of the Council7 , in Article 54 of Regulation (EU) No 1094/2010 of the European Parliament and of the Council8 and in Article 54

[7] Regulation (EU) No 1093/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Banking Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/78/EC (OJ L 331, 15.12.2010, p. 12).

[8] Regulation (EU) No 1094/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Insurance and Occupational Pensions Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/79/EC (OJ L 331, 15.12.2010, p. 48).

of Regulation (EU) No 1095/2010 of the European Parliament and of the Council9 has conducted open public consultations on the draft implementing technical standards on which this Regulation is based, analysed the potential related costs and benefits and requested the advice of the Banking Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1093/2010, the Insurance and Reinsurance Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1094/2010, and the Securities and Markets Stakeholder Group established in accordance with Article 37 of Regulation (EU) No 1095/2010.

HAS ADOPTED THIS REGULATION:

Article 1

The data publication API

The data publication API shall:

a. support the distribution of the information at least in the format in which it is received;

b. support at least the functions of search and download;

c. allow users to have unrestricted access to all services that are free of charge;

d. incorporate any changes or update requested by ESMA to ensure compliance with points (a), (b) and (c).

Article 2

The legal entity identifier

Where required for the purpose of ESAP, entities submitting information to collection bodies and the legal person to which the information relates shall be identified with a Legal Entity Identifier that pertains to that entity, that is compliant with the ISO 17442 standard and that is included in the LEI database maintained by the Global LEI Foundation.

Article 3

The classification of the types of information

Information submitted to collection bodies shall be classified according to the applicable types of information set out in Table 1 of Annex to this Regulation.

Article 4

The categories of the size of the entities

Where a metadata indicating size is required for the purpose of ESAP, the information shall:

a) be accompanied by a metadata indicating one of the size categories set out in Table 2 of the Annex to this Regulation when information is submitted to collection bodies pursuant to one of the legally binding Union acts included therein;

[9] Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC (OJ L 331, 15.12.2010, p. 84).

b) be accompanied by a metadata indicating the size category “other size” when information is submitted to collection bodies pursuant to legally binding Union acts other than those included in Table 2 of the Annex to this Regulation.

Article 5

The characterization of industry sectors

Where a metadata indicating the industry sector of the economic activities is required for the purpose of ESAP:

a) entities falling under one or more categories listed in Table 3 of the Annex to this Regulation shall be classified according to that table;

b) other entities shall be categorised on the basis of one or more of the main sections of Statistical Classification of economics activities in the European Community (NACE), as defined in Commission Delegated Regulation (EU) 2023/137.

Article 6

Entry into force and application

1. This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.

2. This Regulation shall apply from 10 July 2026.

This Regulation shall be binding in its entirety and directly applicable.

Done at Brussels, xx xx xxxx

For the Commission
The President

Annex

Table 1: Types of information

Directive or Regulation	Type of information	Description	Article
Directive 2004/109/EC	Annual financial report	Annual financial report	Article 4
Directive 2004/109/EC	Management report, including sustainability statement	Management report, disclosed by issuers whose securities are admitted to trading on a regulated market	Article 4(2)(b) Article 4(5)
Directive 2004/109/EC	Half year financial report	Half year financial report	Article 5

Directive or Regulation	Type of information	Description	Article

Directive 2004/109/EC	Payments to governments	Report on Payments to governments	Article 6
Directive 2004/109/EC	Inside information	Inside information disclosed by issuers whose securities are admitted to trading on a regulated market	Article 21 Article 2(1)(k)
Directive 2004/109/EC	Managers’ transaction	Transaction conducted by persons discharging managerial responsibility	Article 21 Article 2(1)(k)
Directive 2004/109/EC	Major shareholdings notification	Notification of acquisition or disposal of major holdings	Article 12
Directive 2004/109/EC	Acquisition or disposal of an issuer’s own shares	Acquisition or disposal of an issuer’s own shares	Article 14
Directive 2004/109/EC	Total number of voting rights and capital	Total number of voting rights and capital	Article 15
Directive 2004/109/EC	Changes in the rights attaching to shares or securities other than shares	Changes in the rights attaching to shares or securities other than shares	Article 16
Directive 2004/109/EC	Home Member State	Home Member State	Article 2(1)(i)
Directive 2004/109/EC	Additional regulated information required to be disclosed under the laws of a Member State	Additional regulated information required to be disclosed under the laws of a Member State	Article 3(1)
Directive 2004/109/EC	Administrative sanctions and measures	Information on administrative sanction and measure including appeal	Article 29(1)
Regulation (EU) 2017/1129	Prospectus exemption document (takeover)	Prospectus exemption document for securities offered in connection with a takeover by means of an exchange offer in the context of an offer of securities to the public or of	Article 1(4)(f) Article 1(5) first subparagraph point (e)

Directive or
Regulation Type of information
Description
Article
an admission to trading on a regulated market
Regulation (EU)
2017/1129
Prospectus exemption document (merger or division) Prospectus exemption document for securities offered, allotted or to be allotted in connection with a merger or division in the context of an offer of securities to the public or of an admission to trading on a regulated market
Article 1(5) first
subparagraph point (f)
Article 1(4)(g)
Regulation (EU)
2017/1129
Final terms, including the summary of the individual issue annexed to them Final terms
Article 8(5)
Regulation (EU)
2017/1129
Universal Registration
Document
Universal Registration
Document Article 9(4)
Regulation (EU)
2017/1129 Amendment Amendment to Universal
Registration Document Article 9(4)
Regulation (EU)
2017/1129 Registration Document Registration Document Article 10(2) Regulation (EU) 2017/1129 Securities Note Securities Note
Article 21(1)
Article 21(9)
Article 6(3)
Regulation (EU)
2017/1129
Final offer price and amount of securities
Final offer price and amount of securities Article 17(2) Regulation (EU) 2017/1129 Standalone Prospectus Prospectus (single document), including information incorporated by reference
Article 21(1)
Article 21(9)
Regulation (EU)
2017/1129 Supplement Prospectus supplements, including translations Article 23(1) Regulation (EU) 2017/1129 Base prospectus with Final terms Base prospectus with Final terms
Article 8
Article 21(1)

Directive or
Regulation Type of information
Description
Article
Regulation (EU)
2017/1129
Base prospectus without
Final terms
Base prospectus without
Final terms
Article 8
Article 21(1)
Regulation (EU)
2017/1129
Translation of Appendix
Translation of Appendix to the Universal Registration Document
Article 26(4)
Regulation (EU)
2017/1129
Summary
Summary
Article 21(1)
Article 21(9)
Article 6(3)
Article 7
Regulation (EU)
2017/1129
Translation of the Summary
Translation of the Summary
Article 21(1)
Article 21(9)
Article 6(3)
Article 7
Regulation (EU)
2017/1129 Administrative sanction and measure
Administrative sanctions and other administrative measures
Article 42(1)
Directive 2004/25/EC Authority competent to supervise the bid Authority competent to supervise the bid Article 4(2)(c) Directive 2004/25/EC Takeover bid decision Takeover bid decision
Article 6(1)
Directive 2004/25/EC
Takeover bid offer document Takeover bid offer document Article 6(2) Directive 2004/25/EC Offeree company board opinion and reasons on takeover bid Offeree company board opinion and reasons on takeover bid
Article 9(5)
Directive 2004/25/EC
Equitable price
Equitable price
Article 5(4)
Directive 2007/36/EC Comply or explain disclosure of engagement policy Explanation of non- compliance Article 3g(1) Directive 2007/36/EC Engagement policy Engagement policy
Article 3g(1)(a)

Directive or
Regulation Type of information
Description
Article
Directive 2007/36/EC Implementation of engagement policy Implementation of engagement policy Article 3g(1)(b) Directive 2007/36/EC Consistency of investment strategy with liability structure Consistency of equity investment strategy with profile and duration of liabilities and contribution to the medium to long-term performance of assets
Article 3h(1)
Directive 2007/36/EC Arrangement with asset manager Arrangement with asset manager
Article 3h(2)
Directive 2007/36/EC
Code of conduct
Code of conduct
Article 3(j)(1)
Directive 2007/36/EC
Explanation of non- application of code of conduct Explanation of non- application of code of conduct
Article 3j(1)
Directive 2007/36/EC
Information in relation to the preparation of research, advice and voting recommendations Information in relation to the preparation of research, advice and voting recommendations
Article 3j(2)
Directive 2007/36/EC
Remuneration policy
Remuneration policy
Article 9a(7)
Directive 2007/36/EC Date and result of the vote on remuneration policy Date and result of the vote on remuneration policy Article 9a(7) Directive 2007/36/EC Remuneration report Remuneration report
Article 9b(5)
Directive 2007/36/EC Material transactions with related parties Material transactions with related parties Article 9c(2) Directive 2007/36/EC Material transactions of related parties with company’s subsidiaries Material transactions of related parties with company’s subsidiaries
Article 9c(7)
Directive 2007/36/EC
Voting results
Voting results
Article 14(2)
Directive 2013/34/EU
Annual financial statements
Annual financial statements
Article 30
Directive 2013/34/EU
Management report
Management report
Article 30

Directive or Regulation	Type of information	Description	Article
Directive 2013/34/EU	Sustainability statement	Sustainability statement	Article 19a, Article 29a, Article 30
Directive 2013/34/EU	Sustainability report	Third-country undertakings’ sustainability report	Article 40a
Directive 2013/34/EU	Consolidated management report	Consolidated management report	Article 30
Directive 2013/34/EU	Consolidated financial statements	Consolidated financial statements	Article 30
Directive 2013/34/EU	Audit report	Audit report	Article 30
Directive 2013/34/EU	Assurance opinion	Assurance opinion	Article 30
Directive 2013/34/EU	Assurance opinion on sustainability report	Assurance opinion on sustainability report	Article 40d
Directive 2013/34/EU	Statement indicating that the third-country undertaking did not make information available	Statement indicating that the third-country undertaking did not make information available	Article 40a(2) fourth subparagraph
Directive 2013/34/EU	Statement indicating that the third-country undertaking did not make the necessary assurance opinion available	Statement indicating that the third-country undertaking did not make the necessary assurance opinion available	Article 40a(3)
Directive 2013/34/EU	Report on payments to governments	Report on payments to governments	Article 45
Directive 2013/34/EU	Consolidated report on payments to governments	Consolidated report on payments to governments	Article 45
Regulation (EU) No 236/2012	Net short position	Net short position	Article 6(1)
Regulation (EU) No 596/2014	Inside information	Inside information	Article 17(1)

Directive or Regulation	Type of information	Description	Article
Regulation (EU) No 596/2014	Inside information concerning emission allowances	Inside information concerning emission allowances	Article 17(2)
Regulation (EU) No 596/2014	Managers’ transaction - issuers	Transaction conducted by persons discharging managerial responsibility in respect of issuers	Article 19(3)
Regulation (EU) No 596/2014	Managers’ transaction - emission allowances	Transaction conducted by persons discharging managerial responsibility in respect of emission allowances market participants	Article 19(3)
Regulation (EU) No 596/2014	Administrative sanction and measure	Administrative sanctions or other administrative measures	Article 34(1)
Regulation (EU) 2019/2088	Sustainability risk policies in investment decision	Policies on the integration of sustainability risks in investment decision-making process	Article 3(1)
Regulation (EU) 2019/2088	Sustainability risk policies in investment or insurance advice	Policies on the integration of sustainability risks in investment advice or insurance advice	Article 3(2)
Regulation (EU) 2019/2088	Adverse sustainability impact at entity level	Statement on due diligence policies with respect to the principal adverse sustainability impacts of investment decisions on sustainability factors at financial market participant level	Article 4(1)
Regulation (EU) 2019/2088	Adverse sustainability impact at large entity level	Statement on due diligence policies with respect to the principal adverse impacts of investment decisions on sustainability factors for	Article 4(3)
		large financial market participants
Regulation (EU) 2019/2088	Adverse sustainability impact at group level	Statement on due diligence policies with respect to the principal adverse impacts of investment decisions on sustainability factors for parent undertakings of large groups	Article 4(4)
Regulation (EU) 2019/2088	Adverse sustainability impact at financial adviser level	Information as to whether financial advisers consider in their investment advice or insurance advice the principal adverse impacts of investment decisions on sustainability factors	Article 4(5)(a)
Regulation (EU) 2019/2088	Adverse sustainability impacts at financial adviser level	Information as to why financial advisers do not to consider adverse impacts of investment decisions on sustainability factors in their investment advice or insurance advice	Article 4(5)(b)
Regulation (EU) 2019/2088	Sustainability risk integration in remuneration policies	Sustainability risk integration in remuneration policies	Article 5(1)
Regulation (EU) 2019/2088	Sustainability-related product disclosures	Description of the environmental or social characteristics or the sustainable investment objective	Article 10(1)(a)
Regulation (EU) 2019/2088	Information on the methodologies used	Information on the methodologies used to assess, measure and monitor the environmental or social characteristics or the impact of the sustainable investment	Article 10(1)(b)

Directive or
Regulation Type of information Description Article Regulation (EU) 2019/2088 Sustainability-related product disclosures (pre‐ contractual disclosures) Sustainability-related product disclosures under Articles 8 and 9
Article 10(1)(c)
Regulation (EU)
2019/2088
Sustainability-related product disclosures (periodic reports) Sustainability-related product disclosures under
Article 11
Article10(1)(d)
Directive 2014/65/EU SME Admission document SME Admission document Article 33(3)(c) Directive 2014/65/EU SME Prospectus SME Prospectus Article 33(3)(c) Directive 2014/65/EU SME Ongoing periodic financial reporting Ongoing periodic financial reporting, including SME audited annual report
Article 33(3)(d)
Directive 2014/65/EU SME Regulatory information concerning the issuers SME Regulatory information concerning the issuers Article 33(3)(f) Directive 2014/65/EU Ownership information Ownership information Article 46(2)(a) Directive 2014/65/EU Transfer of ownership Transfer of ownership Article 46(2)(b) Directive 2014/65/EU Authorised investment firm in the EU Authorised investment firm in the EU Article 5(3) Directive 2014/65/EU Authorisation to an investment firm or market operator as a Multilateral trading facility (MTF) Authorisation to an investment firm or market operator as a Multilateral trading facility (MTF)
Article 18(10),
fourth sentence
Directive 2014/65/EU Authorisation to an investment firm or market operator as an Organised Trading Facility (OTF) Authorisation to an investment firm or market operator as an Organised Trading Facility (OTF)
Article 18(10),
fourth sentence
Directive 2014/65/EU Tied agents Tied agents Article 29(3) Directive 2014/65/EU Decision on the suspension or removal of the financial instrument and of any related derivative Decision on the suspension or removal of the financial instrument and of any related derivative
Article 32(2) first
subparagraph and 52(2)

Directive or Regulation	Type of information	Description	Article
Directive 2014/65/EU	Competent authority decision on a suspension or removal	Competent authority decision on a suspension or removal of the financial instrument and of any related derivative traded on a regulated market, MTF, OTF and systematic internaliser, including an explanation if the decision was not to suspend or remove	Article 52(2) third subparagraph
Directive 2014/65/EU	Administrative sanction and measure	Administrative sanction or measure	Article 71 (1)
Directive 2014/65/EU	Appeal to an administrative sanction and measure	Appeal to an administrative sanction or measure, including the outcome of the appeal	Article 71 (2)
Directive 2014/65/EU	Annulation of a decision	Annulation of a decision	Article 71 (2)
Directive 2014/65/EU	Commodity derivatives and emission allowance derivatives positions	Weekly report with aggregate positions in commodity derivatives and in derivatives on emission allowances	Article 58(1)(a)
Directive 2014/65/EU	Issuer’s sponsored research	Issuer’s sponsored research produced in compliance with the EU code of conduct for issuer-sponsored research	Article 24(3b)
Regulation (EU) 2015/2365	Registered trade repository	Registered trade repository	Article 8(3)
Regulation (EU) 2015/2365	Recognised trade repository	Recognised trade repository	Article 19(8)
Regulation (EU) 2015/2365	Open positions in SFTs	Aggregate positions by type of securities financing transactions	Article 12(1)

Directive or
Regulation Type of information
Description
Article
Regulation (EU)
2015/2365 Public statement on an infringement
Public statement on person responsible and the nature of infringement
Article 22(4)(b)
Regulation (EU)
2015/2365
Administrative sanction and measure
Annual report on aggregated information and granular information regarding administrative sanctions and other administrative measure
Article 25(1)
second sentence
Regulation (EU)
2015/2365 Criminal sanction Annual Report on imposed criminal sanctions data
Article 25(2),
second sentence
Regulation (EU)
2015/2365
Administrative sanction and measure
Disclosed administrative sanctions, other administrative measures, or criminal sanctions
Article 25(3)
Regulation (EU)
2015/2365
Administrative sanction and measure
Decision imposing an administrative sanction or other administrative measure in relation to infringements of Article 4 or 15.
Article 26(1)
Regulation (EU)
2015/2365 Appeal to an administrative sanction Appeal to an administrative sanction and outcome of the appeal
Article 26(4)
Regulation (EU)
2015/2365 Annulation of a decision
Annulation of a decision
Article 26(4)
Directive 2002/87/EC
Legal structure and governance and organisational structure Legal structure and governance and organisational structure
Article 9(4)
Directive 2006/43/EC
Statutory auditor
Statutory auditor
Article 15
Directive 2006/43/EC
Audit firm
Audit firm
Article 15
Directive 2006/43/EC Administrative sanction and measure Administrative sanction and measure
Article 30c

Directive or
Regulation Type of information
Description
Article
Directive 2006/43/EC Appeal to an administrative sanction and measure The status and outcome of an appeal to an administrative sanction and measure
Article 30c
Directive 2009/65/EC
Prospectus
Prospectus
Article 68(1)
Directive 2009/65/EC
Annual financial report
Annual financial report
Article 68(1)
Directive 2009/65/EC
Half-yearly financial report
Half-yearly financial report
Article 68(1)
Directive 2009/65/EC Authorisation of management company Authorisation of management company
Article 6(1)
second subparagraph
Directive 2009/65/EC Key investor information document Key investor information document (where not replaced by key information document pursuant to Regulation (EU) No 1286/2014)
Article 78(1)
Directive 2009/65/EC Administrative sanction and measure Administrative sanction or measure against which there is no appeal
Article 99b(1)
Directive 2009/138/EC Solvency and financial condition report Solvency and financial condition report Article 51(1) Directive 2009/138/EC Solvency and financial condition report - group level Solvency and financial condition report - group level
Article 256(1)
Directive 2009/138/EC
Authorisation or withdrawal of authorisation of an insurance or reinsurance undertaking Authorisation or withdrawal of authorisation of an insurance or reinsurance undertaking
Article 25a
Directive 2009/138/EC Reorganisation decision Decision on a reorganisation measure
Article 271(1)
Directive 2009/138/EC Decision to open winding-up proceedings Decision to open winding-up proceedings Article 280(1)

Directive or Regulation	Type of information	Description	Article
Directive 2011/61/EU	Authorised AIFM	Authorised Alternative Investment Fund Manager, including Competent Authority of Alternative Investment Fund Manager	Article 7(5) second subparagraph
Directive 2011/61/EU	Authorised AIF	Alternative Investment Fund managed and/or marketed in the Union	Article 7(5) second subparagraph
Directive 2013/36/EU	Administrative sanction and measure	Administrative penalty	Article 68(1)
Directive 2013/36/EU	Appeal to an administrative sanction and measure	Appeal to an administrative penalty, including the status and outcome of the appeal	Article 68(1)
Directive 2013/36/EU	Administrative sanction and measure	Administrative penalty on anonymous basis	Article 68(2)
Directive 2013/36/EU	Systematically Important Institutions	Notification of Systematically Important Institutions	Article 131(12)
Directive 2014/59/EU	Group financial support agreement	Group financial support agreement	Article 26(1)
Directive 2014/59/EU	Temporary administrator	Temporary administrator	Article 29(1)
Directive 2014/59/EU	Notification of the suspension of payments or delivery obligations	Notification of the suspension of payments or delivery obligations	Article 33a(8)
Directive 2014/59/EU	Special manager	Special manager	Article 35(1)
Directive 2014/59/EU	Own funds	Own funds	Article 45i(3)
Directive 2014/59/EU	Resolution action	Resolution action	Article 83(4)
Directive 2014/59/EU	Public statement on an infringement	Public statement on an infringement	Article 112(1) Article 111(2)(a)
Directive 2014/59/EU	Administrative sanction and measure	Administrative penalty not subject to appeal or where	Article 112(1)
		the right to appeal has been exhausted
Directive 2014/59/EU	Appeal to an administrative sanction and measure	Appeal to an administrative penalty, including the status and outcome of the appeal	Article 112(1)
Directive 2016/97/EU	Administrative sanction and measure	Administrative sanction and other measure against which no appeal was lodged	Article 32(1)
Directive 2016/97/EU	Appeal to an administrative sanction and measure	Appeal to an administrative sanction and other measure, including the outcome of the appeal	Article 32(2)
Directive 2016/97/EU	Annulation of a decision	Annulation of a decision to impose sanctions or other measures	Article 32(2)
Directive 2016/2341/EU	Remuneration policy	Remuneration policy	Article 23(2)
Directive 2016/2341/EU	Annual accounts	Annual accounts	Article 29
Directive 2016/2341/EU	Annual reports	Annual reports	Article 29
Directive 2016/2341/EU	Investment policy principles	Statement of investment policy principles	Article 30
Directive 2016/2341/EU	Administrative sanction and measure	Administrative sanction or other measure against which no appeal was lodged	Article 48(4)
Directive 2019/2034/EU	Legal structure and governance and organisational structure	Legal structure and governance and organisational structure	Article 44
Directive 2019/2034/EU	Administrative sanction and measure	Administrative sanction and measure against which no appeal was lodged or where the right to appeal has been exhausted	Article 20

Directive or Regulation	Type of information	Description	Article
Directive 2019/2034/EU	Appeal to an administrative sanction and measure	Appeal to an administrative sanction and measure, including the status and outcome of the appeal	Article 20
Directive 2019/2162/EU	Covered bonds programme information	Covered bonds programme information	Article 14
Directive 2019/2162/EU	Administrative sanction and measure	Administrative penalty and other administrative measure	Article 24
Directive 2019/2162/EU	Criminal sanction	Criminal Penalty	Article 24
Directive 2019/2162/EU	Appeal to an administrative sanction and measure	Appeal to an administrative penalty and other administrative measure, including the status and outcome of the appeal	Article 24
Directive 2019/2162/EU	Annulation of a decision	Annulation of a decision to impose administrative penalty or other administrative measure, including any final court ruling.	Article 24
Directive 2019/2162/EU	Credit institutions permitted to issue covered bonds	Credit institutions permitted to issue covered bonds	Article 26(1)(b)
Directive 2019/2162/EU	European covered bonds	European covered bonds	Article 26(1)(c)
Regulation (EC) No 1060/2009	Rating methodologies, models and key rating assumptions	Rating methodologies, models and key rating assumptions	Article 8(1)
Regulation (EC) No 1060/2009	Credit ratings and ratings outlook	Credit ratings and ratings outlook	Article 10(1) Article 11a(1) Article 11a(2)

Directive or Regulation	Type of information	Description	Article
Regulation (EC) No 1060/2009	Central Repository	Central Repository	Article 11a(2)
Regulation (EC) No 1060/2009	Changes to rating methodologies, models and key rating assumptions	Information to be disclosed when rating methodologies, models or key rating assumptions used in credit rating activities are changed	Article 8(6)
Regulation (EC) No 1060/2009	Errors in rating methodologies and affected rated entities	Errors in rating methodologies and affected rated entities	Article 8(7)
Regulation (EC) No 1060/2009	Sovereign rating	Sovereign rating	Article 8a(1)
Regulation (EC) No 1060/2009	Sovereign ratings calendar	Sovereign ratings calendar	Article 8a(3)
Regulation (EC) No 1060/2009	Decisions to discontinue a credit rating	Decisions to discontinue a credit rating	Article 10(1)
Regulation (EC) No 1060/2009	Policies and procedures on unsolicited credit ratings	Policies and procedures on unsolicited credit ratings	Article 10(4)
Regulation (EC) No 1060/2009	CRA disclosures	CRA disclosures	Article 11(1)
Regulation (EC) No 1060/2009	Annual transparency report	Annual transparency report	Article 12
Regulation (EC) No 1060/2009	Third country CRA certification decision	Third country CRA certification decision	Article 5(3)
Regulation (EC) No 1060/2009	Registered CRA	Registered CRA	Article 8d(2) Article 18(3)
Regulation (EC) No 1060/2009	CRAs market share and types of credit ratings issued	CRAs market share and types of credit ratings issued	Article 8d(2)
Regulation (EC) No 1060/2009	Historical performance data	Historical performance data	Article 11(2)

Directive or Regulation	Type of information	Description	Article
Regulation (EC) No 1060/2009	Summary information on the main developments	Summary information on the main developments	Article 11(2)
Regulation (EC) No 1060/2009	Administrative sanction and measure	Administrative sanction and measure	Article 24(5) Article 36d(1)
Regulation (EC) No 1060/2009	Periodic penalty payment	Periodic penalty payment	Article 36d(1)
Regulation (EU) No 345/2013	European venture capital funds	European venture capital funds, including countries in which they are marketed	Article 17(1)
Regulation (EU) No 345/2013	European venture capital fund managers	European venture capital fund managers	Article 17(1)
Regulation (EU) No 346/2013	European social entrepreneurship funds	European social entrepreneurship funds, including countries in which they are marketed	Article 18(1)
Regulation (EU) No 346/2013	European social entrepreneurship fund managers	European social entrepreneurship fund managers	Article 18(1)
Regulation (EU) No 575/2013	Prudential requirements disclosures	Prudential requirements disclosures	part Eight
Regulation (EU) No 537/2014	Annual transparency reports	Annual transparency reports	Article 13
Regulation (EU) No 600/2014	Class of financial instrument	Class of financial instrument	Article 14(6)
Regulation (EU) No 600/2014	EU systematic internaliser	EU systematic internaliser	Article 15(1) second subparagraph
Regulation (EU) No 600/2014	Financial instrument reference data	Financial instrument reference data	Article 27(1)
Regulation (EU) No 600/2014	Classes of derivatives subject to the trading obligation	Classes of derivatives subject to the trading obligation	Article 34

Directive or Regulation	Type of information	Description	Article
Regulation (EU) No 600/2014	Trading venues	Venues where derivatives subject to trading obligation are admitted to trading or traded, including dates of effect of trading obligation	Article 34
Regulation (EU) No 600/2014	ESMA’s temporary intervention	Notice of decisions for ESMA’s temporary intervention	Article 40(5)
Regulation (EU) No 600/2014	Competent authorities product intervention	Notice of decisions for competent authorities product intervention	Article 42(5)
Regulation (EU) No 600/2014	Summary of national position management measures and position limits	Summary of national measures for the reduction of position or exposure limits and limits from entering into a commodity derivative	Article 44(2)
Regulation (EU) No 600/2014	Limits from entering into a commodity derivative	Limits from entering into a commodity derivative	Article 45(6)
Regulation (EU) No 600/2014	Third-country firms	Register of third-country firms providing investment service or performing investment activities in the Union	Article 48
Regulation (EU) No 1286/2014	Key information document	Key information document	Article 5(1)
Regulation (EU) No 1286/2014	Administrative sanction and measure	Administrative sanction and measure	Article 27(1), Article 29(1)
Regulation (EU) No 1286/2014	Administrative sanction and measure	Decision imposing an administrative sanction and measure against which there is no appeal for infringements referred to in Article 24(1)	Article 29(1)

Directive or Regulation	Type of information	Description	Article
Regulation (EU) 2015/760	European long-term investment fund	European long-term investment fund including identification data	Article 3(3) second subparagraph
Regulation (EU) 2016/1011	Conflict of interest disclosures	Conflict of interest disclosures	Article 4(5)
Regulation (EU) 2016/1011	Guidelines on input data	Guidelines regarding the types of input data, the priority of use of the different types of input data and the exercise of expert judgement, to ensure compliance with point (a) and the methodology	Article 11(1)(c)
Regulation (EU) 2016/1011	Arrangements for limited quantity or quality of input data	Arrangements identifying circumstances in which the quantity or quality of input data falls below the standards necessary and describing whether and how the benchmark is to be calculated.	Article 12(3)
Regulation (EU) 2016/1011	Information on benchmark methodology	Information on benchmark methodology	Article 13(1)
Regulation (EU) 2016/1011	Compliance statement	Compliance statement of significant benchmark administrator	Article 25(7)
Regulation (EU) 2016/1011	Compliance statement	Compliance statement of non-significant benchmark administrator	Article 26(3)
Regulation (EU) 2016/1011	Benchmark statement	Benchmark statement	Article 27(1)
Regulation (EU) 2016/1011	Actions in case of change or cessation of benchmark	Procedure concerning actions in case of change or cessation of benchmark	Article 28(1)

Directive or Regulation	Type of information	Description	Article
Regulation (EU) 2016/1011	Administrative sanction and measure	Administrative sanction and measure	Article 45(1)
Regulation (EU) 2016/1011	Benchmark administrator	Register of administrators and benchmarks	Article 36
Regulation (EU) 2017/1131	Money Market Fund	Money Market Fund, including its type in accordance with Article 3(1), whether it is a short-term or standard MMF, the manager of an MMF and the competent authority of the MMF	Article 4(7)
Regulation (EU) 2019/1238	Key information document	Key information document	Article 26(1)
Regulation (EU) 2019/1238	Competent authority product intervention decision	Notice of competent authority product intervention decision	Article 63(4)
Regulation (EU) 2019/1238	EIOPA product intervention decision	EIOPA product intervention decision	Article 65(6)
Regulation (EU) 2019/1238	Administrative sanction and measure	Administrative sanction and measure	Article 69(1)
Regulation (EU) 2019/1238	Appeal to an administrative sanction and measure	Appeal to an administrative sanction, including outcome of the appeal	Article 69(4)
Regulation (EU) 2019/1238	Annulation of a decision	Judicial annulation of administrative sanction and measure	Article 69(4)
Regulation (EU) 2019/2033	Investment firm risk management objectives and policies	Investment firm risk management objectives and policies	Part Six
Regulation (EU) 2019/2033	Investment firm governance	Investment firm governance	Part Six
Regulation (EU) 2019/2033	Investment firm own funds	Investment firm own funds	Part Six
Regulation (EU) 2019/2033	Compliance with investment firm own funds requirements	Compliance with investment firm own funds requirements	Part Six
Regulation (EU) 2019/2033	Investment firm remuneration policy and practices	Investment firm remuneration policy and practices	Part Six
Regulation (EU) 2019/2033	Investment firm investment policy	Investment firm investment policy	Part Six
Regulation (EU) 2019/2033	Investment firm environment, social and governance risks	Investment firm environment, social and governance risks	Part Six
Regulation (EU) 2023/1114	Inside information	Inside information	Article 88(1)
Regulation (EU) 2023/1114	Crypto-asset white paper for crypto-assets other than EMT or ART	Crypto-asset white paper for crypto-assets other than asset-referenced tokens and e-money tokens including any modified version and out-of-date version	Article 109(2)
Regulation (EU) 2023/1114	Information about issuer of ART	Information about issuer of Asset-referenced tokens	Article 109(3) points (a)-(b), (d) -(g)
Regulation (EU) 2023/1114	Crypto-asset white paper for ART	Crypto-asset white papers for Asset-referenced tokens including any modified version and out-of-date version	Article 109(3) point (c)
Regulation (EU) 2023/1114	Information about issuer of EMT	Information about issuer of E-money tokens	Article 109(4) points (a)-(b), (d) -(f)
Regulation (EU) 2023/1114	Crypto-asset white paper for EMT	Crypto-asset white papers for E-money tokens including	Article 109(4) point (c)
		any modified version and out-of-date version
Regulation (EU) 2023/1114	Information about crypto-asset service provider	Information about crypto-asset service provider	Article 109(5)
Regulation (EU) 2023/1114	Measure notified in accordance with Article 109 paragraph 6 of the MiCA Regulation	Measure notified in accordance with Article 109 paragraph 6 of the MiCA Regulation	Article 109(6)
Regulation (EU) 2023/1114	Non-compliant entity providing crypto-asset services	Non-compliant entities providing crypto-asset services, including the commercial name or the website of a non-compliant entity, the name of the competent authority that submitted the information and the changes of circumstances or any information brought to ESMA’s attention concerning registered non-compliant entity if applicable	Article 110(1), (2)
Regulation (EU) 2023/1114	Infringement of MiCA	Infringement identified on ESMA’s own initiative	Article 110(4)
Regulation (EU) 2023/1114	Unauthorised or unregistered third country CASP	Information on entities providing crypto-asset services without the necessary authorisation or registration submitted by the supervisory authorities of third countries	Article 110(4)
Regulation (EU) 2023/2631	Factsheet	Factsheet	Article 15(1)(a)
Regulation (EU) 2023/2631	Pre-issuance review	Pre-issuance review	Article 15(1)(b)
Regulation (EU) 2023/2631	Allocations report	Annual allocations reports

Directive or Regulation	Type of information	Description	Article
			Article 15(1)(d)
Regulation (EU) 2023/2631	Post-issuance review	Post-issuance review	Article 15(1)(e)
Regulation (EU) 2023/2631	Impact report	Impact report	Article 15(1)(f)
Regulation (EU) 2023/2631	Optional impact report review	Optional impact report review	Article 15(1)(h)
Regulation (EU) 2023/2631	Pre-issuance disclosures for SLBs	Pre-issuance disclosures for issuers of bonds marketed as environmentally sustainable or sustainability-linked bonds	Article 20
Regulation (EU) 2023/2631	Periodic post-issuance disclosures for SLBs	Periodic post-issuance disclosures for issuers of bonds marketed as environmentally sustainable or sustainability-linked bonds	Article 21
Regulation (EU) 2023/2859	Other	Other types of information made public pursuant to any further legally binding Union acts that provide for centralised electronic access to information on ESAP	Article 1 paragraph 1(a)

Table 2: Categories of size

Directive or Regulation	Criteria	Category by size
Regulation (EU) 2017/1129	Article 2(f)	“SME” if meeting the criteria “Large” if not meeting the criteria

Regulation (EU) 2019/2033	Article 12(1)	"Small and non-interconnected" if meeting the criteria "Large" if exceeding the criteria
Directive 2004/109/EC	Article 3(1) of Directive 2013/34/EU	"Micro undertaking"
	Article 3(2) of Directive 2013/34/EU	"Small undertaking"
	Article 3(3) of Directive 2013/34/EU	"Medium undertaking"
	Article 3(4) of Directive 2013/34/EU	"Large undertaking"
	Article 3(5) of Directive 2013/34/EU	"Small group"
	Article 3(6) of Directive 2013/34/EU	"Medium groups"
	Article 3(7) of Directive 2013/34/EU	"Large group"
Directive 2013/34/EU	Article 3(1)	"Micro undertaking"
	Article 3(2)	"Small undertaking"
	Article 3(3)	"Medium undertaking"
	Article 3(4)	"Large undertaking"
	Article 3(5)	"Small group"
	Article 3(6)	"Medium groups"
	Article 3(7)	"Large group"
Regulation (EU) 575/2013	Article 4(1)	"Small and non-complex institution" if meeting the criteria of point (145)
		"Large institution" if meeting the criteria of point (146)

“Large subsidiary” if meeting the criteria of point (147) Directive 2014/65/EU
Article 4(13)
“SME” if meeting the criteria
“Large” if exceeding the criteria
Directive 2014/59/EU
Article 2(107)
“Micro, small and medium- sized” if meeting the criteria referred to in Article 2(1) of the Annex to Commission Recommendation 2003/361/EC
Article 2(107)
“Large” if exceeding the criteria referred to in Article 2(1) of the Annex to Commission Recommendation 2003/361/EC Directive 2016/2341/EU
Article 5
“Small” if meeting the criteria
“Large” if exceeding the criteria

Table 3 Categorisation of certain entities

Entities	Category
Administrator of benchmarks as defined in Regulation (EU) 2016/1011	Administrator of benchmarks
Central counterparty and other type of counterparties as defined in Regulation (EU) No 648/2012	CCP
Central securities depository as defined in Regulation (EU) No 909/2014	CSD
Credit rating agency as defined in Regulation (EC) No 1060/2009	CRA
Credit institution authorised in accordance with Directive 2013/36/EU of the European Parliament and of the Council	Credit institution
Investment firm authorised in accordance with Directive 2014/65/EU of the European Parliament and of the Council	Investment firm
Insurance undertaking authorised in accordance with Directive 2009/138/EC	Insurance undertaking
Alternative Investment Fund Managers (AIFMs) authorised or registered in accordance with Directive 2011/61/EU of the European Parliament and of the Council	AIFM
Management company as defined in Directive 2009/65/EC	Management company
Institution for occupational retirement provision as defined in Directive (EU) 2016/2341 of the European Parliament and of the Council	Institution for occupational retirement
Payment institutions as defined in Directive (EU)2015/2366	Payment institutions
Reinsurance undertaking authorised in accordance with Directive 2009/138/EC	Reinsurance
Undertakings for the Collective Investment in Transferable Securities (UCITS) authorised in accordance with Directive 2009/65/EC of the European Parliament and of the Council	UCITS
ESG rating providers as defined in Regulation (EU)xx/xxx on the transparency and integrity of Environmental, Social and Governance (ESG) rating activities, and amending Regulation (EU) 2019/2088	ESG rating providers
Other financial market operators such as securities exchanges, commodity exchanges, financial technology and infrastructure	Other financial market operators

6. Impact assessment

6.1
Impact assessment

208. According to the ESA Regulations, the ESAs shall conduct an analysis of costs and benefits when drafting ITSs. The analysis of costs and benefits is undertaken according to an Impact Assessments methodology assessing pros and cons of various options. This section contains an assessment of impact of the proposals in the draft ITSs presented in this Report.

6.1.1 ITSs specifying certain tasks of collection bodies

Problem definition

209. The major challenge in the context of ESAP lies in ensuring that the information provided to ESMA is as harmonized as possible while minimizing the burden on entities and on the CBs themselves. In the context of this ITS, the areas which were deemed most relevant to assess in terms of cost and benefits were the approach to technical automated validations, the open standard license, the API for data collection and the time limits.

Policy options

Policy Issue 1: Specify how the validations shall be performed for each type of information

Option 1.1: Specify general principles on the basis of which CBs should perform their validations

Under this option, the ITS set out how the validations shall be performed on a principle basis and does not specify how technically they shall be applied for each type of information. Under this option, the ESAs will provide guidelines in Level 3 documentations regarding the relevant validations per each type of information in scope.

Option 1.2: Specify how the validations shall be performed in detail for each type of information

This option requires the ITS to explicitly list all validation checks that need be performed for each type of information under ESAP.

Policy Issue 1 – Option 1.1: Specify general principles on the basis of which CBs should perform their validations (preferred option)

Pros	Cons
The JC would meet its legal mandate by specifying how the technical automated validations should be performed.	There would not be full certainty regarding the validations that will be performed by the CBs until the ESAs do not provide L3 guidance to CBs.

By establishing principles for how validation checks should be conducted, rather than explicitly specifying in the ITSs the technical manner in which checks need to be performed for each type of information, this approach would allow for more flexibility to develop those checks and adjust them as implementation progresses, since L3 guidance is a more flexible tool than L2. At the same time, this approach would ensure a certain level of coordination is maintained.

This approach would be fully future-proof since in case of any change in the technical checks needed in the future, the ITS would not need to be amended.

Policy Issue 1 – Option 1.2: Specify how the validations shall be performed in detail for each type of information separately

Pros	Cons
This approach would maximise the transparency and certainty regarding the validations that will be performed by the CBs and would lead to the highest level of harmonization at EU level.	By adopting a detailed approach, there would be a risk of reducing the flexibility in the technical checks that could be performed. The ITS could easily be outdated very quickly and an amendment to the ITS would be necessary whenever a new technical change is necessary. For example, whenever new requirements with regards to the machine-readable format, metadata or QES are established with regards to any of the types of information, an amendment of the ITSs would be necessary to ensuring validation of those new requirements. This approach would therefore be more costly and excessively inflexible.

Pros

Cons

This approach would maximise the transparency and certainty regarding the validations that will be performed by the CBs and would lead to the highest level of harmonization at EU level.

By adopting a detailed approach, there would be a risk of reducing the flexibility in the technical checks that could be performed. The ITS could easily be outdated very quickly and an amendment to the ITS would be necessary whenever a new technical change is necessary. For example, whenever new requirements with regards to the machine-readable format, metadata or QES are established with regards to any of the types of information, an amendment of the ITSs would be necessary to ensuring validation of those new requirements. This approach would therefore be more costly and excessively inflexible.

Conclusion on Policy issue 1: Option 1.1. was retained.

Policy Issue 2: Specify the open standard licences which CBs may apply to the datasets they make available to ESAP

Option 2.1: Specify the Creative Commons Public Domain Dedication (CC0) or any equivalent open license, for information other than covered by copyright and other related rights. Apply Creative Commons Licence BY-NC-ND for information covered by copyright and other related rights.

This option requires the CBs to apply CC0 open standard license or equivalent. The Creative Commons (“CC”) licences are recommended by the Commission as option for standard public licenses, but this option would allow the use of other open licenses that have the same attributes and follow the same conditions as the CC licences. For information covered by copyright and other related rights Creative Commons Licence BY-NC-ND applies.

Option 2.2: Specify Creative Commons Licence BY-NC-ND for all information in scope of ESAP

Under this option, the JC proposes to use Creative Commons Licence BY-NC-ND for all information in scope of ESAP.

Policy Issue 2– Option 2.1: Specify the Creative Commons Public Domain Dedication (CC0) or any equivalent open license, for information other than covered by copyright and other related rights. Apply Creative Commons Licence BY-NC-ND for information covered by copyright and other related rights. (preferred option)

Pros	Cons
This approach would ensure a high degree of harmonization across data sets and across CBs. CBs would have the flexibility to choose their preferred type of open standards license as long as they have the same attributes and follow the same conditions as those specified by the JC.	Certain information covered by copyright and other related rights would not going to be available for use and reuse by users wishing to use if for commercial purposes.
Creative Commons is the leading licensing solution for public sector information and it is recommended for use by Commission guidance. This approach would therefore ensure consistency with other EU legislation.
This approach would ensure that CBs do not impose any additional conditions that could adversely affect the public accessibility, use, and re-use of the information under the scope of ESAP.
Information covered by copyright and other related rights would be protected from commercial use as requested in response to the public consultation by certain stakeholders.

Policy Issue 2 – Option 2.2: Specify different Creative Commons License BY-NC-ND for all information in scope of ESAP

Pros	Cons
This approach would ensure full harmonization across data sets and across CBs.	All data in scope of ESAP would not be available for use and reuse for commercial purposes. This would severely limit the usability of ESAP and its usefulness to certain stakeholders such as data providers.

Conclusion on Policy issue 2: Option 2.1. was retained.

Policy Issue 3: Specify the characteristics of the API for data collection

Option 3.1: A push model

This option proposes to use a push model, where the CBs send the information and the metadata to ESAP, using ESMA’s data collection API for data submission. In this case, the CBssend the required data to ESAP for further processing and publication, in line with the provisions of Art.5(1)(e). ESMA implements the server-side of the API for data collection, whilst the CBs are users of the API and implement the client-side of the API.

Option 3.2: A pull model

This option proposes implementing a pull model, where ESMA initiates the data request by connecting to the APIs for each collection body for data collection. ESMA is a user of the API and implements the client-side of the API, sending requests to CBs which should respond and provide ESMA with the requested data. CBs have to implement the server-side of the API for data collection and need to ensure its ability to serve requests originating from ESAP, operate the servers and ensure their availability.

Option 3.3: Implement a hyperlink model

This option proposes that the CBs provide ESAP with metadata and a link to information stored on their platforms only (i.e. CBs do not provide to ESAP the actual information). The ESAP platform consequently does not provide access to the information itself but only to hyperlinks which direct to information which is stored on the CBs data portals only.

Policy Issue 3– Option 3.1: Push model (preferred option)

Pros	Cons

This approach would align with the current data collection methods established and used by ESMA and other authorities, thus not requiring significant changes for the existing data collections. It would therefore ensure the smoothest transition to the ESAP collection process. Both CBs and ESMA would be storing data for the purpose of ESAP.

Implementing the client-side of the API would allow for lower setup and operational cost for collection bodies, compared to the pull model where collection bodies would have to setup, operate and ensure availability the server-side of the API.

Policy Issue 3 – Option 3.2: Pull model

Pros	Cons
Only CBs would be storing data for the purpose of ESAP, which would therefore minimize the cost of storing data.	In a pull model each NCA would have to implement the server side of the API. This would be much more costly for NCAs to setup and operate compared to a push model since the costs of maintaining all ESAP functionalities by all CBs are much more significant than the costs of ESMA storing ESAP data.
	Several existing registers would need to be re-build from the scratch given that they are built on the basis of a push model already.

Policy Issue 3 – Option 3.3: Hyperlink model

Pros	Cons
This approach would reduce the amount of data being transmitted by CBs and stored by ESMA.	The CBs would not provide ESAP with the information itself, and therefore would be in breach of Article 5(1) of the ESAP regulation. Furthermore, ESMA would not be able to provide access to the information but rather would act as a collection of links and therefore would be in breach of its obligations under Article 1 of the ESAP regulation.
New systems would need to be built for the current regimes where there is already a data collection system in place (whereby ESMA receives, processes and stores the data).
The user experience is likely to be significantly worse than in a scenario in which ESMA provides direct and immediate access to the information, and this is because the system would need to query all CBs at each search by a user. The search result would therefore be much slower.
The cost for CBs would be significantly higher because each collection body would need to implement all the capabilities of the ESAP tool mandated by the Regulation (including search, download, translation, etc.) rather than only ESMA doing so.

Conclusion on Policy issue 3: Option 3.1. was retained.

Policy Issue 4: Specify the time by when the collection body should provide ESMA with the information

Option 4.1: Specify that the information should be provided to ESMA as soon as possible, with a maximum time delay of sixty minutes.

Under this option the JC specifies that the CBs need to submit the information to ESMA as soon as possible and at the latest sixty minutes after a reference time moment, which itself depends on whether information is published or verified.

Option 4.2: Specify that the information should be provided to ESMA within one day

This option specify that the CBs need to submit the information to ESMA within one day after publication.

Option 4.3: Specify that the information should be provided to ESMA as soon as possible

This option indicates that the CBs should provide the information to ESMA as soon as possible following publication, without setting a specific timeframe. The determination of what constitutes “as soon as possible” is left to the discretion of the CBs.

Policy Issue 4 – Option 4.1: The information should be provided to ESMA as soon as possible, with a maximum time delay of sixty minutes (preferred option)

Pros
Cons
Considering that the ESAP system was conceived in L1 as a two-tier system, and that therefore real-time submission to ESMA cannot be requested from CBs, this option would provide CBs with enough flexibility to effectively manage their internal processes, whilst still providing an upper boundary to such flexibility. For data that might be time-sensitive, investors for whom a time limit of 60 minutes is excessive would most likely to continue to use other resources which provide immediate access to such data. Setting a maximum time frame for data submission would ensure standardization across all CBs. This approach would therefore mitigate the risk of varying interpretations of “as soon as possible”, thereby preventing excessive delays. For some CBs this time limit could prove to be challenging and adapting the existing processes and infrastructure to the new ESAP requirements might entail some costs. Information would be made available on ESAP as soon as possible. This would ensure that investors and other stakeholders can rely on ESAP as a timely source of information. ESAP would be built leveraging largely on existing systems for data collection, thus minimising implementation costs.

Policy Issue 4 – Option 4.2: The information should be provided to ESMA within one day

Pros
Cons
Setting a maximum time frame for data submission would ensure standardization across all CBs. This approach would mitigate the risk of varying interpretations of “as soon as possible”.
Allowing the CBs to submit the information to
ESMA within one day after publication would diminish the usefulness of the ESAP as one day might be considered to be too long by certain stakeholders.
CBs would have a lot of flexibility to effectively manage their internal processes, whilst the JC would still provide an upper boundary to such flexibility.
For data that might be time-sensitive, investors for whom a time limit of one day is excessive would most likely continue to use other resources which provide immediate access to such data.

Policy Issue 4 – Option 4.3: The information should be provided to ESMA as soon as possible

Pros
Cons

Under this approach
CBs would most comfortably be able to adapt their existing processes and infrastructure to the new ESAP requirements.
Not specifying a maximum delay of submission of data to ESMA would create a risk of lacking uniformity across the EU since “as soon as possible” can be interpreted by the CBs in different ways. This would diminish the value of having one single data platform at EU level.

Conclusion on Policy issue 4: Option 4.1. was retained.

6.1.2 ITSs specifying certain functionalities of ESAP

Problem definition

210. The ESAP Regulation mandates ESMA to establish and operate the ESAP to facilitate access to information disclosed by entities. The main challenge in this context lies in ensuring that the data is accessible to diverse stakeholders while maintaining a user-friendly and efficient ESAP search function. Consequently, the problem that needs to be addressed is the development of an effective ESAP search function that not only complies with the legal framework but also caters for user requirements without causing unnecessary burden for entities and CBs.

211. Another major challenge in the context of ESAP lies in ensuring that the information provided to ESMA is as harmonized as possible while minimizing the burden on entities and on the CBs themselves.

Objectives

212. In the context of this ITS, the areas which were deemed most relevant to assess in terms of cost and benefits were the approach to the legal entity identifier, the size of the entities and the industry sector.

Policy options

Policy Issue 5: Define the specific legal entity identifier

Option 5.1: Specify that the legal entity identifier should be the ISO 17442 LEI code

Under this option, entities identify themselves using the ISO 17442 LEI code as the legal entity identifier.

Option 5.2: Specify the VAT number or the EUID as the legal entity identifier

Under this option, entities identify themselves using their VAT number or their EUID.

Policy Issue 5 – Option 5.1: Specify that the legal entity identifier should be the ISO 17442 LEI code (preferred option)

Pros	Cons
The LEI is already required for participants in financial markets and therefore it would come at no extra cost and effort for these entities to report it. All entities in scope of phase 1 of ESAP should normally already have an LEI as they are covered by the LEI requirement stemming from MIFIR (applicable to investment firms and clients of investment firms). Some entities submitting information in phase 2 and 3, including entities submitting information on a voluntary basis may not have an LEI. However, since phase 2 and 3 will go live only in 2028 and 2030 respectively, and that the landscape both at EU and international level regarding legal identifiers is fast evolving, it is deemed best to concentrate on phase 1 for the moment and re-assess the availability of the LEI, and if necessary, of a suitable alternative identifier at a later stage for that population of entities. The JC proposes to re-assess the issue of identifiers starting in Q3 2026, following the first phase of ESAP reporting has been launched.	LEI is a paid-for identifier, therefore specifying the LEI as the identifier for the purpose of ESAP would impose some limited costs to the entities that do not already have one (the average LEI registration fee in the EU amounts to 60 euros per year). The broad support in the consultation paper indicates that this is not perceived as a significant cost by respondents.
Consolidated access to the full set of LEI reference data (the GLEIF database) is free of charge for the users (such as retail investors, market participants and regulators). The GLEIF database also allows for reference data to be downloaded in bulk, which enables users to access a golden copy of the reference data pertaining to all entities. The golden copy is available with daily frequency. This approach would therefore ensure that no extra costs are incurred by users of the information.
The LEI is a code based on the ISO 17442 standard developed by the International Organization for Standardization (ISO). Therefore, it is a unique key to standardized information on legal entities globally. This would ensure visibility and searchability of entities in

the scope of ESAP not only to EU investors but also to global investors.

The GLEIF database would enable the retrieval of additional information necessary for the ESAP search system, without mandating entities to submit this data as additional metadata.

The GLEIF database conducts quality control of the data and ensures the uniqueness of the LEI codes attributed to entities. This would ensure high reliability of the reference data and allows data quality checks to be performed by regulators.

The LEI can act as a unique “key” linking different databases and other sources of information available at the national and international level, especially since it is already mandated in many existing pieces of EU and national legislation for reporting purposes. It would therefore be very beneficial to data users (including regulators) to be able to link the information disclosed under ESAP with disclosures made under other legal obligations by the same entities.

Policy Issue 5 – Option 5.2: Specify VAT number or the EUID as legal entity identifier

Pros	Cons
The VAT and EUID number is free to obtain for entities and therefore would come at no extra cost for them.	The introduction of the VAT number or of the EUID at this stage would risk jeopardizing the quality of the data in ESAP as ESMA and CBs would not be able to check whether the code reported is correct and corresponds to the entity it should correspond to. This is because there is no freely accessible and EU-wide VAT or EUID reference data at the moment, and no data quality protocols to ensure that the codes used across the EU are reliable and that there are no duplicates (which would impair the searchability of entities).
The use of a non-global identifier would limit visibility of entities in scope, especially limiting their exposure to cross-border and non-EU funding sources.
ESMA and CBs would not be able to source additional information from a central database and would therefore need to mandate entities to report extra metadata in order to be able to offer the search functionalities on the basis of the criteria specified under Article 7 paragraph 3 of ESAP.
The information on ESAP would not be interoperable with information reported under other financial markets legislations as entities would not be identifiable on the basis of a single “key”.

Conclusion on Policy issue 5: Option 5.1. was retained.

Policy Issue 6: Define the categories of the size of the entities

Option 6.1: Leverage whenever possible on size categories / threshold already existing under sectorial legislation only

This option leverages on the existing size categories or thresholds for regimes that already have such classification in place. For those regimes that currently do not have specific categories defined based on the size of the entities, a generic metadata item is used.

Option 6.2: Leverage whenever possible on size categories or on thresholds already existing under sectorial legislation and create new categories of size for remaining entities

Under this option, the existing size categories or thresholds for regimes that already have such classification in place are used. For those regimes that currently do not have specific categories defined based on the size of the entities, newly defined categories and/or thresholds are defined. This option requires entities to calculate and report certain new size categories when they do not already fall in one.

Option 6.3: Develop new standardised size categories (small / medium/ large) applicable to all entities in scope of ESAP with the same thresholds applicable to all entities

Under this option, the JC defines new size categories which are applicable to all entities in scope of ESAP regardless of their category under existing sectorial legislation.

Policy Issue 6 – Option 6.1: Leverage whenever possible on size categories or on thresholds already existing under sectorial legislation (preferred option)

Pros	Cons
Using existing size categories or thresholds for regimes that already have such classifications in place would ensure consistency and continuity, reducing the need for significant changes or adaptations from entities in scope of ESAP.	Using a generic metadata item for size would make certain entities in scope not searchable by size.
Using existing size categories or thresholds would mean that users and investors are familiar with the categories by size used in the ESAP context.	Under this approach it would not be possible to search all entities in scope of ESAP by size. Furthermore, each category would apply only for similar entities, and -for example- entities defined as large under one reporting framework would not necessarily be comparable with entities defined as large under another.
By creating a generic metadata item for entities under regimes that do not have a classification of size for entities, this approach would minimise the burden for entities since they would not need to calculate a new size.

Policy Issue 6 – Option 6.2: Leverage whenever possible on size categories or on thresholds already existing under sectorial legislation and create new categories of size for remaining entities

Pros	Cons
Using existing size categories or thresholds for regimes that already have such classifications in place would ensure consistency and continuity, reducing the need for significant changes or adaptations.	This approach would create additional burden for entities to calculate and report on new size categories whenever they do not already fall in a category, only for the purpose of the ESAP search function.
By complementing with new categories for those regimes without classification of sizes, this approach would enhance the completeness of the data in ESAP.	Defining new size categories might be excessive since such categories are not defined in the level 1 legislation.
	Users may not find the new categories by size clear since they are not familiar with them.

Option 6.3: Develop new standardised size categories (small / medium/ large) applicable to all entities in scope of ESAP with the same thresholds applicable to all entities

Pros	Cons
Developing new standardized size categories would ensure that all entities in scope of ESAP can be compared on the basis of the same categories.	This approach would create additional burden for entities to calculate and report on new size categories and might be confusing to users who are not used to those categories.
	This approach would often result in a meaningless search function because certain categories of entities (for example banks) would systematically be classified as large whilst others (for example CRAs) would systematically be classified as small. It would not be possible to distinguish between, for example, small/medium/large banks and small/medium/large CRAs.

Conclusion on Policy issue 6: Option 6.1. was retained.

Policy Issue 7: Define the characterization of industry sectors for non-financial entities

Option 7.1: Use the first level of NACE code

This option uses the first level of the NACE Rev 2.1 code (Commission Delegated Regulation (EU) 2023/137) for the classification of industry sectors for non-financial entities.

Option 7.2: Use the second level of NACE code

Under this option, the second level of the NACE Rev 2.1 code is used for the classification of industry sectors for non-financial entities. Compared to the option 7.1, the second level provides a more granular level of classification.

Policy Issue 7 – Option 7.1: Use the first level of NACE code (preferred option)

Pros	Cons
The NACE code is widely used in the EU for classification of industry sectors and is considered an industry standard classification system in EU. All of the non-financial entities of the European Union would be classified according to their activities, as it is the case in	The first level of NACE codes would offer a broad categorization, which might be too generic for the needs of certain advanced users.

other reporting frameworks in place already today.

The first level of NACE code would enable the search function to be efficient and user-friendly, as it spares users from the need to understand the various categorizations in depth, while offering a comprehensive overview.	Sustainability reporting under the Taxonomy Regulation requires entities to classify their activities on the basis of the second level of NACE code, therefore the ESAP search function under this option would be less granular than the classification of activities required under sustainability reporting by companies.
Using the first level NACE code would be consistent with the approach taken in other reporting frameworks such as EMIR and SFTR.
Using the first level NACE code would entail the smallest effort from entities since a smaller number of codes would need to be reported than under the second level NACE code.

Policy Issue 7 – Option 7.2: Use the second level of NACE code

Pros	Cons
The NACE code is widely used in the EU for classification of industry sectors and is considered an industry standard classification system in EU.	Using the second level of the NACE would increase the burden on entities since the second level requires for many companies to report many codes.
The second level of NACE allows for a more granular and specific identification of the economic activities of entities. This can enhance the precision and effectiveness of searches, making it easier to find and analyse entities based on their specific economic activities.	The use of very detailed NACE codes could potentially complicate the search process and make it less user-friendly. Users may have to navigate through a larger number of categories or may struggle to identify the appropriate category for their search. This could ultimately reduce the efficiency and effectiveness of the ESAP’s search function.

Conclusion on Policy issue 7: Option 7.1. was retained.

7. Advice by the SMSG

213. ESMA, EBA and EIOPA’s Securities and Markets Stakeholder Group (SMSG) were consulted with regards to the Consultation on these draft ITSs and did not provide an advice on these ITSs.

Final Report on draft Implementing Technical Standards

Contents

1. Executive Summary

Reasons for publication

Content

Next steps

2. Acronyms and definitions

3. Background

4. Feedback from the Public Consultation

4.1.1 Tasks of CBs

(i) Automated validations

Proposed way forward

2) Do you agree with the above proposal how the CBs shall verify that the information is data-extractable? In case of any challenges foreseen, please propose alternatives.

Proposed way forward

3) Do you agree with the above proposal how the CBs shall verify that the information is machine-readable? In case of any challenges foreseen, please propose alternatives.

Proposed way forward

4) Do you agree with the above proposal for the validation of the metadata? In case of any challenges foreseen, please propose alternatives.

43. Proposed way forward

5) Do you agree with the proposed approach to the validation of the electronic seal? In case of any challenges foreseen, please propose alternatives.

Proposed way forward

6) Do you agree that the format of rejection feedback to the submitting entities should be standardised?

Proposed way forward

7) Do you agree that the rejection feedback should be provided in a common format in accordance with ISO 20022 methodology? If not, please propose suitable alternatives.

9) Do you agree that QES under ESAP should be in XAdES, CAdES or PAdES format?

Proposed way forward

10) Do you agree that there is no need to use ASiC format under ESAP?

Proposed way forward

11) Do you agree that QES under ESAP should be at least at conformance level LT?

12) Do you agree with the requirement to include ISO 17442 LEI code as an attribute in the digital certificates whenever the information submitted to ESAP is accompanied by a QES?

13) Are there any other characteristics of the QES that should be defined under ESAP?

Proposed way forward

(iv) The characteristics of the (data collection) application programming interface (API)

15) Do you agree with the proposed characteristics of the API for data collection? If not, what alternative characteristics would you recommend?

16) Do you agree with the proposed approach to the format, list and characteristics of the metadata? If not, what alternative approach would you recommend?

Proposed way forward

(vi) The time limits

17) Do you agree with the proposed approach with regards to time limits? If not, what alternative approach would you suggest?

Proposed way forward

Proposed way forward

(vii) The indicative list and characteristics of formats that are acceptable as data extractable formats and as machine readable formats

20) Do you agree with the indicative list of formats and characteristics proposed? If not, what alternative formats or characteristics would you recommend?

Proposed way forward

4.1.2 Functionalities of ESAP

(i) The characteristics of the (data publication) API

21) Do you agree with the proposed characteristics of the API for data publication? If not, what alternative characteristics would you recommend?

Proposed way forward

(ii) The specific legal entity identifier

22) Do you agree with the proposal to specify that the legal entity identifier should be the ISO 17442 LEI code? If not, what other identifier would you suggest and why?

Proposed way forward

(iii) The classification of the types of information

23) Do you agree with the proposed approach with regards to types of information? If not, what additional/ alternative type of information do you recommend?

Proposed way forward

(iv) The categories of the size of the entities

Proposed way forward

Proposed way forward

Proposed way forward

(v) The characterization of industry sectors

28) Do you agree with proposed approach with regards to the categorisation of industry sectors? If not, what approach would you suggest and why?

Proposed way forward

29) Do you think additional or fewer sectors would be appropriate for the ESAP search function? If so, which ones would you propose to add and/or remove?

Proposed way forward

5. Draft ITSs

5.1 ITSs specifying certain tasks of collection bodies

COMMISSION IMPLEMENTING REGULATION (EU) 202X/XXX of XXXX laying down implementing technical standards with regard to certain tasks of the collection bodies pursuant to Regulation (EU) 2023/2859 of the European Parliament and of the Council

Article 1

Technical Automated validations

Article 2

Characteristics of the Qualified Electronic Seal

Article 3

Open Standard Licence

Article 4

Characteristics of the data collection API

Article 5

Characteristics of metadata

Article 6

The time limits

Article 7

Indicative list and characteristics of acceptable formats for the information

Article 8

Entry into force and application