Publication of the User Guide allowing CSDs to submit the settlement fails reporting as per Article 7 of the Central Securities Depository Regulation

(1)USER GUIDE CSDR 7

(1)Restricted Version: diffusée 1/23 CSDR 7

(1)CONTENTS

5. Introduction 1.1 Reporting obligations 1.2 Objectives of this document 1.3 Useful/reference documents CSDR art 7 reporting principles 2.1 Information to be reported 2.2 Reporting and submission periods CSSF reporting principles 3.1 CSSF system overview 3.2 Authentication 3.3 SFRREP file structure 3.4 Validation of the SFRREP file 3.5 File resubmission and cancellation 3.6 Feedback files 3.7 Test platform 3.8 Production platform Reporting entities obligations Contact information 3 3 3 4 5 5 5 6 6 7 11 15 19 20 22 22 22 22 CSDR 7

(1)2/23 CSDR 7

(1)1. Introduction According to Article 7

(1)of CSDR, for each securities settlement system (SSS) it operates, a Central Security Depository (CSD) shall establish a system that monitors settlement fails of transactions in financial instruments referred to in Article 5

(1)of CSDR. It shall provide regular reports to the CSSF, as to the number and details of settlement fails and any other relevant information, including the measures envisaged by CSDs and their participants to improve settlement efficiency. Those reports shall be made public by CSDs in an aggregated and anonymised form on an annual basis. CSSF shall share with ESMA any relevant information on settlement fails. 1.1 Reporting obligations Articles 13 to 15 of the RTS (EU) 2018/1229 on Settlement Discipline provide additional details on the information to be provided to the National Competent Authority (NCA) of each CSD. CSD must monitor the volume and value of SF as well as collect information to be provided to their respective NCA. In addition, CSD must establish procedures with their participants having the most significant impact on their Securities Settlement System to identify the reasons for the SF that occur. The information related to Annex I (Table 1 and 2) of ESMA’s RTS is a monthly reporting to be provided by the CSD to their respective NCA on the 5th business day of the following month. The information related to Annex II of ESMA’s RTS is a yearly reporting to be provided by the CSD to their respective NCA by the 20 January of each year. The information related to Annex III of ESMA’s RTS is information to be disclosed to the public by CSD on their website on a yearly basis. 1.2 Objectives of this document This document describes the reporting principles to be used by the CSDs in order to report activity to the CSSF as the NCA for Luxembourg. The information detailed herein relates to: • • • • Reporting obligations including the description of the details to report Technical overview of the reporting system Data and file format of the reports Exchange and encryption protocols CSDR 7

(1)3/23 Any instruction given by the CSSF in this note is based on the aforementioned legal framework and the technical reporting instructions published by ESMA. 1.3 Useful/reference documents Date Reference Document Author 2014/08/28 REGULATION (EU) No 909/2014 OF CSDR European THE EUROPEAN PARLIAMENT AND Commission OF THE COUNCIL of 23 July 2014 2018/09/13 COMMISSION DELEGATED SDR European REGULATION (EU) 2018/1229 of Commission 25 May 2018 2020/08/24 COMMISSION DELEGATED SDR – Postponement European REGULATION (EU) 2020/1212 of 8 to 01/02/2021 Commission May 2020 2021/01/27 COMMISSION DELEGATED SDR – Postponement European REGULATION (EU) 2021/70 of 23 to 01/02/2022 Commission ESMA Website ESMA October 2020 Technical reporting instructions csdr article-7 settlement fails reporting csdr7 settlements fails xml schema ESMA Website - ESMA xml schema 2022/01/11 Circular CSSF 22/792 Guidelines CSSF Application of the Guidelines of the European Securities and Market Authority on Settlement Fails Reporting under Article 7 of CSDR (ESMA70-156-4717) CSDR 7

(1)4/23

