Business Requirements Document FIRDS Reference Data

Transcription

1 Business Requirements Document FIRDS Reference Data 30 October 2015 ESMA/2015/MDSC/1

2 Date: 30 October 2015 ESMA/2015/MDSC/1 Document control: Version Date Author Comments /11/2014 Jerry Nason First draft /11/2014 Jerry Nason Updated for comments from Lukasz Popko /11/2014 Jerry Nason Updated after further review by Cyril Minoux and Lukasz Popko /11/2014 Jerry Nason Updated for changes in RTS received 24/11/ /11/2014 IT Project Team Finalization of the initial draft for Markets Division review /12/2014 IT Project Team Processing comments from Markets Division /12/2014 IT Project Team Processing comments from Markets Division /12/2014 IT Project Team Processing comments from Markets Division /12/2014 IT Project Team Processing comments from Markets Division /12/2014 IT Project Team First draft for Task Force review /02/2015 Cyril Minoux Processing comments from ITMG, the Markets IT Task Force, and MDRWG /02/2015 Cyril Minoux Review with Markets IT Task Force /03/2015 Cyril Minoux Processing of internal comments /03/2015 Cyril Minoux Coverage of the full scope of the FIRDS project /03/2015 Cyril Minoux Version for review by Task Forces, Standing Committees and ESMA, incorporating comments from Markets IT Task Force and MDRWG SG 2/3 on v0.13 and internal comments on v0.14. ESMA CS rue de Grenelle Paris Cedex 07 France Tel. +33 (0)

3 Date: 30 October 2015 ESMA/2015/MDSC/ /05/2015 Cyril Minoux Version for review by Task Forces, Standing Committees and ESMA /06/2015 Peter Lefterov Cyril Minoux Processing comments /06/2015 Cyril Minoux Version including details on Transparency calculations, for review by Task Forces, Standing Committees and ESMA /07/2015 Cyril Minoux Processing comments received from SG2/3, Markets IT Task Force, FIRDS Delegated Project Task Force, and ESMA /07/2015 Cyril Minoux Version for review by ESMA, MDRWG and SMSC /08/2015 Cyril Minoux Processing comments received from MDRWG and SMSC /08/2015 Cyril Minoux Updates following Task Forces Split of document into Reference Data / Transparency calculations and suspensions coordination /09/2015 Cyril Minoux Updates following Task Forces /10/2015 Cyril Minoux Updates following SG2/ /10/2015 Cyril Minoux Updates following SG2/3 and IT Task Forces /10/2015 Cyril Minoux Updates following SG2/3. Final draft for MDSC approval. Distribution List: Name Department Role Olga Petrenko Joanna Lednicka Review Review ESMA CS rue de Grenelle Paris Cedex 07 France Tel. +33 (0)

4 Date: 30 October 2015 ESMA/2015/MDSC/1 Giulia Ferraris Alexandru Dincov Pedro Coutinho Cyril Minoux Robert Kelly Review Review Review Review Review Reference documents: Ref Title Version Author Date 1 MiFIR - REGULATION (EU) No 600/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 15 May 2014 (Article 27) 600/2014 European Parliament Council of Europe 15 May MAR - REGULATION (EU) No 596/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 16 April 2014 (Article 4) 596/2014 European Parliament Council of Europe 16 April 2014 ESMA CS rue de Grenelle Paris Cedex 07 France Tel. +33 (0)

5 Table of Contents 1 Introduction Purpose and audience of this document Context description Scope Definitions Functional requirements Overview of the system Data Collection Collection of Financial Instruments Reference Data on behalf of NCAs delegating data collection in their jurisdiction Collection of Financial Instruments Reference Data from NCAs not delegating data collection in their jurisdiction Collection of quantitative data for the purpose of yearly RCA reassessment on equity Other reference data Data validation and error management Reference data validation and error management Data collection monitoring for NCAs delegating data collection in their jurisdiction Exception handling Re-submissions within the same submission period Late submission of reference data Data Processing Determination of the Relevant Competent Authority for a new instrument Change of Relevant Competent Authority for existing instruments Data storage Publication Publication on ESMA Website Provision of reference data to NCAs Provision of reference data to NCAs delegating data collection Interfaces with other systems Non-functional requirements Security

6 3.2 Availability Performance Data retention Backup and disaster recovery Compliance with standard Ergonomic requirements...30 Annex 1. Scope of the reference data to be received...31 Annex 2. Scope of the reference data to be published...31 Annex 3. Expressions of interest on indices...32 Annex 4. Non-working days...32 Annex 5. Content of feedback files...32 Annex 6. Applicable rules for the determination of the RCA...34 Annex 7. Reference Data content validation rules...39 Annex 8. Indicative list of Delegating and Non-Delegating NCAs

