What happens if a small AI control plane vendor is acquired or shuts down: a bank contingency plan

Why the enforcement layer needs its own contingency plan

A runtime enforcement layer sits in the execution path of models, agents and tools. It decides whether an interaction is allowed, redacted, blocked or escalated, and it generates the evidence that shows what was decided. If the vendor behind it disappears or changes direction, the bank loses both functions at once: control over AI behavior and the record that examiners and model risk management teams expect to see.

The interagency guidance on third-party relationships is final, with Federal Register publication dated June 9, 2023. As of November 2026, the supplied record shows no amendment. It says effective planning should outline the bank's contingency plans if it needs to transition an activity to another third party or bring it in-house. It also says a bank can face substantial financial loss and operational disruption if it fails to manage third-party risks appropriately. For banks supervised by the Federal Reserve with $10 billion or less in consolidated assets, SR 24-2 asks whether a third party can operate through and recover from incidents, and what provisions are needed for termination events and continuity planning.

The interagency model risk management statement adds that banks using third-party models should have contingency plans if a model is no longer available or serviced. Whether that statement reaches an enforcement layer is an interpretation, but model risk teams are likely to ask the question, so the plan should answer it. The depth of the plan should match how critical the activity is to the bank and its customers.

Four vendor-failure scenarios and what each puts at risk

The scenarios differ in speed and in what the bank can still rely on. Assess each one separately, because a plan written for orderly termination rarely survives an abrupt insolvency.

• Acquisition: Service continues, but roadmap, pricing, support and data handling may change. Risk is gradual: unsupported features, new sub-processors, or a product merged into another.
• Change of control: Ownership shifts without a product change. Contract rights, assignment limits and restrictions on access to bank data and systems determine whether the bank can react.
• Product sunset: The vendor announces an end date. The bank has a window, but updates, support and fixes taper off while the exposure remains.
• Insolvency: Hosting, support and engineering can stop abruptly. Impact depends on whether enforcement and evidence run in infrastructure the bank controls.

Fail-open or fail-closed: decide it per interaction type

When the enforcement component becomes unavailable or unsupported, AI interactions are either blocked (fail-closed) or proceed without enforcement (fail-open). Neither is correct everywhere. Blocking everything can halt customer-facing or operational processes. Passing everything through leaves interactions unenforced and produces no evidence for the gap period.

A practical approach is to classify AI use cases by consequence. Interactions that touch sensitive data, trigger tool calls with external effects, or feed decisions subject to model risk management usually justify fail-closed behavior or a human approval path. Low-consequence internal uses may tolerate a time-limited fail-open state with compensating monitoring. Record each classification, who approved it, and the maximum duration of any unenforced state.

Then test it. Degraded-mode behavior should be established by deliberately disabling the enforcement path in a non-production environment and observing what actually happens, including loss of policy updates, approval workflows and escalation routing. Fold the results into the bank's business continuity scenarios, which should consider cases where service capacity and continuity objectives cannot be met.

Technical and contractual dependencies that determine impact

Impact is set less by the vendor event than by where four things live: the runtime, the policies, the evidence, and the contractual rights around them.

Deployment model. If enforcement runs in a vendor-hosted service, an insolvency can switch it off. If it runs as a self-managed deployment in the bank's own cloud, the software keeps running while the bank arranges support or a replacement, though updates and fixes may stop. Self-managed deployment reduces availability risk but shifts patching and operations to the bank.

Policy and configuration ownership. Policies should be owned by the bank, stored in versioned, readable form and mapped to internal control requirements, so that they can be re-implemented on another engine. Proprietary formats that only the vendor can interpret create lock-in even when the contract is favorable.

Evidence retention and export. The guidance stresses the bank's ability to access its data in a timely manner and to share data and documentation with regulators. A sound design keeps evidence in bank-controlled storage, in documented export formats, with retention set by the bank. It also confirms the vendor may not resell, assign or permit other entities to access the bank's data, metadata and systems.

Escrow and its limits. Software escrow can give the bank a route to source code, but code alone does not supply the build knowledge, hosting, security patching or people needed to run it. Treat escrow as a supporting measure and verify release conditions and a working build, not as the plan itself.

As a restrained example of these design properties, Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency, and it generates audit-ready evidence from enforcement in the execution path. These are architecture features a bank can evaluate in any vendor. Trussed does not claim financial-services deployments.