1. CSDR art 7 reporting principles 2.1 Information to be reported Please refer to the • Regulation (EU) No 909/2014 of the European Parliament and of the Council of 23 July 2014 on improving securities settlement in the European Union and on central securities depositories and amending Directives 98/26/EC and 2014/65/EU and Regulation (EU) No 236/2012 and • Commission Delegated Regulation (EU) 2018/1229 of 25 May 2018 supplementing Regulation (EU) No 909/2014 of the European Parliament and of the Council with regard to regulatory technical standards on settlement discipline. The information to be reported is described in Articles 13 to 15 of the SDR and further detailed in the annexes of ESMA’s RTS. 2.2 Reporting and submission periods The reporting and submission periods are the following ones: • • for monthly settlement fails reports: o reporting periods will be full calendar months (e.g. 01-Jan to 31-Jan, etc.), with the possible exception of the first monthly report covering the period from the date of entry into force of the Commission Delegated Regulation (EU) 2018/1229 1 or unless a CSD has just started its activity during the respective month (in which case it will only cover the business days since it was authorised under CSDR). o CSDs must submit monthly reports to the CSSF by the fifth business day of the following month. for annual settlement fails reports: o reporting periods will be full years (e.g. 01-Jan-2020 to 31-Dec-2020), with the exception the first annual report covering the period from the date of entry into force of the Commission Delegated Regulation (EU) 1 According to the Commission Delegated Regulation (EU) 2018/1229, as amended by Commission Delegated Regulation (EU) 2021/70, the first monthly reports should cover the period from 01 Feb
2. CSDR 7

(1)5/23 2018/1229 1 or unless a CSD has started its activity during the respective year (in which case it will only cover the months since itwas authorised under CSDR). CSDs must submit annual reports to the CSSF by 20 January of each year.

1. CSSF reporting principles 3.1 CSSF system overview The CSSF’s information system collects all the reports submitted by the CSDs It is up to the submitter to monitor transmission correctness. Feedback files are systematically generated and sent by the CSSF in response to each SFRREP received. Within the CSSF, the SFRREP is processed as follows:
7. File collection Validation rules control (transmission and format validation) Generation and sending of the CSSF feedback file to the concerned entities, gathering results from validation [SFRFDB] Transfer of the SFRREP to ESMA following ESMA’s rules Reception of the ESMA’s feedback Transfer of the ESMA’s feedback to the concerned entities [SFRFBH] The CSSF’s information system collects and routs data using XML/ZIP files (the xml file will be compressed and sent as a .zip). CSDR 7

(1)6/23 A S3 (simple storage service) solution is used by the CSSF for the file exchange. S3 is an object storage service through a web service interface. S3 stores data as objects within buckets. An object is a file and any metadata that describes the file. A bucket is a container for objects. Each entity will be linked to one bucket divided into two folders: - submission: for the reporting - feedback: for the feedback files Bucket names can consist only of lowercase letters, numbers, dots (.), and hyphens (-). In order to access CSSF S3 system one needs the access key and the secret key provided in the authentication phase. The related urls are available on the Test platform chapter for the Validation environment and the Production platform chapter for the Production environment. 3.2 Authentication Please find below key information on the eDesk enrolment process which is a prerequisite for any use of the CSSF system. Therefore, unless you already have an eDesk user account, we invite you to enrol. Context information • To be able to set up their account, every eDesk user needs a valid LuxTrust certificate which is used for identification and authentication purposes. The certificate can either be private or professional and any LuxTrust Necessary actions 1. Ensure to have a LuxTrust certificate. If necessary, information on how to order a LuxTrust certificate can be found in chapter 2 of the eDesk Authentication User Guide. CSDR 7

(1)7/23 product (token, smartcard, app,…) can be used.

