DORA Red Flags: Why do I need a Legal Entity Identifier? (PART 2)

Why do I need a Legal Entity Identifier? (PART 1) identified that the legal entity key is used 18 times across the 15 Standard Templates in the DORA ITS Register of Information (ROI) [EU 2024/2956]. The legal entity key is used 10 times for Financial Entities and 8 times for ICT Third-party Service Providers.

The legal entity key is one of four keys that you need for the initial ROI submission to your Competent Authority. Protecting the integrity of these keys is essential to the continuing requirement to update your ROI submission and keep it aligned with real world changes.

Recital (8) ITS ROI: “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.”

Part 1 highlighted the use of the legal entity key in the Contractual Relationship (Financial Entity: B_03.01.0020 and ICT Third-party Service Provider: B_03.02.0020).

Digital Operational Resilience is about interdependencies and interconnections that support critical operations. It involves groups of relationships:

• Operating Model. The interdependencies that exist within an Operating Model. Think about the role played by each of your business functions as it evolves over time when a business expands into new territories and begins to outsource some of its activities. Initially, there is a single legal entity and just functional interdependencies (all within the scope of the regulatory authorisation). If this (internal or external) service provider does not deliver, what is the impact on our customers?

• Systems. The interconnections that exist within the Technology Stack. Best practice system design promotes the re-use of objects, the building blocks behind the user interface. If it is not easy to get a single view of a customer, it is usually because the interaction with the customer is supported by multiple systems for different products. DORA is about understanding all of the interconnections, so that they can be risk assessed. If I delete this field what systems will break?

• Interdependencies between your Operating Model and your Systems. This is the link between critical operations and systems. Thinking about business functions, what systems does each depend on? There are different types of interdependencies between your Operating Model and your systems. There will be function specific systems (Applications with a Technology Stack) and the infrastructure required to run all systems (Operating Systems). Cloud introduces more specialisation and re-use potential into the Technology Stack with new interconnections this time between different legal entities when sub-contractors are used to provide specific components and services within the Technology Stack.

Why do I need a Legal Entity Identifier? (PART 2), looks at the legal entity key and the relationships / interdependencies within the Operating Model (of a Financial Entity).

PART 1 identified the use of the legal entity key in the Contractual Relationship (Financial Entity: B_03.01.0020). The legal entity key is used a further 9 times for Financial Entity relationships within an Operating Model (across 8 of the Standard Templates).

Competent Authority Relationship (1)

The first use of the legal entity key is template B_01.01 which identities the Financial Entity maintaining the register of information. In template B_01.01, the legal entity key (B_01.01.0010) and Competent authority (B_01.01.0050) are used to create a record to identify the Financial Entity that is responsible for reporting the Register of Information and the Competent Authority to which the data will be submitted.

For a business that operates through a single Financial Entity with an authorisation from one Competent Authority this can appear to be a bit meaningless (the relationship between the Financial Entity and Competent Authority will be well established and known).

For a business that operates as a group with multiple Financial Entities in different jurisdictions, holding authorisations, with multiple Competent Authorities, the relationship established in template B_01.01 is to clarify the Financial Entity that will report the Register of Information and the Competent Authority that will receive the data. DORA provides flexibility allowing a group to determine the approach it takes when submitting the Register of Information.

Recital (2) ITS ROI: “To reduce administrative costs of groups, groups should have the possibility to develop a single register of information at entity, sub-consolidated and consolidated levels in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers to all the financial entities that are part of that group.”

Scope (2)

The legal entity key is used twice in template B_01.02 - List of financial entities within the scope of the register of information.

It is first used in B_01.02.0010 to create a record for each Financial Entity that is included in the Register of Information submission. The second use is in B_01.02.0060 which identifies the direct parent for the record and creates a parent child relationship with B_01.02.0010.

Branches (2)

In template B_01.03, use of the legal entity key is permitted in B_01.03.0010 to identify a branch of the legal entity. It is used in B_01.03.0020 to identify the legal entity to which each branch belongs, the Head Office, keeping in mind that each legal entity key used in B_01.02.0010 can have a branch network.

Use of the legal entity key in B_01.03.0010 is restricted to circumstances where each branch has a unique legal entity key and that the legal entity key in B_01.03.0020 is also unique.

This re-use of the legal entity key for a branch appears to be an unnecessary complication. A branch is a separate entity in data modelling and the use of the legal entity key to also represent a branch will create confusion. In data modelling a branch has a one-to-many relationship with a legal entity – you need a unique identifier for a legal entity and a unique identifier for a branch. (Entity above has two different meanings – it is used to refer to data modelling, the Entity Relationship Diagram, which establishes the relationship between data as well as a legal concept about ownership, a legal entity).

In the real world, a legal entity operating through a branch network will have an internal identifier for each branch and the use of an internal branch identifier (that is unique) is permitted in B_01.03.0010.

