Escrow Is Not Continuity: Underwriting Third-Party Model Dependency in UK MGAs

UK managing general agents have become sophisticated consumers of third-party technology. Pricing engines, exposure databases, claims triage tools and capital models are increasingly licensed rather than built. That is a rational response to speed and cost. It also creates a continuity exposure that many underwriting files still treat as an administrative matter. A software escrow agreement is often filed alongside the vendor contract and assumed to answer the question. In most cases it does not.

The distinction matters because an MGA's underwriting result is no longer simply a function of the people at the desk. It is a function of the rules embedded in software the MGA does not own, maintained by a vendor the MGA does not control, and updated on a cadence the MGA may not fully observe. When that arrangement fails, the question is not whether source code has been deposited. The question is whether the MGA can keep pricing risks, servicing brokers and meeting its delegated authority obligations.

What escrow actually protects

A conventional software escrow agreement is a deposit arrangement. It typically provides for source code, build instructions and related materials to be held by an independent escrow agent and released on specified trigger events, such as vendor insolvency or material breach. It is a useful backstop. It is not a continuity plan.

Underwriters should be clear about what the standard product does not provide. It rarely includes the production environment, the data pipelines that feed the model, the third-party libraries and licences on which the model depends, or the operational knowledge required to run it. It may not include the most recent version. It may not include the vendor's configuration settings. It may not include the model documentation that explains why a particular variable is weighted as it is. In practice, a release of source code without custody of the surrounding dependencies can leave an MGA with a legal right to code it cannot operate.

That gap is material in a UK context. MGAs operate under delegated authority arrangements where underwriting discipline is monitored by capacity providers and, in many cases, by Lloyd's or the Prudential Regulation Authority. A disruption to a core pricing engine is not merely an IT incident. It is an underwriting control event, a Consumer Duty evidence problem and, potentially, a breach of binding authority conditions. The escrow agreement should be assessed against those obligations, not against the comfort of having a signed schedule.

Four tests for escrow adequacy

A practical underwriting review can begin with four questions. First, what is actually deposited? The file should identify not only source code but the model specification, parameter files, data dictionaries, build and deployment scripts, dependency lists and licence terms. If the vendor uses a proprietary runtime or a cloud service that cannot be replicated, the deposit should say so explicitly and explain the fallback.

Second, how current is the deposit? A model that is updated quarterly but deposited annually is not a continuity asset. Underwriters should test the update rights in the escrow agreement: who is responsible for refreshing the deposit, how often, and what evidence the MGA receives. A vendor that treats escrow as a one-off onboarding task is unlikely to maintain a usable deposit.

Third, who can operate the model? Source code is not a capability. The MGA should identify whether it has, or can contract for, the skills to rebuild, test and run the model. In some cases the answer will be a specialist integrator; in others it will be the vendor's own staff under a transition services agreement. Either way, the arrangement should be documented before a trigger event, not after.

Fourth, what does exit look like? Escrow release is one step in a wider exit. The MGA should be able to extract its data, including historical exposure and claims records, in a usable format. It should understand which third-party licences transfer and which do not. It should know how long the vendor will continue to support the model during a transition. These are underwriting questions because they determine how quickly the MGA can resume writing and how much of its renewal book is at risk.

A 2026 underwriting checklist

For UK MGA arrangements, the following checklist can be used as a starting point. It is not a substitute for legal review, but it frames the continuity exposure in terms an underwriter can price.

• Identify every third-party model or decision engine that materially affects pricing, underwriting acceptance, claims triage or capital calculation.
• Confirm whether the vendor contract and escrow agreement cover the model itself, the data pipeline, the configuration and the documentation.
• Test the deposit refresh cycle against the vendor's release cycle. Require evidence of the most recent deposit.
• Review trigger events. Insolvency alone is rarely sufficient; consider prolonged service failure, loss of key vendor staff and regulatory action.
• Establish who has the right to operate the model on release and whether the MGA has access to the necessary skills and licences.
• Document the data extraction and transition process, including format, timing and cost.
• Assess the concentration risk if the same vendor supports multiple MGAs or multiple capacity providers.
• Record the residual exposure in the underwriting file and reflect it in any reliance placed on the vendor relationship.

The underwriting conclusion

The presence of an escrow agreement is not evidence of continuity. It is evidence that a deposit arrangement exists. For UK MGAs, the underwriting question is whether the arrangement preserves the ability to price, bind and service business through a vendor failure. That requires a view on custody, update rights and exit readiness, not simply a signature on a schedule. In 2026, with delegated authority under close scrutiny and technology dependency rising, the distinction should be reflected in how these risks are assessed and priced.