1. Go to the eDesk home page, click on “Log in” in the right upper corner, then, click on “Log in with LuxTrust” and create your eDesk account. Further information can be found in chapter 4.1 of the eDesk Authentication User Guide. • Once a user account is created, it has to be linked to the entity/entities the user is working for.
2. Once you have created your eDesk account, start a “New entity link request” as explained in chapter 4.2.2 of the eDesk Authentication User Guide. Even if you would like to apply to become advanced user, you have to start a “new entity link request” first. • The “New entity link requests” are treated (accepted or rejected) by an advanced user of your company.
3. If your firm has not yet an advanced • As a consequence, each entity using eDesk needs (at least) one advanced user. Please note that it is possible to have multiple advanced user roles per audit firm. • To become an advanced user, the candidate has to send a “New advanced user request” including a mandate and some accompanying documents to the CSSF via the eDesk portal. The documents will be verified at the CSSF and the advanced user will be validated (or rejected). • In CSDR7, particular actions and rights are restricted to specific roles within the entity. These roles are also managed by the advanced user(s). An overview of the specific rights assigned to the different roles can be found in chapter 4.3.5 of the eDesk Authentication User Guide user or if the firm wants to set-up additional advanced user roles , it should designate (at least) one and the latter should start a “New advanced user request”. The exact application procedure is described in chapter 4.2.3 of the eDesk Authentication User Guide.
4. The advanced user has to approve (or reject) the “new entity link requests” as explained in chapter 4.3 of the eDesk Authentication User Guide.
5. The advanced user should assign specific roles to the according participants of this phase. See chapter 4.3.5 of the eDesk Authentication User Guide for how to proceed. You can find the eDesk Authentication User Guide on the eDesk home page. Once authentication done, the advanced user can give the specific IT Expert role to someone of his company: CSDR 7

(1)8/23 Choose a user first by using the magnify glass Then choose the IT Expert role in the list of roles Save The IT Expert can access the IT management console. The console allows managing the access of the technical user to the S3 system. PRODUCTION link : https://edesk.apps.cssf.lu/edesk-itmgt Click on the link in order to get here: CSDR 7

(1)9/23 Click the Create access button You have now a new access granted: Click on this new access, you will get on the page with the S3 connection credentials Save the information provided (bucket, access key, secret key). In order to copy the secret key, press the eye on the right side of the screen. And pay attention to the message: the secret key can only be viewed once, in case of loss you will need to reset your credentials. If needed, you can also revoke your access. You can now use the credentials in order to access the S3 module. In S3 you will use: CSDR 7

(1)10/23 • The submission folder to upload files in .zip format • The feedback folder to retrieve feedbacks Any S3 compatible client can be used to upload and download files manually and any S3 compatible SDK can be used to automate it. For example, MinIO offers both : SDK and a command line client , but some GUI client like FileZilla Pro should also be compatible. 3.3 SFRREP file structure 3.3.1 Business Application header The Business Application Header (BAH) is a header that has been defined by the ISO 20022 community that can form part of an ISO 20022 business message. Specifically, the BAH is an ISO20022 message definition (head.001.001.01) which can be combined with any other ISO20022 message definition to form a business message. The purpose of the BAH is to provide a consistent and predictable way for this data to be conveyed with the message, regardless of implementation factors such as the choice of network. The use of the BAH in SFRREP is mandatory. The below table presents the list of mandatory elements of the BAH that should be included in the message and the specific Business Message Identifier. Usage in Status Advice Element Description Usage in Reporting Message (i.e. Feedback) Message (i.e. Report) – just for information purposes From To The sender of the <Fr>.<OrgId>.<Id> <Fr>.<OrgId>.<Id><.< message <.<OrgId>.<Othr>. OrgId>.<Othr>.<ID> <ID> Ex : LU Ex: EU The recipient of <To>.<OrgId>.<Id> <To>.<OrgId>.<Id><.< the message <.<OrgId>.<Othr>. OrgId>.<Othr>.<ID> <ID> Ex : EU Ex: LU <BizMsgIdr> <BizMsgIdr> Free text zone, max Same as Reporting 35 char Message Business Unambiguously Message identifies the Identifier Business Message to the MessagingEndpoin t that has created the Business Used as unique identifier for each report Message. CSDR 7