If you are aware of the use of a Legal Entity Identifier for a branch, that meets the specification for B_01.03.0010 please provide feedback.

Service Use (1)

Template B_02.02 - Contractual arrangements – Specific information, creates records for the relationship between Financial Entities, Contracts and ICT Third-party Service Providers to recognise the use of ICT Services by legal entities.

The legal entity key of the Financial Entity “making use of the ICT Service(s)” is recorded in B_02.02.0020.

The commercial use of ICT Services in a contract is primarily defined by users and functionality, not by legal entities. For example, it is usual for the contract for the procurement of a HR system for global Financial Services business operating as a group with 30 legal entities, to identify the permitted use as any legal entity that is a member of the group. Functionality such as annual leave requests will be generally available to all employees, while functionality such as payroll will be restricted to members of HR. Commercially the structure of the agreement might include a license fee for general use by all employees of identified modules within the system with additional license fees for specified users – Manager functionality and HR functionality, for example.

Commercially, what is important to the ICT Third-party Service Provider is the number of users for each type of license provided (as tiered volume-based discounts are usually offered).

The contractual agreement in this scenario, is often between one legal entity in the group, a legal entity that exists for centralised IT procurement and provisioning and the ICT Third Party. The contractual agreement as described above allows the provisioning of the ICT Services to all legal entities within the group (the definition of group is a standard clause in most contracts).

Contract (1)

Entity signing the Contractual Arrangement (B_03.01.0020), see Why do I need a Legal Entity Identifier? (PART 1).

Branch (1)

Template B_04.01 – Financial Entities making use of the ICT Services could do with a name that is more aligned with its purpose.

The first and second fields in B_04.01 are the same as the first and second fields in B_02.02 and both templates focus of is on the identification of “…financial entitiy making use of ICT Service(s)”. B_04.01 requires a branch level of detail and B_02.02 requires a function level of detail.

Both templates will include records that identify the relationship between a contract, a “…financial entity making use of ICT Service(s)” and both require more detail – one for function level interdependencies and the other for branch level interdependencies.

Functions (1)

In Template B_06.01, field B_06.01.0040 is a legal entity key to establish the relationship between legal entities and functions. Keep in mind that the functions key in DORA does not represent a real-world function, it is a hybrid key of business function and licensed activity. This was covered in the blog DORA Red Flags: What is a function?

Templates B_06.01 and B_01.03 are similar, one identified the functions that belong to a legal entity, while the other identifies the branches that belong to a legal entity.

Service Use Non-contracting Financial Entity (1)

It is clear from feedback that many people struggle to understand the objective of template B_03.03 – Entities signing the contractual arrangements for providing ICT Services to other entities within the scope of the consolidation.

It is important to highlight that the use of the legal entity key in this template is about the “…financial entity providing the ICT Service(s)” rather than the “…financial entity making use of the ICT Service(s)”. There must be a record for the financial entity in Template B.01.02. It must therefore be a financial entity within the scope of the Register of Information, that has signed a contract with an ICT Third-party Service Provider and that also provides ICT Services to other financial entities within the scope of the consolidation.

It sounds like a Financial Entity within a group that has an IT Department that has signed a contract with an ICT Third-party Service Provider. Template B_02.02 will identify financial entities making use of that service and Template B_03.01 will identify the financial entity that has signed the contract.

The legal entity key in B_03.03.0020 must be a financial entity, it must have signed a contract with an ICT Third-party, it most likely is a “…financial entity making use of the ICT Service(s)” and it must also be a “…financial entity providing the ICT Service(s)” to other financial entities in the consolidation.

This appears to be deal with the scenario where you have a legal entity that is a financial entity which has an IT Department within the legal entity that acquires ICT Services for its own use and also provides them to other financial entities within the group. It sounds like a situation where you have one dominate financial entity in the group but the IT Department has not been established as a separate legal entity.

Keep in mind that a legal entity within a group that acts to centralise the procurement and provision of ICT Services to other legal entities within the group would be an internal ICT Third-party Service Provider (it would be unregulated and not a financial entity within the definition of DORA).

This template appears to be about relationships between financial entities within a group that provide ICT Services to each other where one entity contracts those services. There isn’t a contract for the provision of these ICT Services between the financial entity and the other financial entities. The other financial entities are recorded as making use of the ICT Services and B.03.03 appears to be addressing a “making use of” and “providing” gap to complete the picture.

Conclusions

The legal entity key for a financial entity is used 10 times across 8 of the Standard Templates in the ITS ROI. This blog is about identifying and providing real world context for the relationships that use the legal entity key for a Financial Entity that belongs to a group.

Why do I need a Legal Entity Identifier? (PART 3), will look at the relationship for the legal entity key for ICT Third-party Service Providers.