7 1 Introduction 1.1 Purpose and audience of this document 1. This document specifies the functional and non-functional business requirements for the Financial Instruments Reference Data System (FIRDS). As per project presentation document (ESMA/2014/BS/192 Annex 2.3) the project covers requirements for reference data collection and publication, collection and processing of additional data to support the MiFIR transparency regime, and suspensions coordination. This document specifically focuses on the reference data collection and publication. 2. The intended audience of this document is ESMA policy and IT staff as well as the Market Data Standing Committee (MDSC), and the IT Management and Governance group (ITMG). 3. This Business Requirement Document (BRD) is intended to be used as an input for design stages of the Financial Instruments Reference Data System delegated project. The solution will be described in the Functional Specifications Document (FSD). 4. These business requirements have been drafted based on MiFiR, MAR and on the expectations from the business. 1.2 Context description 5. The new requirements of the Markets in Financial Instruments Regulation (MiFIR) and the Market Abuse Regulation (MAR) oblige trading venues and Systematic Internalisers to submit identifying reference data for the relevant financial instruments to competent authorities who are required to transmit it to ESMA for subsequent publication on its website. This is in particular required to support the scope of transaction reporting under MiFIR, as well as market abuse surveillance activities under MAR. 6. A Reference Data System has been developed and is currently in operation in ESMA. MiFIR Article 27 and MAR Article 4 impose further requirements upon the processing of financial instrument reference data, the following diagram is provided for high-level illustration. The reporting entities are common to both the MiFIR and the MAR requirements, except for Systematic Internalisers which will only report under MiFIR. 7

8 Figure 1 MiFID I and MAR/MiFIR Scope of Instrument Reference Data 7. The Board of Supervisors decided on 17 December 2014 to delegate tasks to ESMA and launched in particular the Financial Instruments Reference Data System project. 8. Detailed scope is provided in the next section. 1.3 Scope 9. The collection of reference data covering the requirements of MiFIR Article 27 and MAR Article Records collected under MAR Article 4 will be a subset of the records received under MiFIR Article 27, and in the same format, with the exception of a few fields such as the date of the request for admission. 11. Validation of the file upon receipt, as well as validation of its content. 12. Storage of all validated reference data received in an ESMA database. 13. Processing, publication and distribution of financial instruments reference data to the National Competent Authorities. 14. Allow suspensions coordination on all instruments traded on Regulated Markets, Multilateral Trading Facilities, Organised Trading Facilities and Systematic Internalisers. 8

9 1.4 Definitions ADT AVT BRD Average Daily Turnover Average Value of Transactions Business Requirements Document (this document) CFI Classification of financial instruments code as defined in ISO ESMA ITMG ITS European Securities and Markets Authority IT Management and Governance group Implementing Technical Standards MIC Market Identifier Code as defined in ISO MTF NCA NCA delegating data collection NCA delegating transparency calculations Non-delegating NCA OTF RCA / Relevant Competent Authority RM RTS SI TV Trading Venues and Systematic Internalisers must be identified by a MIC code. In the context of this document, in accordance with RTS on Article 27 ( trading venue field) the MIC code must be interpreted as Segment MIC for the trading venue or systematic internaliser, where available, otherwise operating MIC. Multilateral trading facility, as defined in Art.4(22) of Directive 2014/65/EU National Competent Authority A National Competent Authority who has signed a Delegation Agreement with ESMA in order to delegate the task of collecting data in their jurisdiction directly from Trading Venues, Systematic Internalisers, APAs and CTPs for the purpose of reference data provision and transparency calculations A National Competent Authority who has signed a Delegation Agreement with ESMA in order to delegate the task of performing transparency calculations A National Competent Authority who has not signed a Delegation Agreement with ESMA on the Instruments Reference Data Project Organised trading facility, as defined in Art.4(23) of Directive 2014/65/EU The National Competent Authority that has the most relevant market in terms of liquidity as per MiFIR Article 26 under its jurisdiction Regulated Market Regulatory Technical Standards Systematic Internaliser Trading Venue, covering Regulated Markets, Multilateral Trading Facilities, Organised Trading Facilities 9

10 2 Functional requirements 2.1 Overview of the system Non-Delegating NCAs Data collection monitoring Data Quality Management NCAs delegating transparency calculations only I/F (NCAs) RM MTFs OTFs Interface to TV / SI Check for data transmission errors Check for format errors (XML validation) Check for data content errors Reference data processing Instruments Reference Data Publication of reference data on the internet Transmission of Reference Data to NCAs Changes to RCA Interfaces with NCAs NCAs SIs Entities reporting Instruments Reference Data under MIFID II Support to reporting entities Interface to LEI data provider Additional reference data Interface to ISO currency and country codes Interface with the suspensions coordination system Interface with the Transparency system Global LEI Foundation LEI LEI LEI LEI Figure 2 Overview of the instruments reference data system As per MiFIR requirements, Trading Venues and Systematic Internalisers shall provide reference data to their Competent Authority ; Competent Authorities provide that information to ESMA ; ESMA publishes that information on its website and gives access to it to NCAs. Figure 3 MiFIR Article 27 requirements 10