(1)11/23 Message Identification of The identifier of The identifier of relevant Definition the type of the relevant ISO 20022 ISO 20022 message Identifier message (ISO message (using base (using base name only) 20022 message name only) of the of the generated identifier) reporting message feedback file, i.e., auth.031.001.01 Creation Date and time Date when this Date and time in ISO 8601 format. Business Message was created Related Specifies the Unused for the The copy of the BAH of Business reporting message. the referred data Application Header of the Business Message Used only for the feedback message. message (it allows to link the status advice and the reporting message) to which this Business Message relates. Note: For a corrupted file (that cannot be unzipped for instance) the feedback cannot retrieve the BizMsgIdr. In that specific case the BizMsgIdr du feedback will return the filename elements concatenated, without the “-” and the “_”. The Business Application Header xsd is the one provided by ESMA : CSDR_Settlement_Fails-_Article_7_Reporting_CSDR-_Settlement_Fails_Article_7_Reporting_BusinessApplicationHeaderV01_hea_20200205_1052_iso15enriched.xsd 3.3.2 Business File header Each ISO 20022 business message shall be sent together with the Business Application Header (BAH) message. These are separate messages and should be packaged within an additional structure, referred to as “envelope”, in order to constitute a single XML file. The Business File Header is a simple XML file that encapsulates the BAH and the Reporting message or Status Advice message. The Business File Header XSD is the one provided by ESMA: head.003.001.01.xsd 3.3.3 SFRREP message definition CSDR7 uses ISO 20022 auth.100.001.01 / auth.101.001.01 message definitions base/ derived messages and the XSD are the ones provided by ESMA : CSDR 7

(1)12/23 • CSDR-_Settlement_Fails-_Article_7_Reporting_CSDR-_Settlement_Fails_Article_7_Reporting_SettlementFailsMonthlyReportV01__20200205_1052_iso15enriched.xsd for the monthly reports • CSDR-_Settlement_Fails-_Article_7_Reporting_CSDR-_Settlement_Fails_Article_7_Reporting_SettlementFailsAnnualReportV01_a_20200205_1052_iso15enriched.xsd for the yearly reports The Monthly Settlement Fails report consists of three main reporting sections: o Reporting header: Within this section the reporting entity specifies the parameters of the report (i.e. Creation date and time, reporting period, currency, report status), as well as the identification details of the SSS that the report concerns. o Monthly aggregates: Within this section the reporting entity specifies the aggregated monthly volume and value of settled, failed, total of settlement instructions during the period covered by the report. o Daily data: Within this section, the reporting entity specifies the daily data volume and value of settled, failed, total of settlement instructions during the period covered by the report, broken down by Type of financial instrument / Type of transaction / Intra or Cross CSD / Type of settlement instruction / Type of settlement fail. The Annual Settlement Fails report consists of two main sections: o Reporting header: Within this section the reporting entity specifies the parameters of the report (i.e. Creation date and time, reporting period, currency, report status), as well as the identification details of the SSS that the report concerns o Annual aggregate: Within this section the reporting entity specifies the aggregated annual volume and value of settled, failed, total settlement instructions during the period covered by the report All elements of both report section must be filled-in. Both reports are mandatory and must be submitted even in the event when no settlement fails during the period covered by the report. In this particular case 0 values should be used to fill in the reports. CSDR 7

(1)13/23 3.3.4 Filenaming convention All files must be submitted to the CSSF as per the following naming convention: TYPDIR-EIIIIIIII-FNNNNNNNN-YYYY-MM- Seq.ext Code Meaning Structure Authorized values TYP Reporting type Char

(3)‘SFR’ for “Settlement Fails Reporting” DIR Direction Char

(3)‘REP’ for Report file sent to the CSSF - Separator Char

(1)Constant ‘-’ E Entity type of the Char

