Published on 24 April 2025 Email this Share this on LinkedIn Share this on Facebook Communiqué Guidance for correction of most frequent issues identified in the submitted Registers of Information under DORA Following the end of their user acceptance testing (UAT) of the reception of the Register of Information (RoI), the ESAs have published ‘Observations from testing of RoI reporting to the ESAs. Key common issues identified’, a document listing the key common issues identified during this phase. Given that the CSSF is receiving the RoI from financial entities under its supervision from 1 April on, the CSSF also compiled a guide aiming at assisting financial entities in resolving issues detected during the validation checks of the submitted RoI by the CSSF and the ESAs. This guide shall be read in conjunction with the above ESA observations. The CSSF guide is not intended to be exhaustive but covers the most common issues encountered during the validation checks of the received registers. It is a living document which will be updated on a regular basis. The CSSF advises financial entities to consult this guide before contacting our helpdesk. In addition, the CSSF would like to inform the few entities who have not yet submitted their RoI, that they are still required to do so as soon as possible. In this context, the CSSF raises the attention to a guidance document published on 7 April and updated today. This document clarifies whether the submission of a RoI by Luxembourg-based financial entities subject to DORA and supervised by the CSSF or the ECB is expected to be sent to the CSSF on a consolidated or individual basis, or to another competent authority as part of the consolidated register of its parent company. We advise financial entities to consult this document in case of doubt. 7 April 2025 - Updated on 24 April 2025 Register of information: Guidance tables on submission to the CSSF Guidance allowing financial entities to identify the National Competent Authority to which their register of information has to be submitted. CSSF guidance PDF (86.42Kb) 24 April 2025 CSSF guide concerning the submission of DORA Register of information Guidance related to the composition and the content of a register of information. Compilation of information from different ESA sources. Technical document PDF (604.24Kb) Main topic: ICT and cyber risk – for DORA entities Relevant for Central Securities Depositories (CSDs) Credit institutions Crowdfunding service providers Crypto-Assets Service Providers (CASPs) Data Reporting Service Providers (DRSPs) Investment firms Investment fund managers Issuers of Tokens Payment institutions/electronic money institutions/AISPs Pension fund Register of information: Guidance tables on submission to the CSSF The summary tables below are designed to help Luxembourg-based financial entities falling under the scope of the DORA regulation and supervised by the CSSF or the ECB (FE) to determine, whether a register of information needs to be communicated to the CSSF and based on which consolidation level, or whether it needs to be submitted to another competent authority (table 1) as part of the consolidated register of its parent company. In case it is to be submitted to the CSSF on a consolidated basis, the second table provides details for which entities the information needs to be included in the register. These tables should identify a number of cases, without claiming to be exhaustive. In case of doubt, financial entities may always contact their supervision departments. Table 1: Obligation of submission and level of consolidation The Financial Entity (FE) is not part of a group FE Individually To CSSF The FE is the EU parent of a group of FEs FE Supervised by the CSSF FE supervised by the ECB FE Consolidated To CSSF FE Consolidated To ECB* The FE is a subsidiary within a group of FEs whose parent company (PC) is not in the EU/EEA FE Individually To CSSF The FE is a subsidiary within a group of FEs whose EU PC is established in Luxembourg The FE is a subsidiary within a group of FEs whose PC in the EU is established in a Eurozone country The FE is a subsidiary within a group of FEs whose PC in the EU is established in an EU/EEA country outside the Eurozone PC is supervised by the CSSF PC is supervised by the ECB PC is not supervised by the CSSF or ECB PC is supervised by the ECB PC is supervised by an NCA from the same sector PC is supervised by an NCA from the same sector PC Consolidated To CSSF PC Consolidated To ECB* FE Individually To CSSF PC Consolidated To ECB* PC Consolidated To same sector NCA PC is supervised by an NCA from another sector FE Individually To CSSF PC Consolidated To same sector NCA PC is supervised by an NCA from another sector FE Individually To CSSF * The ECB asks that the information be submitted at the highest level of consolidation within the Single Supervisory Mechanism (SSM) considering the prudential scope of consolidation. In accordance with the DORA FAQs No 5, if the prudential scope of consolidation were to encompass financial entities within the meaning of DORA that belong to another (non-banking) financial sector, the register of information of this entity would therefore be encompassed in the consolidated/sub-consolidated RoI of the group and should consequently be reported to the ECB at consolidated level. Table 2: Identification of subsidiaries whose information must be included in the consolidated register to submit to the CSSF (submission of an EU parent entity established in Luxembourg under CSSF supervision) Does the subsidiary belong to the same Where is the subsidiary located? sector? Yes Yes Yes No In Luxembourg In the EU or EEA Outside the EU or EEA In Luxembourg No No In the EU or EEA Outside the EU or EEA REGISTER OF INFORMATION: GUIDANCE TABLES ON SUBMISSION TO THE CSSF Is the subsidiary supervised by the Should the consolidated RoI include information about CSSF? this subsidiary? Yes No No Yes No No No Yes Yes No Yes No No No CSSF guide concerning the submission of DORA Register of information Version 1.0 – 23/04/2025 TABLE OF CONTENTS 1. Introduction ............................................................................................................... 4 2. General information .................................................................................................... 4 2.1 Identification of financial entities and their third-party service provider ............................. 4 2.1.1 Type of Identifier .................................................................................................. 4 2.1.2 Composition of a Legal Entity Identifier (LEI) ............................................................ 5 2.1.3 Composition of a European Unique Identifier (EUID) .................................................. 5 2.1.4 GLEIF / BRIS database .......................................................................................... 5 2.2 Difference between Warning and Error messages............................................................ 5 3. Structure of the Register of Information ........................................................................ 6 3.1 Naming convention of the .zip file ................................................................................. 6 3.2 Content of the .zip file ................................................................................................. 6 3.2.1 Sub-folder META-INF ............................................................................................. 7 3.2.2 Sub-folder reports ................................................................................................. 7 3.2.2.1 report.json ........................................................................................................ 8 3.2.2.2 FilingIndicators.csv ............................................................................................. 9 3.2.2.2 parameters.csv .................................................................................................. 9 3.3 UTF-8 encoding ........................................................................................................ 10 4. Content of a .csv file ................................................................................................. 10 4.1 Composition of a .csv file ........................................................................................... 10 4.1.1 Header of a .csv file............................................................................................. 10 4.1.1.1 Special case: Table B_03.03 .............................................................................. 11 4.1.1.2 Special case: Table B_02.03 and B_03.01 ........................................................... 11 4.1.1.3 Special case : Table B_06.01 ............................................................................. 12 4.3 Order of the columns ................................................................................................ 12 5. .csv files .................................................................................................................. 13 5.1 Data Field types ....................................................................................................... 13 5.1.1 String (varchar) ................................................................................................. 13 5.1.2 Date .................................................................................................................. 13 5.1.3 Boolean ............................................................................................................. 13 5.2 Enumerated type (Close set of options) ....................................................................... 14 5.3 Mandatory data fields ................................................................................................ 14 5.4 Key fields ................................................................................................................ 15 5.4.1 Identification of Key Fields ................................................................................... 15 5.4.2 Identical Key values on open tables ....................................................................... 15 5.5 Missing data for Mandatory / Key fields ....................................................................... 16 5.5.1 Missing or unknown LEI ....................................................................................... 16 5.5.2 Country key fields ............................................................................................... 16 6. Foreign Key Violations ............................................................................................... 17 6.1 Foreign Key Violation - across tables .......................................................................... 17 6.2 Foreign Key Violation - self reference ......................................................................... 17 7. Validation Rules........................................................................................................ 18 7.1 DPM Business Validation Rules ................................................................................... 18 2/24 7.2 Validation Rules related to LEI / EUID ......................................................................... 23 3/24 CSSF guide concerning the submission of DORA Register of information Version 1.0 – 23/04/2025 1. Introduction The aim of this guide consists in assisting financial entities in resolving issues detected during the validation checks of the submitted DORA registers of information (RoI). This guide shall be read in conjunction with the ‘Observations from testing of RoI reporting to the ESAs. Key common issues identified’ document published by the ESA on 16 April 2025 (Link). This guide is not intended to be exhaustive but covers the issues most commonly encountered in the validation checks of the RoI received during the first year of submission. It provides information based on current best knowledge and will be updated regularly. As it is evolving over time, the CSSF advises you to consult the latest version of this guide before contacting our helpdesks. In case of any question, please feel free to contact by mail the different helpdesks of the CSSF: Any technical issues, for instance with the on-boarding to CSSF eDesk platform shall be addressed to edesk@cssf.lu Any question related to the content of the register of information shall be addressed to ICTRiskSupervision@cssf.lu 2. General information 2.1 Identification of financial entities and their third-party service provider 2.1.1 Type of Identifier • Financial entities are identified under DORA via a Legal Entity Identifier (LEI). • Third-party service providers located inside the EU are identified under DORA via a Legal Entity • Third-party service providers located outside the EU are identified under DORA via a LEI. Identifier (LEI) or a European Unique Identifier (EUID). 4/24 2.1.2 Composition of a Legal Entity Identifier (LEI) • A LEI consists of a 20-character alphanumeric string. The first four characters identify the Local Operating Unit (LOU) that has issued the LEI whereas Characters 5 to 18 are the unique alphanumeric string assigned to the financial entity. The final two characters are checksum digits. 2.1.3 Composition of a European Unique Identifier (EUID) • The EUID has been introduced as a European standard alongside national business registers in 2017 by the European Commission. • Its composition is the following: 2.1.4 GLEIF / BRIS database • The ESA check the provided LEI or EUID against the GLEIF and BRIS databases. • In case the provided ID is not contained in both databases, a warning message will be displayed. • However, the submitted register will not be rejected. Please refer also to the Top Errors #5 (page 17), Top Error #9 (page 22) and Top Error #12 (page 25) in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. 2.2 Difference between Warning and Error messages This guide enumerates a certain number of requirements based on the published ITS on register of information (Link) and the technical specifications provided by the ESA (Link). In case a non-compliance of the RoI is detected during the analysis of its content, an error message is shown. In this case, the submitted RoI is rejected, and financial entities shall fix the detected error(
- s)and resubmit their register in due time to the CSSF, which will submit the register to the ESA. A warning message on the other hand indicates a detected non-compliance of the submitted register but without rejection. The financial entities may decide to fix the detected issue(
- s)and to re-submit their register to the CSSF. Any register re-submitted before end of May 2025 will be transmitted by the CSSF to the ESA. Examples of warning or error messages 5/24 Please refer also to the list of Top 20 error codes which may lead to the rejection of the register described on page 5 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. 3. Structure of the Register of Information • The register of information to be submitted to the CSSF is composed of different folders and files. Those folders and files are grouped inside a .zip file. • Only .zip files are accepted by the CSSF via its eDesk platform. • Any RoI communicated to the CSSF which is not a valid .zip file will be rejected. This is for instance the case for any file for which the file extension is changed to .zip. Other compressed files like for instance .7z files will be rejected. 3.1 Naming convention of the .zip file • The following naming convention has to be respected when submitting a register of information to the CSSF: LEI.IND_Country_Version_ReferenceDate_Timestamp.zip or LEI.CON_Country_Version_ReferenceDate_Timestamp.zip where: LEI is the LEI code of the reporting financial entity composed of 18 characters and numbers followed by two check digits CON or IND is the indication whether the file is being reported at consolidated (CON) or individual entity level (IND) Country is the two-letter ISO code of the country of the submitting entity Version is DORA010100 (constant for the reporting in 2025) ReferenceDate is 2025-03-31 for the first reporting in 2025 Timestamp is the timestamp when the reporting file was created: YYYYMMDDHHMMSS000 Examples: DUMMYLEI123456789012.CON_IT_DORA010100_DORA_2025-03-31_20250421141632000.zip DUMMYLEI123456789012.IND_LU_DORA010100_DORA_2025-03-31_20250421141632000.zip 3.2 Content of the .zip file Please refer also to the Top Error #10 described on page 23 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. • The main folder contained in the .zip file has the same name as the zip file but without the • The name of the folder is in uppercase .zip extension Example: Name of the .zip file: DUMMYLEI123456789012.IND_LU_DORA010100_DORA_2025-03-31_20250421141632000.zip 6/24 Name of the folder: DUMMYLEI123456789012.IND_LU_DORA010100_DORA_2025-03-31_20250421141632000 • The main folder contains two sub-folders ‘reports’ and ‘META-INF’ • The name of those two sub-folders must not be modified and are case-sensitive • Additional sub-folders are prohibited • Additional files at sub-folder level are prohibited A non-compliance with this rule leads to the rejection of the submitted register. 3.2.1 Sub-folder META-INF • The sub-folder ‘META-INF’ contains one file called ‘reportPackage.json’. • Any additional folder or file inside the sub-folder META-INF is prohibited • The filename of the ‘reportPackage.json’ is case sensitive • The ‘reportPackage.json’ file shall not be modified • Content of the ‘reportPackage.json’ file: A non-compliance with this rule leads to the rejection of the submitted register. 3.2.2 Sub-folder reports Please refer also to the Top Error #6 described on pages 18-19 and the additional information related to the Table.csv files on pages 27-28 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. 7/24 The sub-folder ‘reports’ contains: the different b_xx.xx .csv files corresponding to the table files the ‘FilingIndicators.csv’ file the ‘parameters.csv’ file the ‘report.json’ file Example : • Any additional folder or file inside the sub-folder is prohibited leading to the rejection of the submitted register • The sub-folder does not contain any .xls or .xlsx files • All filenames are case sensitive • The filename of the b_xx.xx.csv table files must be lower case e.g. b_01.01.csv • Financial entities do not need to include all b_xx.xx.csv files (for instance in case a financial entity has no branches, file b_01.03.csv is not required to be included in the sub-folder). In this particular case, financial entities have to ensure that the requirements in the below section ‘3.2.2.2 FilingIndicators.csv’ are respected. A non-compliance with this rule leads to the rejection of the submitted register. 3.2.2.1 report.json • The report.json file contained in the sub-folder ‘reports’ shall not be modified • Content of the ‘report.json’ file: A non-compliance with this rule leads to the rejection of the submitted register. 8/24 3.2.2.2 FilingIndicators.csv Please refer also to the Top Error #4 described on page 16 and the additional information related to the FilingIndicators.csv file on page 26 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. • Content of the ‘FilingIndicators.csv’ file: • The content of the ‘FilingIndicators.csv’ file shall not be modified. • Name of the file is case sensitive. • All lines except the header contain the Boolean ‘true’ even if the financial entity will not report a given template (for instance in case the financial entity has no branches, file b_01.03.csv is not required). A non-compliance with this rule leads to the rejection of the submitted register. 3.2.2.2 parameters.csv Please refer also to the Top Error #8 described on page 21 and the additional information related to the parameters.csv file on page 26 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. • Content of the ‘parameters.csv’ file: • The order of the header of the parameters.csv file is important - name first, value after • The second row shall start with ‘entityID,rs:’ followed by the LEI of the entity submitting the register and ‘.CON’ or ‘.IND’. In other words, the string shall be followed by the 24 first characters of the zip name. • The reference period specified in line 3 shall be the same that the one specified in the filename of the .zip file. For the 2025 submission, the reference date is set to ‘2025-03-31’. 9/24 3.3 UTF-8 encoding • All .csv and .json files shall be encoded in UTF-8 format. Files encoded in a different format (for instance ASCI) will be rejected. • In order to check whether a given .csv file is encoded in UTF-8 under Microsoft Windows, please open the file via notepad.exe. The following file has been encoded in UTF-8 format and will be accepted: The following file has been encoded in ANSI format and will be rejected: 4. Content of a .csv file 4.1 Composition of a .csv file • A .csv is composed of a header (first row) and the rows containing the value of the different data fields specified by the ITS on Register of information. 4.1.1 Header of a .csv file Please refer also to the Top Error #11 described on page 21 and the additional information related to the parameters.csv file on page 24 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. • The header of a .csv file contains a list of the different columns c0010, c0020, … • All columns in the header are separated via the comma symbol ‘,’ • All column names in the header are in lower cases and start with the letter “c” followed by 4 digits • No additional columns shall be added • The header of a .csv file does not contain an empty value 10/24 • The columns contained in a header are incremented by 10 (c0010, c0020, c0030, …) The Data Model for DORA RoI (Link) enumerates all the data fields defined in the ITS on register of information. Example: Template B.01.01 is composed of 6 different data fields: The header of the file b_01.01.csv will be: c0010,c0020,c0030,c0040,c0050,c0060 Examples of headers that will be rejected for file b_01.01.csv: Header Justification C0010,C0020,C0030,C0040,C0050,C0060 Columns shall start with the lowercase letter ‘c’ c0010,c0020,c0030,c0050,c0060 Missing column c0040 c0010,c0020,c0030,c0040,c0050,c0060,c0070 Column c0070 is impermissible, it does not exist in the data point model (DPM) c0010;c0020;c0030;c0040;c0050;c0060 Wrong separator, only a comma is accepted as separator b_01.01.c0010, b_01.01.c0020, b_01.01.c0030, Naming convention of the columns not b_01.01.c0040, b_01.01.c0050, b_01.01.c0060 respected 4.1.1.1 Special case: Table B_03.03 The file b_03.03.csv is the only template which contains a column ‘c0031’. The column name ‘c0031’ in table b_03.03 is not an error and should not be corrected. A ‘b_03.01.csv’ file containing header c0010,c0020,c0030 will be rejected. 4.1.1.2 Special case: Table B_02.03 and B_03.01 The Data Model for DORA RoI specifies that templates B.02.02 and B.03.01 have only two columns. 11/24 In the annotated table for DORA published by the ESA a third column was added to both templates so that files b_02.03.csv and b_03.01.csv shall both have the following header: c0010,c0020,c0030 4.1.1.3 Special case : Table B_06.01 The ESA noted in FAQ#46(U) that there is a numbering error in the numbering of the column codes in Template B_06.01 in the ITS published in the EU Official Journal. In particular, data field B_06.01.0050 is missing in the column codes, resulting in the data fields being assigned erroneous column codes. The ESA further noted that for reporting purposes, the data points included in the reporting technical package v4.0 for the ITS on the Registers of information should be considered. The data point model contains consecutive numbers of the data fields. Following the renumbering of the columns, the header of file b_06.01.csv shall be: c0010,c0020,c0030,c0040,c0050,c0060,c0070,c0080,c0090,c0100 4.3 Order of the columns Financial entities have to ensure that the number of columns contained in a .csv header corresponds to the ESA’s specification. The order of the columns however may vary e.g. they can come in any order. In this case, the financial entities have to ensure that the corresponding values follow the same order than the columns in the header. Example of two different b.01.01.csv files that are accepted: Example1: Example2: In both examples, column c0010 for instance contains the LEI of the financial entity and column c0020 its name. Example of a b.01.01.csv file that is rejected: 12/24 In this example column c0010 contains the LEI of the financial entity but column c0020 the value ‘2025-03-31’ instead of the financial entity’s name. 5. .csv files 5.1 Data Field types The “Data Model for DORA RoI” document (Link) published by the ESA lists the different types of the data fields contained in the register of information. For certain of those types, certain requirements shall be respected which are described hereunder: 5.1.1 String (varchar) In case the string value contains a separator ‘,’ then this string value must be quoted with double quotes “”. Example: “Bank, branch of Germany” 5.1.2 Date All dates must be specified in the format yyyy-mm-dd The following values do not respect the date format and will be rejected: Data field Justification 31-12-2025 Date format yyyy-mm-dd not respected 2025-31-12 Rejected as date is provided in yyyy-dd-mm format 2025/12/31 Separator ‘/’ not allowed 2025-01-31 00:00:00 Time must not be added to the date 5.1.3 Boolean • A Boolean type must be either true, false, 1 or 0. • The values ‘true’ or ‘false’ must be in lower case. Value Justification TRUE Rejected as not in lower case True Rejected as not in lower case 13/24 5.2 Enumerated type (Close set of options) • For certain data fields, the ITS on register of information (Link) provides a list of specific values that financial entities shall use and the type of those data fields is specified as ‘Closed of options’. Q&A#25 (Link) specifies that “The values to be reported in the drop-down data fields are explained in the ITS and these are the actual values in a human-readable format. However, for reporting purposes the values should be replaced by the codes provided in the data point model (DPM) preceding with prefix ‘eba_’ according to the filling rules. To help navigate all the codes associated with the values in the drop-down data fields, the ESAs prepared a mapping file providing all the values and their codes”. • Financial entities shall ensure that they chose a value from the corresponding drop-down list. Figure below shows the possible values for data field B.01.02.0040 in template B_01.02: • • Values from the drop-down list are prefixed by ‘eba_’. Financial entities shall ensure that they pick a value from a drop-down list associated to a given data field. In the above example, only the values ‘eba_CT:xxx’ from the above list are accepted for data field B.01.02.0040. An error message will automatically be raised in case a financial entity uses a value which is no contained in the drop-down list or uses a value from a different drop-down list. • Financial entities shall enter the complete value (for instance ‘eba_CT:x318’ and not only the value ‘x318’) 5.3 Mandatory data fields The ITS specify in column ‘Fill-In Option’ whether a given data field is mandatory or optional. 14/24 The fact whether a given data field is mandatory is also specified in the document ‘Data Model for DORA RoI’ (Link). Example from Template B_01.01 based on the Data Model document: For all data fields in template B_01.01, the value of the column ‘Nullable’ is set to ‘No’ meaning that all those data fields are mandatory. 5.4 Key fields 5.4.1 Identification of Key Fields The document ‘Data Model for DORA RoI’ (Link) specifies in column ‘PrimaryKey’ or ‘ForeignKey’ whether a given data field is a key field or not. Example from Template B_01.01 based on the Data Model document : Key fields cannot be empty. A non-compliance with this rule leads to the rejection of the submitted register. 5.4.2 Identical Key values on open tables Please refer also to the Top Error#7 described on page 20 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. As noted in the previous section 5.5.1, certain columns are defined as Key columns. In case a financial entity reports the same key twice, an error message will be raised and the submitted RoI will be rejected. 15/24 5.5 Missing data for Mandatory / Key fields Please refer also to the Top Error#2 (pages 11-13) and Top Error#3 (pages 14-15) in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. • The ESA specified in FAQ#26(U) that “If financial entities are not able to fill some data fields that are mandatory, they can leave these data fields blank (report empty values), unless the instructions to the data fields or responses to Q&A specify otherwise (please refer to responses to DORA Q&A 140, 141, 142, 143, 144, 145, 146, 147). “ • The answers to DORA Q&A 140-147 can be found in the Joint Q&A Register (Link). • Empty mandatory fields will generate a Warning message during the data quality feedback. The submitted register however will not be rejected. 5.5.1 Missing or unknown LEI FAQ#40 notes that “in case the LEI is not available for the ICT third-party provider (or its ultimate parent undertakings) registered in third countries, the financial entity should populate the data filed with any relevant value to avoid the file being rejected as failing the referential integrity check. In practice this could mean that the financial entity could use other identifiers available. The use of such identifiers will be highlighted as a data quality issue, but the files will not be rejected”. 5.5.2 Country key fields As the data fields B_02.02.0130, B_02.02.0150 and B_02.02.0160 are considered as key fields, they cannot be empty. The ESA have defined for those 3 data fields a drop-down list so that all 3 fields should contain as value a code with prefix ‘eba_’. Example 1: In case the Country of provision of the services is the country of Ireland, financial entities shall not enter ‘Ireland’ but the code ‘eba_GA:IE’ in fata field B_02.02.0130. Example 2: In case the mandatory key value is not known by the financial entities for one of those three fields, they shall specify the code ‘eba_GA:qx2007’ representing the value ‘Not applicable’. 16/24 In case the three key fields do not contain a value from the corresponding drop-down list, an error message will be issued and the submitted register rejected. 6. Foreign Key Violations Please refer also to the Top Error#1 described on pages 6-10 of the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. A data field is a foreign key meaning that the value of that data field shall be defined in a data field in the same or in another template. Is this not the case, an error message of type “Foreign Key Violation” will be issued leading to the rejection of the submitted register. The ESA distinguish between two types of Foreign Key violation : 6.1 Foreign Key Violation - across tables A Foreign Key Violation refers to a situation where a given data field contains a value which has not been defined in a primary key of another table. Example: - Table B_02.01 contains all the contractual arrangements signed with an Intra-Group entity or with an external TPPs. Each of those contractual arrangements are identified by a Contractual arrangement reference number. - Table B.02.03 contains all Intra-Group entity contractual arrangements. Each contract in table B.02.02 shall be defined in table B_02.01. Is this not the case, an error message of type ‘Foreign Key Violation - across tables‘ is displayed. The dependency between the tables B_02.01 and B_02.03 or precisely between the data fields B.02.01.0010 and B_02.02.0010 are represented in the Data Model for DORA RoI document as follows: 6.2 Foreign Key Violation - self reference Dependencies may also exist inside a single table. 17/24 Example: Table B.02.01 contains all the contractual arrangements of the financial entity. - Column c0020 of table B_02.01 specifies the type of the contract : standalone arrangement, overarching / master contractual arrangement or subsequent or associated arrangement. - In case column c0020 contains the value ‘subsequent or associated arrangement’, then column c0030 shall contain the contractual reference number of the overarching / master contractual arrangement. In the above example, Column 0030 contains a reference to a contract which has to be specified in table B.02.01. Is this not the case, a Foreign Key Violation error message will be raised and the submitted register will be rejected. 7. Validation Rules Please refer also to the Top Error#2 described on pages 11-13 in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. The ESA have regrouped all the technical validation checks in the document ‘Overview of the RoI reporting technical checks and validation rules (updated 10 March 2025)’ (Link). A non-compliance with these rules will trigger a warning message; the submitted register will however not be rejected. 7.1 DPM Business Validation Rules DPM rules for Table B_01.01 Code e23677_e Description All columns shall contain a value i.e. cannot be empty v8872_m In case column c0030 or c0040 or c0050 or c0060 contains a value then column c0020 shall not be empty. v8873_m In case column c0020 or c0040 or c0050 or c0060 contains a value then column c0030 shall not be empty. v8874_m In case column c0020 or c0030 or c0050 or c0060 contains a value then column c0040 shall not be empty. 18/24 v8875_m In case column c0020 or c0030 or c0040 or c0050 contains a value then column c0050 shall not be empty. v8876_m In case column c0020 or c0030 or c0040 or c0050 contains a value then column c0060 shall not be empty. v8890_m The LEI provided in column c0010 shall have a length of 20. DPM rules for Table B_01.02 Code e23676_e Description Columns c0020-0090 cannot be empty v22913_s Value of column shall be >= 0 v8803_m In case column c0110 is not empty, then column c0100 shall not be empty v8804_m In case the value of column c0040 is not ‘eba_CT:x318’ or ‘eba_CT:x317’ then column c0110 shall not be empty. v8826_m The LEI provided in column c0060 shall have a length of 20. v8858_m If the value of one of the columns c0030 or c0040 or c0050 or c0060 or c0070 or c0080 or c0090 or c0100 or c0110 contains a value then column c0020 shall not be empty. v8859_m If the value of one of the columns c0020 or c0040 or c0050 or c0060 or c0070 or c0080 or c0090 or c0100 or c0110 contains a value then column c0030 shall not be empty. v8860_m If the value of one of the columns c0020 or c0030 or c0050 or c0060 or c0070 or c0080 or c0090 or c0100 or c0110 contains a value then column c0040 shall not be empty. v8861_m If the value of one of the columns c0020 or c0030 or c0040 or c0060 or c0070 or c0080 or c0090 or c0100 or c0110 contains a value then column c0050 shall not be empty. v8862_m If the value of one of the columns c0020 or c0030 or c0040 or c0050 or c0070 or c0080 or c0090 or c0100 or c0110 contains a value then column c0060 shall not be empty. v8863_m If the value of one of the columns c0020 or c0030 or c0040 or c0050 or c0060 or c0080 or c0090 or c0100 or c0110 contains a value then column c0070 shall not be empty. v8864_m If the value of one of the columns c0020 or c0030 or c0040 or c0050 or c0060 or c0070 or c0090 or c0100 or c0110 contains a value then column c0080 shall not be empty. v8865_m If the value of one of the columns c0020 or c0030 or c0040 or c0050 or c0060 or c0070 or c0080 or c0100 or c0110 contains a value then column c0090 shall not be empty. v8891_m The LEI provided in column c0010 shall have a length of 20. 19/24 DPM rules for Table B_01.03 Code e23675_e Description Columns cannot be empty v8856_m If columns c0030 is not empty then column c0040 shall not be empty. v8857_m If columns c0040 is not empty then column c0030 shall not be empty. v8892_m The LEI provided in column c0020 shall have a length of 20. DPM rules for Table B_02.01 Code e23792_e Description Columns c0020, c0040, c0050 cannot be empty v22912_m In case column c0020 contains ‘eba_CO:x3’ then column c0030 shall not be empty. v23716_s The value of column c0050 shall be >= 0 v8805_m In case column c0020 contains ‘eba_CO:x3’ then column c0030 shall not be empty. v8866_m If one of the columns c0020, c0030 or c0040 is not empty then column c0050 shall not be empty. v8867_m If one of the columns c0020, c0030 or c0050 is not empty then column c0040 shall not be empty. v8868_m If one of the columns c0030, c0040 or c0050 is not empty then column c0020 shall not be empty. DPM rules for Table B_02.02 Code e23680_e Description Columns c004 to c0080 cannot be empty v8816_m Value of column c0080 shall be > then the value of column c0070 v8869_m In case of the columns c0070, c0080, c0090, c0100, c0110, c0120, c0140, c0170 or c0180 contains a value then column c0040 shall not be empty. v8870_m In case of the columns c0040, c0080, c0090, c0100, c0110, c0120, c0140, c0170 or c0180 contains a value then column c0070 shall not be empty. v8871_m In case of the columns c0040, c0070, c0090, c0100, c0110, c0120, c0140, c0170 or c0180 contains a value then column c0080 shall not be empty. v8893_m The LEI provided in column c0020 shall have a length of 20. 20/24 DPM rules for Table B_03.01 Code v8894_m Description The LEI provided in column c0020 shall have a length of 20. DPM rules for Table B_03.03 Code v8895_m Description The LEI provided in column c0020 shall have a length of 20. DPM rules for Table B_04.01 Code e23683_e Description Column c0030 shall not be empty. v8896_m The LEI provided in column c0020 shall have a length of 20. DPM rules for Table B_05.01 Code e23674_e Description Columns c0020, c0050, c0060, c0070, c0080 and c0110 shall not be empty. v8817_m In case column c0070 contains ‘eba_CT:x212’ then column c0020 shall contain ‘eba_qCO:qx2000’ or ‘eba_qCO:qx2002’ v8818_m In case column c0070 contains ‘eba_CT:x212’ then column c0040 shall contain ‘eba_qCO:qx2000’ or ‘eba_qCO:qx2002’ v8821_m If column c0020 contains ‘eba_qCO:qx2000’ then column c0010 shall contain a valid LEI v8823_m If column c0030 contains a value then column c0040 shall not be empty. v8824_m If column c0100 contains a value then column c0090 shall not be empty. v8850_m In case of the columns c0030, c0040, c0050, c0060, c0070, c0080, c0090, c0100, c0110 or c0120 contains a value then column c0020 shall not be empty. v8851_m In case of the columns c0020, c0030, c0040, c0060, c0070, c0080, c0090, c0100, c0110 or c0120 contains a value then column c0050 shall not be empty. v8852_m In case of the columns c0020, c0030, c0040, c0050, c0070, c0080, c0090, c0100, c0110 or c0120 contains a value then column c0060 shall not be empty. v8853_m In case of the columns c0020, c0030, c0040, c0050, c0060, c0080, c0090, c0100, c0110 or c0120 contains a value then column c0070 shall not be empty. 21/24 v8854_m In case of the columns c0020, c0030, c0040, c0050, c0060, c0070, c0090, c0100, c0110 or c0120 contains a value then column c0080 shall not be empty. v8855_m In case of the columns c0020, c0030, c0040, c0050, c0060, c0070, c0080, c0090, c0100 or c0120 contains a value then column c0110 shall not be empty. DPM rules for Table B_06.01 Code e23682_e Description Columns c0020, c0030, c0050, c0070, c0080, c0090, c0100 shall not be empty. v8877_m In case of the columns c0030, c0050, c0060, c0070, c0080, c0090 or c0100 contains a value then column c0020 shall not be empty. v8878_m In case of the columns c0020, c0050, c0060, c0070, c0080, c0090 or c0100 contains a value then column c0030 shall not be empty. v8879_m In case of the columns c0020, c0030, c0060, c0070, c0080, c0090 or c0100 contains a value then column c0050 shall not be empty. v8880_m In case of the columns c0020, c0030, c0050, c0060, c0080, c0090 or c0100 contains a value then column c0070 shall not be empty. v8881_m In case of the columns c0020, c0030, c0050, c0060, c0070, c0090 or c0100 contains a value then column c0080 shall not be empty. v8882_m In case of the columns c0020, c0030, c0050, c0060, c0070, c0080 or c0100 contains a value then column c0090 shall not be empty. v8883_m In case of the columns c0020, c0030, c0050, c0060, c0070, c0080 or c0100 contains a value then column shall not be empty. v8897_m The LEI provided in column c0040 shall have a length of 20. DPM rules for Table B_07.01 Code e23681_e Description Columns c0050, c0070, c0080, c0090, c0100 and c0110 shall not be empty. v8825_m In case column c0050 contains the ‘eba_ZZ:x959’ or ‘eba_ZZ:x960’ then column c0060 shall not be empty. v8884_m If one of the columns c0030, c0060, c0070, c0080, c0090, c0100, c0110 or c0120 contains a value then column c0050 shall not be empty. v8885_m If one of the columns c0030, c0050, c0060, c0080, c0090, c0100, c0110 or c0120 contains a value then column c0070 shall not be empty. v8886_m If one of the columns c0030, c0050, c0060, c0070, c0090, c0100, c0110 or c0120 contains a value then column c0080 shall not be empty. 22/24 v8887_m If one of the columns c0030, c0050, c0060, c0070, c0080, c0100, c0110 or c0120 contains a value then column c0090 shall not be empty. v88889_m If one of the columns c0030, c0050, c0060, c0070, c0080, c0090, c0100 or c0120 contains a value then column c0110 shall not be empty. v8888_m If one of the columns c0030, c0050, c0060, c0070, c0080, c0090, c0110 or c0120 contains a value then column c0100 shall not be empty. 7.2 Validation Rules related to LEI / EUID Please refer also to the Top Error#5, Top Error#9, Top Error#12 described in the ‘Observations from testing of RoI reporting to the ESAs – key common issues’ document published by the ESA. The identification of financial entities and their third-party service provider have been described in Section 2.1 of this document. Some of the rules specified in the previous section only check whether the LEI code is a valid LEI based on its composition (a string of 18 followed by 2 check digits) and its length. The ESA noted in their FAQ#44 (Link) that “the ITS on the registers of information requires LEI to be active. As part of the validation rules, LEIs are checked against an external database (GLEIF). This check will ensure that the LEI is a valid one in GLEIF. During the initial stages of the reporting of the registers of information and in particular in 2025, the ESAs will not be enforcing strict checks of the LEI status (e.g., active, lapsed, etc.)”. 8 additional validation checks are performed by the ESA related to LEI and EUIDs. Code Description Template / Column VR_2 LEI code validity : LEI code needs to be a valid one according b_01_01 / c0010 to the GLEIF database VR_12 LEI code validity: LEI code needs to be a valid one according b_01_02 / c0010 to the GLEIF database VR_16 Country Code validity: Code needs to be a valid one according b_01_02 / c0030 to the GLEIF database VR_23 LEI code validity: LEI code needs to be a valid one according b_01_02 / c0060 to the GLEIF database VR_71 LEI code validity: LEI code needs to be a valid one according b_05_01 / c0010 to the GLEIF database. Rule will only be checked in case b_05_01_c0020 = 'LEI' VR_72 EUID code validity: EUID code needs to be a valid one b_05_01 / c0010 according to the BRIS. Rule will only be checked in case b_05_01_c0020 = 'EUID' VR_77 LEI code validity: LEI code needs to be a valid one according b_05_01 / c0030 to the GLEIF database. Rule will only be checked in case b_05_01_c0040 = 'LEI' 23/24 VR_78 EUID code validity: EUID code needs to be a valid one b_05_01 / c0030 according to the BRIS. Rule will only be checked in case b_05_01_c0040 = 'EUID’ In case a non-compliance with these rules are identified, a warning message will be displayed but the submitted register will not be rejected. 24/24