DORA Red Flags: Why do I need a Legal Entity Identifier? (PART 1)
- Alan Barry
- Feb 12
- 4 min read
So far, the DORA Red Flags blog series has focused on two of four keys identified in Recital (8) of the DORA ITS on the Register of Information (ROI) [EU 2024/2956]:-
the Type of ICT Service key where we highlighted the need for an ICT Service key, and
the Function Identifier key which is a hybrid of functions from your operating model and the licensed activities obtained through a Regulatory Authorisation
The integrity of these keys and their connection to the real world is important when creating and maintaining the data submissions to your Competent Authority
Recital (8): To that end, the register of information should use four keys, which, among others, linking relevant data to each other across the templates of the register of information: (i) the reference number of the contractual arrangement between the financial entity signing that arrangement and the direct ICT third-party service provider, (ii) an appropriate identifier of financial entities and ICT third-party service providers, (iii) the function identifier, and (iv) the type of ICT services.
The Type of Service key appears three times in the 15 Standard Templates in Part 2 of ANNEX I of the ITS ROI (B_02.02.0060, B_05.02.0020 and B_07.01.0040). The Function key appears twice (B_02.02.0050 and B_06.01.0010).
The next blog in the series will look at the Contractual Arrangement Reference Number key which appears 9 times in the 15 Standard Templates (B_02.01.0010, B_02.01.0030, B_02.02.0010, B_02.03.0010, B_02.03.0020, B_03.01.0010, B_03.02.0010, B_03.03.0010 and B_04.01.0010).
Legal Entity Key
This blog introduces the complexities associated with the Legal Entity Key by identifying the relationships within DORA ITS ROI Standards Templates that use the Legal Entity Identifier (LEI). The DORA Reg Flags blog series will examine each of the relationships at a later date.
The Legal Entity Identifier is specified 18 times across the 15 Standard Templates in the DORA ITS ROI.
It is used in 10 fields to uniquely identify a Financial Entity (or a Legal Entity within a group or Branch associated with a Financial Entity):
B_01.01.0010. LEI of the Financial Entity Maintaining the Register of Information (Competent Authority Relationship).
B_01.02.0020. LEI of the Financial Entity (In-scope Financial Entities).
B_01.02.0060. LEI of the Direct Parent Undertaking of the Financial Entity (In-scope Financial Entities).
B_01.03.0010. Identification Code of the Branch (Branches).
B_01.03.0020. LEI of the Financial Entity Head Office of the Branch (Branches).
B_02.02_0020. LEI of the Financial Entity Making Use of the ICT Service(s) (Service Use).
B_03.01.0020. LEI of the Entity signing the Contractual Arrangements (Contract).
B_03.03.0020. LEI of the Financial Entity providing ICT Services (Service Use Non Contracting Entity).
B_04.01.0020. LEI of the Financial Entity making use of the ICT Services (Service Use Branch).
B_06.01.0040. LEI of the Financial Entity (Function Identification).
It is used a further 8 times in the 15 Standard Templates to identify the ICT Third-party Service Providers.
B_02.02.0020. Identification Code of the ICT Third-party Service Provide (Contract).
B_03.02.0020. Identification Code of the ICT Third-party Service Provider (Service Provision).
B_05.01.0010. Identification Code of the ICT Third-party Service Provider (ICT Third-parties).
B_05.01.0010. Additional Identification Code of the ICT Third-party Service Provider (ICT Third-parties).
B_05.01.0110. Identification Code of the ICT Third-party Service Providers ultimate parent undertaking (ICT Third-parties).
B_05.02.0030. Identification Code of the ICT Third-party Service Provider. (Supply Chain)
B_05.02.0060. Identification Code of the recipient of the sub-contracted ICT Services. (Supply Chain)
B_07.01.0020. Identification Code of the ICT Third-party Service Provider. (Assessment)
What does all of this mean in the real world?
Contract
In the real world, a contractual arrangements between a Financial Entity and an ICT Third-party Service Provider sets an expectation for an identifiable contract between two parties, a service buyer and a service provider, both of which are identifiable legal entities.
Prior to reading the DORA ITS ROI, there is an expectation for a Standard Templates identifying Contracts (a contract key), Financial Entities (a legal entity key) and ICT Third-party Service Providers (a legal entity key). The contract has two parties requiring a relationship between the Contracts and Financial Entities and Contracts and ICT Third-party Service Providers.
This is the real-world view of how ICT Services are procured.
Interdependencies and Interconnections
DORA is about the identification of interdependencies and interconnections between critical operations and ICT Services. The contract is important but what DORA is focused on is the services that are enabled as a result of the contract and the dependencies that are created.
Think about your weekly grocery shopping, what is important? the receipt that confirms what you have bought and the amount you paid, or the items you unpack when you arrive home?
What happens after a contract for ICT Service is signed?
The ICT Service in the contract are installed or enabled by the Technology teams, configured to meet your needs and handed over to users who are granted permission to use the functionality. That creates the dependency relationship that DORA is about, the contract is a gateway to the ICT Services, while the nature of the ICT Third-party Service Provider and the approach taken to service provision will present risks that need to be identified and assessed.
There are significant complexities associated with Dependency Analysis within an Operating Model, within ICT Services and between an Operating and ICT Services. This is compounded by a Regulators limited scope both in terms of jurisdiction and legal entity authorisations. That is, how legal entities in different jurisdictions within the same group, some of which are unregulated, provide services to support a global Operating Model.
Conclusion
The complexity in the ROI reflects real world dependencies. Without an understanding of the relationships, you risk tapping large amounts of meaningless data into 15 different tabs in an Excel template without any reference to the real world. A significant volume of data that has to be maintained by someone else, as the real world changes.
In the next blog we will look at the key Contractual Arrangement Reference Number, after which we will return the Legal Entity Identifier with Part 2 to examine the relationships in the ROI.
Comments