(1)Usual entity types, e.g. “&” for DCT Identification Number 00000001…99999999 number of the

(8)technical agent IIIIIIII sender - Separator Char

(1)Constant ‘-’ F Entity type Char

(1)Constant - the identification given by the CSSF for the entity has to be used. Usual entity type is “&” for DCT NNNNNN Entity Number( NN identification 8) 00000001…99999999 number - Separator Char

(1)Constant ‘-’ YYYY Year of the Number( Year of the reporting reporting 4) - Separator Char

(1)Constant ‘-’ MM The month of the Number( 01…12 for the monthly files reporting 2) - Separator Char

(1)Constant ‘-’ Seq Sequence number Number( Number with leading zero. Used for 4) determination of the order of 00 for the yearly files processing and guarantees uniqueness .ext Extension Char

(4)‘.zip’ for the REP file containing a single ‘.xml’ file SFRREP-&00000001-&00000001-2020-10-0001.xml for monthly file CSDR 7

(1)14/23 SFRREP-&00000001-&00000001-2020-00-0001.xml for yearly file Xml files must be zipped before sending. 3.3.5 File sequence management Sequences are defined as a number of 4. Every new sending must increment the sequence number by one (amendment or cancelation for example). Example: NEWT : SFRREP-&00000001-&00000001-2020-10-0001 (ACPT) AMND : SFRREP-&00000001-&00000001-2020-10-0002 (ACPT) CANC : SFRREP-&00000001-&00000001-2020-10-0003 (ACPT) NEWT : SFRREP-&00000001-&00000001-2020-10-0004 A rejected file must be sent again with the same sequence number. NEWT : SFRREP-&00000001-&00000001-2020-10-0001 (RJCT) NEWT : SFRREP-&00000001-&00000001-2020-10-0001 (ACPT) AMND : SFRREP-&00000001-&00000001-2020-10-0002 (RJCT) AMND : SFRREP-&00000001-&00000001-2020-10-0002 (ACPT) 3.4 Validation of the SFRREP file The SFRREP file goes through a set of mandatory and harmonised validation rules. CSDs will receive two feedback files: the first one [CSSF feedback] concerns the integration of the report in the CSSF system after technical controls the second one [ESMA feedback] concerns the integrations of the report in the ESMA’s system. This feedback will also be sent by the CSSF to the sender (see schema) Any report that does not comply with the validation rules is automatically rejected by the CSSF. The respective rejection codes and reasons are indicated below. A report can be rejected for two main purposes: • File validation Transmission error: for example, “The file cannot be decompressed” [CSSF feedback] Format error: for example “The file structure does not correspond to the XML schema” [CSSF feedback] CSDR 7

(1)15/23 • Content validation: related to business rules [ESMA feedback] and some light CSSF controls that can be raised in the CSSF feedback. CSDs must ensure that all feedback files are properly analysed and that any rejected reports are corrected and resubmitted to the CSSF. 3.4.1 CSSF controls Hereafter the list of the controls performed by the CSSF: Control Error Error message Correction code Transmission validation All files on CSDR7 are FIL- The file cannot Ensure the file is compressed in zip format. 101 be a zip. Create a decompressed. .zip from a xml When treating a file, the first step is the decompression of file, do not just the zip file. This error is change the file returned by the system if extension the file cannot be decompressed. Once the file is FIL- The file contains Ensure you decompressed, CSDR7 102 no or more than create a .zip 1 XML file. based on a checks that the decompressed container zip single xml file file contains exactly one XML file. This error is returned by the system when no XML or more than one file is found. The system checks that the FIL- The name of the There are filename and the version of 103 XML file is not differences the XML file and of the ZIP consistent with between the xml file are identical. This error the name of its and the zip file is returned by the system container ZIP names. when any of the file. aforementioned fields is not identical in the ZIP and XML filenames. Tip : if you need to change the .zip file name, change first the xml file name and then zip it again. CSDR 7