11 Some National Competent Authorities 1 have delegated to ESMA the tasks of performing transparency calculations on their behalf (referred to as NCAs delegating transparency calculations ). Some of these National Competent Authorities have also delegated to ESMA the tasks of collecting data directly from Trading Venues and Systematic Internalisers in their jurisdiction (referred to as NCAs delegating data collection ). Jurisdiction of a NCA delegating both data collection in its jurisdiction and transparency calculations RM / MTF / OTF / SIRM / MTF / OTF / SIRM / MTF / OTF / SI Reference data Reference data Reference data Jurisdiction of a NCA delegating transparency calculations only RM / MTF / OTF / SIRM / MTF / OTF / SIRM / MTF / OTF / SI Reference data Reference data Reference data NCA Reference data Reference Data NCAs ESMA Website Jurisdiction of a Non-Delegating NCA RM / MTF / OTF / SIRM / MTF / OTF / SIRM / MTF / OTF / SI Reference data Reference data Reference data NCA Reference data Figure 4 Reference data flow 1 See Annex 8 - Indicative list of Delegating and Non-Delegating NCAs 11

12 2.2 Data Collection Collection of Financial Instruments Reference Data on behalf of NCAs delegating data collection in their jurisdiction Figure 5 Reference Data flow for Trading Venues under the jurisdiction of a NCA delegating data collection 15. Each day that a TV/SI under the jurisdiction of a NCA delegating data collection is open for trading, the ESMA system will receive from that TV/SI the complete identifying reference data for: all instruments admitted to trading on Regulated Markets that are still valid 2 or for which a request for admission to trading has been made; all instruments traded on a MTF or OTF, including where orders or quotes were placed between 18:00 CET on the previous day and 18:00 CET on that day on that MTF or OTF; any instruments traded on a Systematic Internaliser including where orders or quotes were placed between 18:00 CET on the previous day and 18:00 CET on that day on that Systematic Internaliser where the underlying: (i) is a financial instrument traded on a trading venue, (ii) is an index or a basket composed of financial instruments traded on a trading venue. 16. The instruments reference data fields to be received for each instrument is specified in Annex The complete instrument reference data may be provided by the submitting entities in one or multiple files. Within a given file, no more than one record should be provided for each (ISIN-MIC) combination. For technical reasons, the system may limit the maximum size of a file In case reference data is provided in multiple files for the same (ISIN-MIC) combination, the system will only take into account the latest record submitted. 2 An instrument is considered valid until its termination date. In case the termination date is initially left empty, the reporting entity is expected to fill it in when the instrument is going to be terminated. In case an instrument is terminated early, the RCA of the instrument is expected to update the value of the termination date accordingly, and the system shall take that new termination date into account. 3 This will be specified in the Functional Specification Document. 12

13 19. The reference data files transmitted by TVs, and SIs will use the same standardised ISO XML format as the files transmitted by NCAs not delegating data collection. 20. TVs / SIs will provide the full instrument reference data by 21:00 CET. 21. The instrument reference data provided by submitting entities will cover both MiFIR and MAR requirements. Under MAR, submitting entities are only required to report instruments reference data twice: a. when a request for admission to trading is made, when it is admitted to trading or when it is traded for the first time; b. when the instrument ceases to be traded or to be admitted to trading Collection of Financial Instruments Reference Data from NCAs not delegating data collection in their jurisdiction Figure 6 Reference Data flow for Trading Venues under the jurisdiction of a Non-Delegating NCA 22. Each day that a TV/SI under the jurisdiction of a Non-Delegating NCA is open for trading, the ESMA system will receive from the Non-Delegating NCA the complete identifying reference data for all TV/SI under the jurisdiction of the Non-delegating NCA on: all instruments admitted to trading on Regulated Markets that are still valid 4 or for which a request for admission to trading has been made; all instruments traded on a MTF or OTF including where orders or quotes were placed between 18:00 CET on the previous day and 18:00 CET on that day on that MTF or OTF; all instruments traded on a Systematic Internaliser including where orders or quotes were placed between 18:00 CET on the previous day and 18:00 CET on 4 An instrument is considered valid until its termination date. In case the termination date is initially left empty, the reporting entity is expected to fill it in when the instrument is going to be terminated. In case an instrument is terminated early, the RCA of the instrument is expected to update the value of the termination date accordingly, and the system shall take that new termination date into account. 13

14 that day on that Systematic Internaliser where the underlying: (i) is a financial instrument traded on a trading venue, (ii) is an index or a basket composed of financial instruments traded on a trading venue. 23. The instruments reference data fields to be received for each instrument is specified in Annex The complete instrument reference data may be provided by the submitting entities in one or multiple files. Within a given file, no more than one record should be provided for each (ISIN-MIC) combination. For technical reasons, the system may limit the maximum size of a file. 25. In case reference data is provided in multiple files for the same (ISIN-MIC) combination, the system will only take into account the latest record submitted. 26. The reference data files transmitted by NCAs not delegating data collection will use the same standardised ISO XML format. 27. NCAs not delegating data collection will provide the full instrument reference data by 23:59 CET to ESMA. However, in case no validations are performed by the NCA, the NCA shall forward the files received as soon as they are received, and no later than 21:30 CET The instrument reference data provided by submitting entities will cover both MiFIR and MAR requirements. Under MAR, submitting entities are only required to report instruments reference data twice: a. when a request for admission to trading is made, when it is admitted to trading or when it is traded for the first time; b. when the instrument ceases to be traded or to be admitted to trading Collection of quantitative data for the purpose of yearly RCA reassessment on equity 29. It is assumed that the transparency data to be received for Equity instruments by the system in charge of transparency calculations will be sufficient for the purpose of the yearly RCA reassessment on equity. 5 However, files received by NCAs from their Trading Venues / Systematic Internalisers after the 21:00 CET cut-off time are expected along with the next day data submissions. E.g. if a file is received at 21:15 it should not be forwarded to ESMA at 21:20, but it may be forwarded at 21:40 (if 21:30 is the applicable NCA cut-off time) or at 0:15 am next day (if 23:59 CET is the applicable NCA cut-off time) 14

