DORA Red Flags: Is there an example of an entity that signs a contract and another Financial Entity that makes use of the ICT Services?

The DORA ITS Register of Information (ROI) [EU 2024/2956] uses four keys across 15 Standard Templates that are required to ensure the integrity of the data submitted to your Competent Authority. These keys are essential to the maintenance of your ROI data after you complete your initial upload.

Contract Key

DORA is about assessing interdependencies and interconnections between a Financial Entity and the ICT Services supporting critical operations, including contracted ICT Services form a Third-party.

In this blog, we take a look at the Contract key.

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.”

In the real world, there is a written contract, signed by two parties, a Financial Entity and an ICT Third-party Service Provider. These contracts can be verified and legally enforced. Recording the existence of each contract, by assigning it with a contract key, is the starting point, after which ICT Services can be identified and risk assessed.

In the DORA ITS Register of Information (ROI) [EU 2024/2956] the contract key (Contractual arrangement reference number) is used to uniquely identify a contract between a Financial Entity and an ICT Third-party. It is used 9 times across the 15 Standard Templates specified in the ROI (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).

To record the existence of a real-world contract in the ITS ROI, you need to enter data in 3 of the Standard Templates:

• B_02.01 – Contractual Arrangements – General Information (B_02.01.0010, B_02.01.0030)

• B_03.01 - Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s) (B_03.01.0010)

• B_03.02 - ICT third-party service providers signing the contractual arrangements for providing ICT service(s) (B_03.02.0010)

On its own, Standard Template B_02.01, has no real-world connection (you will not be able to find the contractual agreement from a record in B_02.01).

The contract key is an incremental code, you assign to each contract to be able to uniquely identify it in your ROI submission. In the real world of 100’s or 1,000’s of contracts, saved on a file server, you need to know the parties to a contract to locate the relevant agreements. You then need to know the ICT Services that you are interested in assessing, to find the agreement you are looking for.

In the ROI, the Contract Key (B_02.01.0010), Financial Entity (B_03.01.0010) and ICT Third-party Service Provider (B_03.02.0010) are used to uniquely identify a contract and the associated parties and Overarching Contract (B_02.01.0030) is used to link different legal agreement that together form part of the same contract.

The real-world of ICT Procurement involves a Master Services Agreement between the parties and addendums for the provision of additional services. It is the reason for B_02.01.0030 Overarching contractual arrangement reference number. B_02.01.0030 creates a parent child relationship between the Master Services Agreement, which is usually the first contract between a Financial Entity and ICT Third-party Service Provider, and subsequent addendums.

Groups of Legal Entities

The ROI design, and the use of the contract key 5 more times, is about the complexity associated with groups of legal entities. It is also about the use of legal entities within a group, that are not regulated Financial Entities, that contract ICT Services and provide them to regulated Financial Entities.

This complexity arises from the reality that for many global Financial Services businesses, the IT Department is a separate legal entity that centrally contracts ICT Services, develops its own solutions, contracts ICT Services from vendors and provides these solutions and services to multiple regulated Financial Entities (often with different licensed activities) within the same group.

It is further complicated as your IT Department operating through a separate legal entity is either unregulated and/or can be outside of the regulatory jurisdiction. Keep in mind that in recent years, the IT Departments within a Financial Services business have also been established as FinTechs providing ICT Service to other regulated Financial Entities.

It is important to note, that for the DORA ROI, if your IT Department exists as a function within a Financial Services business that operates through a single legal entity, then the only challenge you have is to understand the complexity of the design and some of the language used to explain it. A number of the Standard Templates are about how services are provided and used across groups of legal entities.

The design of the ROI must take into account the global nature of the largest Financial Service businesses operating through multiple legal entities within a group, both regulated and un-regulated, in different jurisdictions as well as a Financial Services business operating through a single legal entity within the regulatory jurisdiction.

Conclusion

This blog focuses on how Financial Entities use the contract key to record a contractual agreement in the ROI, how to record the parties that sign the contract and how to link separate agreements that together form part of the same contract.

The use of the contract key to identify interdependencies and interconnections across legal entities within a group, requires an understanding of the nature of the entities within the group. That is the subject of the next blog DORA Red Flags: Why do I need a Legal Entity Identifier? (Part 2).