(1)16/23 Validate that the filename FIL- The file name Please check the complies with the filenaming 113 does not comply File naming with the file convention and naming adapt. The convention. indication refers convention. to the sequence number also Format Validation The ISO 20022 Message FIL- The ISO 20022 Check of the Identifier must refer to the 104 Message Message agreed schema used by the Identifier is not identifier: The system. valid. ISO 20022 Message Identifier must refer to the agreed schema used by the system. Example: <MsgDefIdr>aut h.100.001.01</ MsgDefIdr>for the monthly files <MsgDefIdr>aut h.101.001.01</ MsgDefIdr> for the annual files Validate that the file sent fits FIL- The file structure Check against to the corresponding XML 105 does not the xsd schema schema. correspond to the XML schema Validate that the file sent fits FIL- to the corresponding XML 105 schema. Error during XML schema validation. The From and/or the To value is not correct Check the BAH and correct the values of the “From” and/or “To” xml tags CSDR 7

(1)17/23 When a file is received, the FIL- File has already Check the name system checks whether a file 107 been submitted of the last sent once file and increase with the same filename has already been submitted to the sequence if CSSF. necessary (pay attention to the CSSF and ESMA feedback) Data Content Validation MSF – The <RptgPrd>.<FrDt> 001 must be in the YYYY-MM-01 or format ASF - The reporting The Reporting From date is not valid. “From date” must follow the expected format 001 The <RptgPrd>.<ToDt> must be in the YYYY-MM-DD MSF – 002 format, where DD must be or the last calendar day of the ASF - MM month. The reporting The Reporting To date is not valid. “To date” must follow the expected format 002 For each CSD a specific LEI MSF – The combination Correct the LEI, is expected 009 of CSD name that must and LEI is not correspond to correct. the reporting Or ASF - entity 008 For the given annual report, at least one monthly report ASF - has already been integrated 009 at the CSSF There is no At least one received Monthly monthly report Settlement Fails must be report that accepted by corresponds to CSSF and ESMA the submitted before Annual submitting an Settlement Fails annual report report. Verify that the <BizMsgIdr> has not already been submitted. LUX 006 The Correct the <BizMsgIdr> identifier that was already must be unique submitted. CSDR 7

(1)18/23 Note 1 : Regarding error code FIL-105, it has to be noted that this error type includes a wide range of errors related to a single report. The result of the XML validation is a list of errors per report generated by the XML parser. Due to the xml structure of the feedback file it is not possible to include all of them (the field “Desc” is limited to 350 Characters). Note 2: if the filename is too exotic, the system will not take the file into account, it will be moved into the Feedback folder without any other control. 3.4.2 Content validation Except for a few “light” content controls defined in the table above, CSSF does not intend to do content validation. Business rules are validated by ESMA’s CSDRS system. Please refer to the ESMA’s documentation. 3.5 File resubmission and cancellation 3.5.1 Resubmission for correction purposes A monthly or annual settlement fails report can be re-submitted, allowing the submitting entity to correct potential erroneous data. To re-submit, all file and content validation rules should be respected, with the following specifics: o The filename updating the data of an already submitted report must be identical to the filename of the previous version of the report, but attention to increase the value of the sequence number by 1. o The XML should include the value AMND under the respective status field : <RptSts> xml tag. 3.5.2 Resubmission after rejection After a rejection, the file must be resubmitted with the same report status (NEWT, AMND or CANC). Errors provided in the feedback file must be corrected and the sequence number will be the same. 3.5.3 Report cancellation A monthly or annual settlement fails report will be possible to be cancelled, allowing the submitting entity to correct potential erroneous data. To cancel: o The name of a file cancelling the data of an already submitted report must be identical to the filename of the previous version of the report, but attention to increase the value of the sequence number by 1. CSDR 7