15 2.2.4 Other reference data Currency codes, Country codes, CFI codes, MIC codes, LEI 30. The system will collect from the relevant provider a. the list of ISO currency codes; b. the list of ISO country codes; c. the list of ISO CFI codes; d. the list of ISO MIC codes. 31. The system will collect from the Global LEI Foundation website the concatenated file of LEIs. The system will not collect nor redistribute BICs Non-working days 32. Before the beginning of each calendar year, the system will collect the list of dates when trading venues or systematic internalisers are not open for trading for that year, as per Annex 4. These dates will be collected directly from Trading Venues under the jurisdiction of NCAs delegating data collection, and from NCAs otherwise. 33. In addition, the system will collect from all NCAs the list of NCAs non-working days List of indices 34. The system will collect from NCAs the list of ISIN identifiers of the indices for which they are interested to receive Transaction Reports, as per Annex 3. 15

16 2.3 Data validation and error management This chapter describes the data validations that are required. The ESMA system will run these data validations on all data received, whether from TVs / SIs or NCAs Reference data validation and error management Gather and check necessary data Submitting Entity Prepare data for submission Perform XML validation Fail Correct data Analyze feedback message Pass Submit file Receive Feedback Message Receive file Reject entire file Reject entire file Records rejections and warnings ESMA Fail Fail Invalid records (rejected) Inconsistent records (warnings) Data Transmission Validation Perform Data Inconsistent Pass XML Content records validation Pass Validation Valid management Records Valid Records 35. The ESMA system will return one single feedback file for each file submitted by the submitting entity. This feedback file will report on the overall status of the submitted file, and, if the submitted file is partially accepted, list the records which did not pass the data content validations, and list the warnings on inconsistencies detected Data transmission errors 36. Upon receipt of a file, the ESMA system will check that the file transmitted by the submitting entity can be extracted and use the expected naming convention. 37. If an error is identified at this stage, a feedback is sent to notify the sender, the processing stops, and reporting is unsuccessful for all records contained in the file. The sender will have to fix the source of the errors and resubmit all the records contained in the file. 16

17 Data format errors 38. Trading Venues / SI and NCAs not delegating data validations shall only submit files after having performed successful XML-validation against a commonly agreed XML- Schema. Additionally, the ESMA system will also perform XML validation of the files received. 39. If an error is identified at this stage, a feedback is sent to notify the sender, the processing stops, and reporting is unsuccessful for all records contained in the file. The sender will have to fix the source of the errors and resubmit all the records contained in the file Data content errors 40. If the data transmission and data format tests are passed successfully, the ESMA system shall perform automated data content validations as specified in Annex If an error is identified at this stage, the corresponding record will be rejected. The system will send feedback to the sender on the erroneous records (if any) and the reason for rejection. The sender will have to fix the source of the errors and submit files containing the corrected records Inconsistent record management 42. For instruments traded on several trading venues, when reference data is provided by a NCA other than the Relevant Competent Authority for a given instrument, the system will check that the reference data provided for this instrument s identifier is consistent with the reference data provided by the Relevant Competent Authority for that identifier 43. Two records are considered consistent if they refer to the same ISIN and the fields listed in Table 1 hold strictly the same values. Trading-venue dependent fields listed in Table 2 are not involved in this comparison. 6 Table 1 Reference data fields expected to be checked for consistency against the value provided by the Relevant Competent Authority Instrument Classification Commodities derivative indicator Issuer or operator of the trading venue Identifier Financial instrument short name Notional currency 1 Total issued nominal amount Maturity date Non-free-text fields: Expiry date Price multiplier Underlying instrument code Underlying issuer Term of the direct underlying index Option type Strike price 6 e.g. If the same share is admitted to trading on two different trading venues at two different dates it is not an inconsistency. For that reason, not all fields should be taken into account when assessing the consistency of two records on the same instrument. 17

