Source Code Escrow for AI Control Plane Vendors: A Decision Guide for Banks (as of November 2026)

What the current guidance says, and what has changed

The 2023 interagency third-party guidance says that when a banking organization purchases software, it is important to consider a provision for escrow agreements that give access to source code and programs under certain conditions, with insolvency of the third party given as an example. The same document states that supervisory guidance does not have the force and effect of law and imposes no new requirements. Escrow is therefore a consideration, not a mandate.

Two developments in 2026 affect how a policy should cite this baseline. On 17 April 2026, OCC Bulletin 2026-13 announced revised interagency model risk management guidance. It rescinds prior model risk management guidance and other issuances, covers vendor and other third-party products, and notes that practices appropriate for one bank may be inappropriate for another with a different risk profile or model use. On 15 September 2026, the OCC, Federal Reserve, FDIC and NCUA published proposed third-party risk management guidance. It is a proposal, not final. It stresses oversight proportionate to risk, risk-informed due diligence, and contract provisions negotiated in line with the bank's risk assessment.

The practical consequence is the same in both documents: tie the escrow decision to the bank's own assessment of the relationship, and record the reasoning. Revisit internal policy language when the proposal is finalised.

Why runtime enforcement layers raise the question

A runtime AI enforcement layer sits in the execution path of models, agents and tool calls. It applies policy to individual interactions and produces the evidence a bank may need to show examiners what its AI was permitted to do and what it did. That gives the vendor two roles at once: an operational control and the source of an evidence trail.

If the vendor fails, is acquired or discontinues the product, the bank can lose both. Enforcement may stop receiving fixes and updates, or the bank may have to remove it from the path. Evidence continuity can break at the point where examiner and model risk scrutiny is highest. For lower-stakes use cases this is an inconvenience. For consequential use cases it is a control gap that has to be planned for in advance, which is why model risk and third-party risk teams need shared criteria rather than case-by-case instinct.

Escrow within a wider continuity strategy

Escrow gives access to code. It does not by itself deliver a working control, trained staff or preserved evidence. Weigh it against the other continuity controls available.

Self-managed deployment in the bank's own cloud changes the dependency profile. The bank controls where the layer runs, the data and retention settings, and the evidence store, so a vendor failure does not switch off a hosted service. It does not remove the dependency on the vendor for fixes, security patches and ongoing development, which is where escrow can still matter. Trussed, for example, is a runtime policy enforcement layer in the execution path that is self-managed in the customer cloud and produces audit-ready evidence. For any vendor with that model, the question is whether the bank could sustain the software, not just host it.

For vendor-hosted services the exposure is larger, because access to source code alone may not restore service. The bank would also need the hosting environment, so escrow terms for hosted services should address that explicitly.

Other controls to pair with or substitute for escrow include export of policy definitions and configuration in documented formats, evidence exports the bank can retain independently, a tested exit plan, and contract terms covering support commitments and transition assistance. A stressed exit scenario that assumes supplier failure will show which of these controls actually works and where escrow adds something the others cannot.

Deposit scope for a runtime enforcement layer

Source code alone is rarely enough to operate a runtime layer. The deposit should contain what a competent engineering team needs to rebuild, configure, deploy and run the layer without the vendor.

Specify the following components in the agreement: application source code for the enforcement engine and any supporting services; build tooling and scripts, with the compiler and toolchain versions used; dependency manifests, including third-party and open-source components and their licences; policy definitions and rule schemas in the form the engine consumes; deployment configuration, such as infrastructure definitions and environment settings for the bank's cloud; and technical documentation covering architecture, build and deploy procedures, and operational runbooks.

For a layer that generates evidence, add the evidence schema and the means to read previously generated evidence. Without them, a bank could rebuild the software and still be unable to interpret the records examiners rely on. Require updates to the deposit with each material release, with a defined cadence, because a stale deposit will not match the version running in production.

Release conditions that hold up in practice

Insolvency of the third party is the release condition named in the interagency guidance. Contracts commonly extend the list to cessation of support, failure to meet maintenance obligations, and change of control. Each has different practical strengths.

Insolvency is clear to define but may be the least useful on its own, since a vendor can degrade for months before any formal event. Cessation of support and maintenance failure catch that degradation, but only if the contract defines them objectively, for example missed critical-fix timelines over a stated period, with a clear notice and cure process. Change of control matters when an acquirer may retire or neglect the product, but it needs careful drafting so that a benign acquisition does not trigger release while a harmful one is not missed.

Because enforceability depends on legal drafting and on how a vendor's insolvency is handled in law, have counsel test each trigger and the licence the bank receives on release. The licence should permit the bank to use, modify and maintain the code for its own operations, including through contractors. A trigger that cannot be established quickly, or a licence that is too narrow to operate under, offers little protection.

Verification levels: proving the deposit works

A deposit that has never been tested is an assumption. Escrow and verification providers describe verification as checking the completeness and viability of a deposit for a supply chain failure scenario, including dry-runs aligned with the release cycle of business-critical software. Three levels are commonly used, in increasing depth.

The first is file integrity: confirming the deposit is present, readable, free of malware and matches an inventory. The second is build verification: compiling the deposited code with the deposited tooling and confirming the output matches the production release. The third is deployment testing: standing up the built layer in a clean environment from the deposited configuration and documentation, then confirming that it enforces policy and produces evidence as expected.

For a self-managed runtime enforcement layer that a bank would have to operate alone after release, build verification is the minimum, and deployment testing is appropriate where criticality is high. Repeat verification on a defined schedule and after major releases, and align it with business continuity and disaster recovery planning. Record results in the vendor file so that examiners and model risk reviewers can see the evidence behind the continuity decision.