The growing reliance on external ICT service providers is one of the structural characteristics of modern financial market infrastructures. Significant concentration and default risks arise, particularly in the case of business-critical systems – such as core banking software, systems for lending, risk assessment or collateral management, trading and treasury systems, or applications relevant to regulation (e.g. reporting software, compliance or monitoring tools, fraud detection solutions, etc.). With Regulation (EU) 2022/2554 (“DORA”), the European legislator has responded to this dependency and created a comprehensive regulatory framework to strengthen digital operational resilience.
At the heart of this is the obligation for financial firms to remain operational at all times, even in the event of a failure of ICT service providers. This requires not only technical precautions, but also, in particular, robust contractual safeguards. Against this backdrop, escrow agreements are becoming increasingly important in practice. They are used as a tool to ensure access to critical software and data even in crisis situations.
Nevertheless, on closer inspection, it becomes apparent that escrow agreements are often overestimated. Their mere existence is not sufficient to meet the requirements of DORA. Rather, their regulatory and practical effectiveness depends crucially on their specific terms and conditions.
Escrow agreements: structure and legal function
An escrow agreement (often referred to in German as a trust or deposit agreement) is so named because it is based on the principle of the English term ‘escrow’, which refers to the custodial holding of assets by a neutral third party. Escrow agreements are typically structured as tripartite arrangements. The parties involved are the ICT service provider or software provider as the depositor, the financial institution as the licensee or beneficiary, and a neutral escrow service provider (escrow agent) as the trustee. The subject matter of the agreement is the deposit of source code, technical documentation, access data or other materials necessary for the operation of the software with the escrow agent.
Legally, this involves a combination of custody, security and trust-like elements. The escrow agent undertakes to release the deposited material to the beneficiary under defined conditions. The aim is to enable the financial firm to continue its business operations in the event of a crisis – such as the insolvency or default of the service provider.
The economic significance of escrow lies in reducing unilateral dependencies on ICT service providers. Particularly in the case of business-critical systems, the loss of access to the source code poses a significant operational risk for financial firms. Escrow agreements are intended to mitigate this risk by securing the necessary resources in advance, thereby enabling a form of contractual ‘business continuity’.
Escrow and DORA: No automatic regulatory classification
In the context of DORA, the question arises as to whether escrow service providers themselves are to be classified as third-party ICT service providers within the meaning of the Regulation. Such classification depends on the specific technical and organisational structure of the service and cannot be affirmed across the board. Whilst digitally operated escrow platforms may well qualify as ICT services in individual cases – depending on their structure – the activities of traditional escrow agents are generally limited to safekeeping and release.
The regulatory relevance of escrow agreements therefore typically lies not in the direct application of the DORA provisions to the escrow agent, but in their function as an instrument for safeguarding the DORA-relevant relationship with the actual ICT service provider. Escrow is thus an indirect but essential element of the resilience strategy.
A false sense of security: Why standard escrow is often insufficient
In practice, it is frequently assumed that simply entering into an escrow agreement is sufficient to meet regulatory requirements. This assumption is dangerous. Many escrow agreements are not structurally designed to ensure the actual continuity of critical systems. They provide a formal safeguard without effectively addressing the underlying risks.
In practice, the following structural weaknesses often emerge, which can significantly limit the effectiveness of escrow agreements in the DORA context.
- A key problem lies in the design of the release mechanism. Many agreements provide for triggers that are either too narrow or too broad. Whilst purely insolvency-related release rights are often insufficient to ensure the operational capacity required under DORA, broadly defined triggers – such as those triggered by mere breaches of contract – pose significant risks to the depositor’s IP position. What is required is a balanced, objectively verifiable provision that takes into account both the protection of intellectual property and practical access in the event of a crisis.
- Another structural weakness of many escrow agreements concerns the actual usability of the deposited material. In practice, the deposit is often limited to the source code, without any assurance that this can actually be compiled and made functional in an emergency. If build environments, dependencies or documentation are missing, the code is of no economic value. However, DORA requires not only access, but effectively the ability to continue critical functions. This gives rise to a derived best practice – in the sense of a proper specification of DORA’s objectives and requirements, not as an explicitly standardised individual obligation – namely the necessity of binding technical verifications that go beyond mere completeness checks.
- Closely linked to this is the question of the up-to-date nature of the escrow material. A risk-appropriate best practice aligned with DORA’s objectives suggests that periodic update cycles of six or twelve months, as provided for in many standard contracts, are regularly insufficient for dynamic IT environments. What is crucial is timeliness tailored to the specific risks and the respective IT dynamics. For effective resilience, it is essential that the deposited material is synchronised with the production version or can at least be synchronised at short notice.
- The copyright framework is also of central importance. The mere handover of the material is not sufficient if the licensee does not simultaneously receive the necessary rights of use to maintain operations, rectify errors or make adjustments.
- Conversely, in the absence of a clear purpose limitation, there is a risk of an excessive extension of rights at the expense of the depositor. The contract must therefore strike a precise balance between permission to use and the protection of intellectual property.
- Another critical point concerns the custody of the material. General formulations regarding ‘secure custody’ regularly fail to meet regulatory requirements. Rather, specific technical and organisational measures are required, for example with regard to encryption, access controls, redundancy and auditability. Particularly in light of DORA and regulatory requirements, the custody arrangement must be designed to be transparent and verifiable.
- Finally, the termination of the escrow agreement is often inadequately regulated. In practice, it is not uncommon to find arrangements where control over the material depends on short-term instructions or additional payments, or where, in extreme cases, automatic deletion is even provided for. This is clearly at odds with the objective of keeping critical resources permanently available. From the financial institution’s perspective, it is therefore essential to ensure that, even upon termination of the contract, an orderly return or continued safekeeping takes place.
In summary, it can be stated that escrow agreements can serve as an important tool for mitigating DORA-relevant risks, but only if they are drafted with legal precision, technical soundness and operational robustness. Standardised contract templates often fail to meet these requirements. Financial firms must therefore view escrow not as a mere compliance formality, but as an integral part of their resilience strategy, requiring independent legal and technical review.
Conclusion
In practice, this means that escrow agreements should be viewed neither as a mere formality nor as a panacea. They are a useful building block for safeguarding critical dependencies – but only realise their value if they are consistently conceived and implemented with real-world crisis scenarios in mind. A functional assessment from the perspective of an emergency is crucial: can the institution actually continue operations within a short timeframe? Is the deposited code complete, up to date and usable? Are there clear rights regarding further development and the involvement of third parties? And are the internal processes even prepared to utilise an escrow scenario operationally?
It is precisely here that a gap between contractual design and actual feasibility often becomes apparent in practice. Escrow is set up but not tested; materials are deposited but not validated; rights are agreed but not operationalised. From a DORA perspective, this appears insufficient, particularly in light of the requirements for ICT risk management, business continuity and regular testing.
Best practice is therefore to embed escrow within a holistic exit and resilience strategy. This includes, in particular:
- regular technical verifications and, where necessary, test runs derived from the DORA requirements (in particular ICT risk management, business continuity management, outsourcing control and testing),
- coordination with business continuity and IT contingency plans,
- clear governance for the event of disclosure,
- and continuous verification of the currency and completeness of the deposited material.
Only if escrow is understood not in isolation but as part of a structured resilience strategy can it make a genuine contribution to meeting the DORA requirements. Otherwise, there is a risk that, at the crucial moment, a contract may exist – but no viable course of action.