18 Currency of nominal value Strike price currency Nominal value per unit/minimum traded value Option exercise style Fixed rate Delivery type Identifier of the index/benchmark of a floating rate bond Base product Term of the index/benchmark of a floating rate bond Sub product Basis Point Spread of the index/benchmark of a Further sub product floating rate bond Transaction type Seniority of the bond Final price type IR Term of contract Notional currency 2 Fixed rate of leg 1 Fixed rate of leg 2 Floating rate of leg 2 IR term of contract of leg 2 Notional currency 2 FX Type Free-text fields: Instrument Full Name Underlying index name Name of the index/benchmark of a floating rate bond Reference rate Table 2 Trading-venue dependent fields (not involved in consistency checks) Trading venue Request for admission to trading by issuer Date of approval of the admission to trading Date of request for admission to trading Date of admission to trading or date of first trade Termination date Trading-venue dependent fields Rationale: For a given ISIN, these fields may vary for each Trading Venue / Systematic Internaliser trading that instrument. 44. In case of any difference on non-free-text fields, the system will notify the sender of the issue by generating a warning. 45. Even if the system detects an inconsistency, the system will incorporate to the list of instruments published the submitted ISIN, MIC and associated trading-venue dependent fields (Table 2). Fields present in Table 1 will be aligned to the values set by the Relevant Competent Authority for that instrument, except for free-text fields. 18

19 Management of inconsistent records within the jurisdiction of the Relevant Competent Authority 46. To cover cases when the ESMA system receives inconsistent reference data for the same ISIN from the Relevant Competent Authority or from TV / SIs under its jurisdiction, the system will implement the following rules: a. in case of a new ISIN, the system will accept the record; b. in case of an existing ISIN, if the submitted record is consistent with pre-existing records, the system will accept the record; c. in case of an existing ISIN, if the submitted record is not consistent with preexisting records, and if the new record has the earliest admission / first trading date, the system will accept the new record and all records with same ISIN will reflect the update starting from the next publication; d. in case of an existing ISIN, if the submitted record is not consistent with preexisting records, and if the submitted record doesn t have the earliest admission / first trading date, the system will reject the record, but retain the submitted (ISIN- MIC) combination (with the respective dates of request for admission, admission, first trade, and termination) and overwrite any inconsistent field relating to the instrument with the value of the pre-existing records Data collection monitoring for NCAs delegating data collection in their jurisdiction 47. The system will make available to NCAs delegating data collection in their jurisdiction monthly reports that will help identifying recurring data collection issues, such as: 19

20 a. the list of TVs which did not report at all or did not report on time more than x days during the month; b. the list of ISINs for which an inconsistency was detected, the associated dates and fields concerned. 20

21 2.4 Exception handling Re-submissions within the same submission period 48. The system shall allow NCAs, TVs and SIs to submit files containing updated version of records previously submitted. 49. Data resubmissions shall be possible during the same day until the cut-off time and may be used for a submitting entity to correct erroneous files or records. Day T Cutoff time Submitting Entity Submit Data Feedback Message... Submit Feed back Transmission Validation XML validation Erroneous file Content Validation OK / Erroneous Erroneous records records Inconsistent Records Pickup Valid records from all submitted files Load valid records in Reference Database ESMA Figure 7 Re-submission of data before cut-off time 50. In case data is provided in multiple files for the same (ISIN-MIC) combination, the system will only take into account the latest record it received before the cut-off date/time Late submission of reference data 51. The system will support deferred processing of late submitted reference data. 52. Late submissions will be processed along with data received before the next cut-off date and time. 53. The system will send a notification of failure to the submitting entity after the cut-off date and time in case of late reporting. 54. In case a NCA, TV or SI did not successfully report on time, the system will assume that the last version of reference data previously submitted is still valid and unchanged. 21

22 2.5 Data Processing 55. In the context of this document, consistently with RTS on Article 27, trading venues must be identified by their Segment MIC, where available, otherwise operating MIC Determination of the Relevant Competent Authority for a new instrument 56. The system will support the determination of the Relevant Competent Authority (the most relevant market in terms of liquidity as per MiFIR Article 26) for new instruments until the earliest Date of admission to trading or date of first trade received for that instrument. 57. The system will apply the relevant rule to the instrument based on the instrument s CFI code, using a table mapping CFI codes constructs and applicable rules as per Annex 6. This table should be configurable in the system, so that to allow for potential updates. 58. In case RTS22 Art.16 (2) ("equity / equity like") applies, the Relevant Competent Authority will be the Competent Authority of the Member State of the Trading Venue with earliest Date of request for admission (if applicable) or Date of admission to trading or date of first trade. 59. In case RTS22 Art.16 (3) and (4) ("debt") applies, a. if the country stated in the Legal Address of the LEI data record of the issuer is an EEA country, the Relevant Competent Authority will be the Competent Authority of the country stated in the Legal Address of the LEI data record of the issuer; b. otherwise the Relevant Competent Authority will be the Competent Authority of the Member State of the Trading Venue with earliest Date of request for admission (if applicable) or Date of admission to trading or date of first trade. 60. In case RTS22 Art.16 (5).a ("equity derivatives") applies, and the underlying is in the reference database, the RCA is the RCA of the underlying. 61. In case RTS22 Art.16 (5).b ("debt derivatives") applies, and the underlying is in the reference database, the RCA is the RCA of the underlying. 62. In case RTS22 Art.16 (5).c ("basket derivatives") applies, the RCA will be the Competent Authority of the Member State with earliest Date of admission to trading or date of first trade. 63. In case RTS22 Art.16 (5).d ("index derivatives") applies, the RCA will be the Competent Authority of the Member State with earliest Date of admission to trading or date of first trade. 22

