Self-Hosted AI Software License Terms for Banks: Perpetual Use, Exit Assistance and Support Windows

Why licensing is a control and evidence question

For self-hosted AI software, the license is part of the bank's control environment. The software runs in the bank's own cloud, so the contract decides whether it stays usable, supportable and replaceable when the vendor relationship changes. Gaps tend to surface late: a vendor ends support, changes its licensing model, or is replaced, and the bank cannot show continuity, documented dependencies or retained evidence.

The US interagency guidance on third-party relationships, issued by the Board, FDIC and OCC in June 2023, covers all stages of the relationship life cycle and does not assume every relationship needs the same level of oversight. It says a bank typically negotiates contract provisions that facilitate risk management and oversight and specify the obligations of both parties. As of November 2026, an interagency proposal announced on September 11, 2026 would replace that guidance. It is a proposal, not final, so check its status before finalizing any checklist. The proposal restates that using a third party does not diminish the bank's responsibility to manage risk and comply with laws.

Supervisory guidance does not have the force and effect of law. Present the terms below as aligned to supervisory expectations, not as legal mandates.

Perpetual use: define what survives termination

A perpetual license is only as useful as its scope. The questions that matter are which versions, updates and components remain licensed after termination or non-renewal, and whether anything in the software depends on the vendor to keep working. License keys with expiry dates, activation or phone-home checks, and update delivery channels are all dependencies. Ask the vendor directly whether any of them can stop a deployed system from running.

The third-party guidance gives several hooks. It lists terms governing the use of the bank's information, systems, intellectual property and equipment as contract considerations. It also says it is important to include warranties related to the vendor's own licenses or subscriptions for intellectual property developed by other third parties. For AI software, that bears on embedded third-party components. Ask for a list of those components and a warranty that the vendor has the right to license them to the bank.

The guidance also says that when a bank purchases software, it is important to consider an escrow provision giving access to source code and programs under certain conditions, for example insolvency of the vendor. Whether escrow should extend to model weights, configuration or deployment tooling is a negotiation item. So is whether release conditions go beyond insolvency, such as end of support. Define the escrow scope against what is needed to run and rebuild the deployed system, not only the source code.

Exit assistance: scope, duration and evidence return

Exit assistance turns a termination right into something the bank can execute. The contract should define the transition period, what the vendor returns or exports, and whether it will cooperate with a successor provider. For self-hosted AI software, the exportable items include configuration, policy definitions and audit evidence, in formats a successor or the bank's own tooling can read.

The model risk side reinforces this. The interagency statement on model risk management for BSA/AML systems says it is important that banks using third-party models have contingency plans if the model is no longer available or serviced, or may no longer be reliable, and that banks remain responsible for compliance when using them. That statement is narrower in scope than AI generally, but the contingency principle carries over to any vendor-supplied model a bank depends on. An exit assistance clause is a concrete part of that plan.

There is no single US benchmark for transition length. For an EU reference point, the Data Act contract requirements for switching describe a transitional period of up to 30 days and a data retrieval period of at least 30 calendar days afterward. Whether they apply to a given arrangement is a legal question, so treat them as context. Set the bank's duration against how long it realistically takes to select, validate and cut over to a replacement, including re-validation under change management.

Support windows: lifecycle, patches and notice

Support and maintenance are named in the third-party guidance as ancillary services to be described in the contract. For self-hosted AI software, the description should state how long each version is supported, what security patch commitments apply during that period, and how much written notice the vendor gives before ending support for a version the bank runs.

A Federal Reserve due-diligence document for community banks notes that a technology provider's procedures for deploying new software, and its policy on patching and use of unsupported or end-of-life software, tell the bank about the provider's potential security and business impact. Request that written policy during due diligence and make the key commitments contractual.

Support lapses are also a model risk issue. If a model is no longer serviced, the contingency expectation above applies. Support windows should therefore be aligned with the bank's validation and change management cycles. A short notice period on end of support can force an upgrade or replacement before the bank has validated the new version. Ask whether extended support is available and on what terms, and record the answer.

Keeping evidence in the bank's hands

Deployment architecture changes how much exit friction a contract has to absorb. When the software is self-managed in the bank's own cloud, data, logs and configuration sit in the bank's environment. The contract should say which categories of information, systems and intellectual property live there and what the vendor can access. Documented dependencies, retained records and review evidence should sit in bank-controlled storage so they remain available if the vendor relationship ends. Retention periods and residency are the bank's decisions to set.

This is where a runtime control layer matters to the evidence question. Trussed enforces policy in the execution path for models, agents and tool calls (allow, redact, block, rate limit, escalate for human approval) and produces audit-ready evidence from that enforcement. It deploys self-managed in the customer cloud with configurable retention and data residency, so the evidence stays with the customer. Trussed has not been deployed at banks; its production experience is in insurance, pharma, healthcare and education, and it has run continuously in a regulated enterprise for more than 18 months.

The point for buyers is general: whichever vendor is chosen, ask whether the evidence of what the AI was allowed to do, and what it did, remains accessible to the bank after the contract ends.