(1)19/23 Under the respective status field, the XML should include the value CANC : (<RptSts>) xml tag. o 3.6 Feedback files 3.6.1 Filenaming convention A CSDR feedback file (SFRFDB) is provided by the CSSF after technical validation for each SFRREP reporting file received. ESMA’s feedback (SFRFBH) is recovered by the CSSF and then made available for the submitting entities. ESMA applies data content validation controls. Please refer to ESMA’s documentation. Below are the structure and details of the feedback message. ESMA’s and CSSF’s feedback messages have the same structure. All files transmitted by the CSSF as per the following naming convention: Code Meaning Structure Authorized values TYP Reporting type Char

(3)‘SFR’ for “Settlement Fails Reporting” DIR Direction Char

(3)‘FDB’ for CSSF feedback ‘FBH’ for ESMA feedback - Separator Char

(1)Constant ‘-’ E Entity type of the Char

(1)Usual entity types, e.g. “&” for DCT Identification Number 00000001…99999999 number of the

(8)technical agent (sender) IIIIIIII sender - Separator Char

(1)Constant ‘-’ F Entity type Char

(1)Constant - the identification given by (reporting entity) the CSSF for the entity has to be used. Usual entity type is “&” for DCT NNNNNN Entity Number( NN identification 8) 00000001…99999999 number (reporting entity) - Separator Char

(1)Constant ‘-’ CSDR 7

(1)20/23 YYYY Year of the Number( Year of the reporting reporting 4) - Separator Char

(1)Constant ‘-’ MM The month of the Number( 01…12 for the monthly files reporting 2) - Separator Char

(1)Constant ‘-’ Seq Sequence number Number( Number with leading zero. Used for 4) determination of the order of 00 for the yearly files processing and guarantees uniqueness .ext Extension Char

(4)‘.zip’ for the file containing a single ‘.xml’ file CSSF feedbacks: SFRFDB-&00000001-&00000001-2020-10-0001.xml for monthly file SFRFDB-&00000001-&00000001-2020-00-0001.xml for yearly file ESMA feedbacks: SFRFBH-&00000001-&00000001-2020-10-0001.xml for monthly file SFRFBH-&00000001-&00000001-2020-00-0001.xml for yearly file 3.6.2 Explicit processing statuses The CSSF reports an explicit status for each submitted report. The feedback file may report one of the following statuses: • o o o o o o • Rejected (RJCT): the report is flagged as rejected when: zip file does not contain one single XML file zip file cannot be opened or decompressed the contained xml file does not have the same filename as the container zip file (except timestamp and extension) the report does not use the same XML Schema as the one used by the system the report uses exactly the same filename previously used the report cannot be validated against the XML Schema, etc Accepted (ACPT): the report is flagged as accepted when it passes successfully all validation checks CSDR 7

(1)21/23 3.7 Test platform A testing phase is highly recommended before the Go-Live. As a reminder, CSDs are not allowed to use the production environment to test their systems. VALIDATION url : https://s3.val.apps.cssf.lu For security reasons public IPs must be provided to the CSSF, in order to whitelist them. 3.8 Production platform Production url : https://s3.apps.cssf.lu

1. Reporting entities obligations Data quality Submitting entities are strongly advised to use the XML schemes to generate and validate their files before submitting them to the CSSF. Files must be validated against the XML schema provided by ESMA. Review the feedback files and correct the rejected reports CSDs must ensure that all feedback files are properly analysed and that any rejected reports is corrected and resubmitted to the CSSF. Feedback process is an automatic exchange between systems using official transmission channels. CSDs must resend their corrected files using the same automatic process (based on the official xml schemes).
2. Contact information In case of questions, please contact: • IT_division_analyse@cssf.lu for the technical questions and • market.infrastructures@cssf.lu for the business questions. CSDR 7

(1)22/23 Commission de Surveillance du Secteur Financier 283, route d’Arlon L-2991 Luxembourg (+352) 26 25 1-1 direction@cssf.lu CSDR 7

(1)www.cssf.lu Restricted Version: diffusée 23/23