23 64. In case RTS22 Art.16 (5).e ("derivatives on derivative") applies, and the underlying is in the reference database, the RCA will be the Competent Authority of the Member State with earliest Date of admission to trading or date of first trade for the underlying instrument. 65. In case RTS22 Art.16 (6) ("other") applies, the RCA will be the Competent Authority of the Member State with earliest Date of admission to trading or date of first trade. 66. In any other cases, the RCA will be the Competent Authority of the Member State with earliest Date of admission to trading or date of first trade. 67. The system will consider the date and time of reception only in case the system cannot apply the above rules to conclusively determine RCA. If such a case occurs the RCA will be the NCA of the TV / SI which record was first received by the Non- Delegating NCA (if specified as stated in Annex 1) or by the ESMA system. 68. Once the RCA for an instrument is determined based on these rules, the system will update as well the derivatives which have that instrument as single underlying Change of Relevant Competent Authority for existing instruments 69. In case RTS22 Art.16 (1) ("equity / equity like") applies, and the instrument was admitted to trading or traded at the beginning of the previous calendar year, the system will determine in March each year the Regulated Market with highest annual turnover (if any), or, in case of instruments not traded on any Regulated Market, the MTF with highest annual turnover (excluding all transactions executed under pre-trade waivers of MiFIR Art 4(1) (a) to (c)). The Relevant Competent Authority will be the Competent Authority of this Trading Venue. If the RCA changes based on this rule, the system will update as well the derivatives which have that instrument as single underlying. The changes in the RCAs will be published in the Instruments Reference Data on April 1 st each year, and start being applicable from that date. 23

24 ESMA NCA Provide the list of ISINs for which the NCA requests to become the RCA Complement the list with instruments having any of these ISINs as single underlying Reject unknown instruments (RCA not available) Review the list of instruments Ask for review Receive validation to proceed Forward request to each corresponding RCA Change RCA for ISINs for which the change was accepted by the current RCA Receive confirmation of the changes applied Send the list of the changes applied Changes will take effect starting from the next day Receive decision RCAs for an instrument Receive request Process the request (Accept or Reject) Send decision Receive confirmation of the changes applied Figure 8 Process for non-rca NCAs requesting to become the RCA ESMA RCA Provide the list of ISINs and proposed alternative RCA Complement the list with instruments having any of these ISINs as single underlying Reject unknown instruments (RCA not available) Review the list of instruments Ask for review Receive validation to proceed Forward request to each proposed NCA Change RCA for ISINs for which the change was accepted by the proposed RCA Receive confirmation of the changes applied Send the list of the changes applied Changes will take effect starting from the next day Receive decision Proposed alternative NCA for an instrument Receive request Process the request (Accept or Reject) Send decision Receive confirmation of the changes applied Figure 9 Process for the RCA requesting to have another NCA become the RCA 24

25 70. In specific cases 7, there may be a need to override the results produced by the rules implemented in the system. The system should allow a NCA to request to become the RCA for one or more ISIN(s), which should then be submitted to the approval of the corresponding RCAs. To deal with exceptional circumstances 8, the system should allow ESMA to change the RCA for an instrument upon having liaised with the involved NCAs. If the RCA changes based on this rule, the system will update as well the derivatives which have that instrument as single underlying. 7 Examples include: an instrument stops being traded on a TV, then later on trading resumes on another TV ; an ISIN gets reused for a totally different instrument 1 year after the instrument has been terminated ; two NCAs have reported different issuer LEIs on the same new debt instrument, and as per the rules, the system has determined the RCA based on the first submitted record. 8 Examples include: one of the concerned NCA has temporary issue with its IT system and is prevented to use the system s functions to request or validate the change of RCA. 25

26 2.6 Data storage 71. The ESMA system must integrate all validated reference data received into a single data store. 72. Reference data on instruments shall remain available in the instruments reference database after the termination date in accordance with section 3.4 below. 2.7 Publication 73. The system will make reference data available in the form of machine-readable files: a. Full file: the full file will contain the full reference data received from NCAs, RM, MTF, OTF and SI before the applicable previous cutoff time, for all instruments that are still valid and that have been admitted to trading on RM, including where a request for admission to trading has been made, or that are traded on a MTF, OTF, or SI. Given the expected high volume of data, the full file may be split in several files for technical reasons. b. Delta file: the delta file will contain the instruments reference data for all instruments for which a change has been made from the previous full file. c. Invalid records file: this will be the place holder for all records that are not part of the full file anymore. This includes instruments that are not valid anymore, as well as out-of-date versions of records that have been modified over time. Given the expected high volume of data, the invalid records file may be split in several files for technical reasons Publication on ESMA Website 74. The full file / delta file / invalid instruments file will be published daily before 9 am Central European Time (CET). 75. In addition, the system will offer a web interface to search and display reference data using search criteria such as the ISIN of the instrument, the ISIN of the underlying, the LEI of the issuer, the MIC code of the Trading Venue / Systematic Internaliser, or the CFI code of the instrument. 76. The system may limit the maximum number of records displayed at a time by this web interface, but will allow to navigate within the set of records in case the search results exceed that limit Provision of reference data to NCAs 77. The full file / delta file / invalid instruments file shall be made available to NCAs on the HUB before 8 am Central European Time (CET). 26

27 78. In order to flag records that were kept unchanged from a preceding day because the corresponding submitting entity did not report on time, each record will include the date / time when the record was received from the corresponding submitting entity. This information will be available in NCAs full-files only. Changes to this date / time will not be recorded in the invalid records file. 79. Records for which an inconsistency has been detected will also be flagged. This information will be available in NCAs full-files only. Changes to this inconsistency flag will not be recorded in the invalid records file. 80. The system will provide to NCAs the following additional reference data: a. list of indices and associated Competent Authorities which have registered their interest, as per Annex 3 ; b. lists of currency codes, country codes, CFI codes, MIC codes, and LEIs Provision of reference data to NCAs delegating data collection 81. The system will allow NCAs delegating data collection to request the reference data files received from the TV / SI in their jurisdiction. 2.8 Interfaces with other systems 82. Interface to the ESMA HUB will be required to receive the instrument reference data from Non-delegating NCAs, RMs, MTFs, OTFs and SIs, send feedback messages, and to provide NCA with reference data with a system-to-system interface. 83. The system will depend on data collected by the system in charge of equity transparency calculations for the collection of quantitative data necessary for the yearly RCA reassessment for equity instruments. 84. The system will depend on external reference data, for which appropriate interfaces will need to be built, such as: a. The register of Competent Authorities; b. The register of Trading Venues and Systematic Internalisers; c. A relevant provider of reference information on currency codes, country codes, CFI codes, MIC codes; d. A global register of LEI. 27

28 3 Non-functional requirements 85. In case of delegation of task, the system will comply with the Delegated Agreement SLA. 3.1 Security 86. Except for data published, the data used by this system is classified as per Table 3 according to ESMA s Information Security Policy: Table 3 FIRDS Reference Data System data classification Data item / Group or set of similar data 28 Reference Data Full file dataset including RCA 29 Reference Data Delta file dataset including RCA 40 Stored historic data (submitted files, generated daily files) 30 Data needed for determination of most relevant market in terms of liquidity - Equity (Art.4 RTS on equity) 26 Manual request for change of RCA - ad hoc Data received from TVs / NCAs for Reference Data Classification Level Confidentiality Classification Level Integrity Classification Level Availability REGULAR USE MODERATE CRITICAL REGULAR USE MODERATE CRITICAL REGULAR USE CRITICAL CRITICAL REGULAR USE STRATEGIC STRATEGIC REGULAR USE MODERATE MODERATE REGULAR USE CRITICAL CRITICAL 3.2 Availability 87. Apart for planned service interruptions, the system will operate 7 days per week and 24 hours per day, receiving and generating reference data every day. 88. Support will be available during ESMA working days and hours. If an incident occurs on a non-working day / outside of ESMA working hours, it should be analysed on the next working day and handled according to the ESMA support processes. 3.3 Performance 89. The system must be able to support collection, processing and publication of 8 million valid instrument records on a daily basis, and between 16 and 36 million new instruments per year. 28

29 90. It is expected that up to users will download the reference data on a daily basis between 9:00am CET and 11:00am CET and between 6:00pm CET and 8:00pm CET. 3.4 Data retention 91. All data in the system shall be stored for a minimum of 5 years. This requirement applies in particular to: a. Reference data published on ESMA website; b. The ESMA reference database, including historical data which shall be kept during 5 years after instruments have ceased being valid or traded; c. All original files received and sent by the system, including data files as well as feedback and error files. 3.5 Backup and disaster recovery 92. The ESMA system shall use the standard ESMA IS policies and procedures used for data backup and redundancy. 93. The Recovery Time Objective (RTO) is 4 hours; 94. The Recovery Point Objective (RPO) is 1 day. 3.6 Compliance with standard 95. The ESMA system shall comply with generally accepted standards and communication protocols The ESMA system shall be compatible with web browsers as follows: a. Internet Explorer, Firefox ESR 10 : the system will initially support the last two major desktop versions available at the time of the start of the testing phase; b. Firefox, Safari, Chrome, Edge: the system will initially support on a best effort basis the major desktop versions available 6 months before the start of the testing phase to the end of the testing phase; c. Updates to the above baseline will be supported through maintenance during the life of the system. 9 Functional specifications will in particular describe the data exchange formats 10 Firefox Extended Support Release see 29

30 3.7 Ergonomic requirements 97. The ESMA system s user interface and documentation shall be provided in English. 30

31 Annex 1. Scope of the reference data to be received The list of reference data fields to be received by the system is described in Tables 1, 2 and 3 of the Annex of the Regulatory Technical Standard on MiFIR Article 27. In addition, NCAs not delegating data collection in their jurisdiction will have the possibility to submit, for each record, the date and time they received the record from the corresponding TV / SI. This field will be used to implement the rule described in paragraph 67. This field is optional. If not specified, the date and time of reception of the file by ESMA will be used instead. Changes to this field will not be recorded in the invalid records file. Annex 2. Scope of the reference data to be published The list of reference data fields to be published by the system are: Fields described in Tables 1, 2 and 3 of the Annex of the Regulatory Technical Standard on MiFIR Article 27 ; The country of the Relevant Competent Authority ; For NCAs full file only: o o the date / time when the record was received from the corresponding submitting entity; a flag indicating whether an inconsistency has been detected for the corresponding record. 31

32 Annex 3. Expressions of interest on indices Data to be received by the system Field Description Note Identifier of the index Expression of interest ISIN code of the index, or 4-letter code as per RTS 23 Annex Table 1 {INDEX} Indicates whether to add or remove the submitting entity as being interested in the index Data to be provided by the system Field Description Note Identifier of the index Country code of the Member State having expressed its interest Date of expression of interest ISIN code of the index, or 4-letter code as per RTS 23 Annex Table 1 {INDEX} Country code of the NCA having expressed its interest in receiving Transaction Reports for that ISIN Date when the NCA last expressed its interest for the index Annex 4. Non-working days Field Description Note Country code of the NCA Trading Venue / SI Non-working day 2-letter ISO Country Code of the NCA to which the non-working days apply MIC code of the Trading Venue / SI to which the non-working days apply: segment MIC for the trading venue or systematic internaliser, where available, otherwise operating MIC. Date of the non-working day, in ISO 8601 date format To be populated for NCA non-working days To be populated for Trading Venue / SI non-working days To be repeated for each non-working day of the NCA / TV / SI Annex 5. Content of feedback files Field Description Note File identifier Report status Identifies the file on which feedback is provided Indicates whether the submitted file was fully accepted, partially accepted, or fully rejected due to data transmission or data format errors 32

33 Field Description Note Rejected file error Error reference and message associated with the rejected file. Only in case a transmission error or format error has been identified. Erroneous record identifier Erroneous record error The technical identifier of the record. Error reference, status (Rejection or Warning) and message associated with the erroneous record. For inconsistent records, the message will state the fields that have been detected as inconsistent. Only in case a data content error or an inconsistent record has been identified, (file is partially accepted) 33

34 Annex 6. Applicable rules for the determination of the RCA Note: the table below should be configurable in the system, so that to allow for potential updates. Level1 Level2 CFI Construct Mapping to concepts used in RTS22 Art.16 (determination of the RCA) Entitlement (rights) Allotment Rights RA**** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Subscription Rights RSS*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Subscription Rights RSP*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Subscription Rights RSC*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Subscription Rights RSF*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Subscription Rights RSB*** RTS22 Art.16 (5).b ("debt derivatives") Entitlement (rights) Subscription Rights RSI*** RTS22 Art.16 (6) ("other") Entitlement (rights) Subscription Rights RSM*** RTS22 Art.16 (6) ("other") Entitlement (rights) Purchase Rights RPS*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Purchase Rights RPP*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Purchase Rights RPC*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Purchase Rights RPF*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Purchase Rights RPB*** RTS22 Art.16 (5).b ("debt derivatives") Entitlement (rights) Purchase Rights RPI*** RTS22 Art.16 (6) ("other") Entitlement (rights) Purchase Rights RPM*** RTS22 Art.16 (6) ("other") Entitlement (rights) Warrants RWB*** RTS22 Art.16 (5).c ("basket derivatives") Entitlement (rights) Warrants RWS*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Warrants RWD*** RTS22 Art.16 (5).b ("debt derivatives") Entitlement (rights) Warrants RWT*** RTS22 Art.16 (6) ("other") Entitlement (rights) Warrants RWC*** RTS22 Art.16 (6) ("other") Entitlement (rights) Warrants RWI*** RTS22 Art.16 (5).d ("index derivatives") Entitlement (rights) Warrants RWM*** RTS22 Art.16 (6) ("other") Entitlement (rights) Mini Future Certificates RFB*** RTS22 Art.16 (5).c ("basket derivatives") Entitlement (rights) Mini Future Certificates RFS*** RTS22 Art.16 (5).a ("equity derivatives") Entitlement (rights) Mini Future Certificates RFD*** RTS22 Art.16 (5).b ("debt derivatives") Entitlement (rights) Mini Future Certificates RFT*** RTS22 Art.16 (6) ("other") Entitlement (rights) Mini Future Certificates RFC*** RTS22 Art.16 (6) ("other") Entitlement (rights) Mini Future Certificates RFI*** RTS22 Art.16 (5).d ("index derivatives") Entitlement (rights) Mini Future Certificates RFM*** RTS22 Art.16 (6) ("other") Depositary Receipts on Entitlement (rights) Entitlements RD**** RTS22 Art.16 (6) ("other") Entitlement (rights) Miscellaneous RM**** RTS22 Art.16 (6) ("other") Listed options Baskets O**B** RTS22 Art.16 (5).c ("basket derivatives") Listed options Stock-equities O**S** RTS22 Art.16 (5).a ("equity derivatives") Listed options Debt O**D** RTS22 Art.16 (5).b ("debt derivatives") Listed options Commodities O**T** RTS22 Art.16 (6) ("other") 34