Bank AI Controls: Buy Now, Build, or Wait for Your Core Provider? A Decision Framework Under Revised Model Risk Guidance

The supervisory baseline has changed

Many bank policies still cite SR 11-7. As of November 2026, that reference needs checking. The OCC issued revised model risk management guidance in Bulletin 2026-13 on 17 April 2026, rescinding its prior model risk management guidance and related issuances. The Federal Reserve has also issued revised guidance, which Vice Chair Bowman described as amended together with the OCC and FDIC.

Two features of the new text matter for this decision. First, the OCC guidance is risk-based and tailored to size, complexity and extent of model use. It is described as most relevant to banks above $30 billion in total assets, and it sets no enforceable standards. Second, the Federal Reserve states that its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI. Generative assistants, agents and coding assistants therefore fall outside that stated scope, and a bank cannot assume a runtime control layer will be assessed as a model under it.

The practical consequence is that the bank needs its own documented governance basis for these uses. Bowman said banks are relying on existing risk-management frameworks to guide their AI use. For agentic cases, the OCC's 4 November 2026 supervisory framework for examiners (Bulletin 2026-54) sets no new expectations, but it tells examiners to tailor reviews to the materiality of the use case. It also says control intensity can rise with the consequences of an agent's failure or misuse, with classification resting on consequences, transfer of agency and degree of human oversight rather than technical sophistication.

What a core provider can reasonably cover

A core banking or platform provider is well placed to govern its own AI features. It controls those features' configuration, can apply its own policies and can report on its own components. That is a legitimate reason to wait, particularly where the bank's AI use is concentrated in that provider's products.

The gap appears at the boundary. Banks rarely confine AI to one provider. Staff use general-purpose models, developers use coding assistants, and teams connect agents to internal tools. A roadmap that covers a provider's own features may say little about the models, agents, tools and assistants used across the rest of the bank. The question for the provider is not whether it has AI governance features, but which AI assets they reach and which are explicitly out of scope. Get that answer in writing.

A layered outcome is common: the core provider governs its own features, and a separate cross-vendor runtime layer covers everything else. Treat that as a design option to evaluate, not a conclusion. The deciding factor is the bank's own inventory of live AI use and where it sits.

Enforcement in the execution path and the evidence it produces

Examiners and model risk functions will ask two things: what was the AI permitted to do, and what did it do. Controls that review activity afterwards can answer the second question but not prevent the first from going wrong. Controls in the execution path can act before an action completes, for example by allowing it, redacting data, blocking it, rate limiting it, or escalating it for human approval. The ability to route high-consequence actions to a person maps directly to the OCC's emphasis on consequences and degree of human oversight.

Evidence quality is a separate test. Useful evidence is generated by the enforcement decision itself, retained on a defined schedule, held where the bank controls it, and exportable if the vendor relationship ends. Fed guidance acknowledges that banks using vendor models may not receive underlying code or data. The same logic applies to control vendors: if you cannot inspect the mechanism, the documentation and evidence the vendor supplies must carry the weight.

Trussed addresses this layer as runtime control for regulated enterprises. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls, and generates audit-ready evidence mapped to NYDFS, NIST and related frameworks. It has run in continuous production in a regulated enterprise for more than 18 months, with over 100 models under one policy plane. Insurance is the regulated financial sector where Trussed is deepest. Any vendor's claims, including these, should be tested against your own requirements.

Pricing the interim exposure of waiting

Waiting is not a neutral choice. Whatever AI is in use today runs under the controls the bank has now. The cost of delay is therefore specific to each bank, and the way to estimate it is an inventory: which generative, agentic and coding-assistant uses are live, which touch sensitive data or can take actions, and how each would be rated on consequences, transfer of agency and human oversight.

If the inventory shows mostly low-consequence uses inside one provider's products, a wait with interim policy restrictions may be reasonable. If it shows agents calling internal tools, or assistants handling customer or confidential data across several vendors, the exposure sits largely outside any single provider's roadmap, and waiting leaves that exposure unmanaged for an unknown period.

Buying carries its own risk, but it can be bounded. Pilot a limited, reversible scope with written exit and evidence-export terms before any broad rollout. Document the classification logic so it is defensible if examiners ask. A pilot can be retired if the core provider later delivers equivalent coverage, which keeps the decision reversible in both directions.

Third-party risk diligence for an early-stage vendor

Either path falls under the same bank-owned responsibility. The proposed interagency third-party risk management guidance, published 15 September 2026 and not yet final, states that the banking organization has ultimate responsibility for sound risk management and legal compliance. It lists core processing providers, cloud and compliance-tool providers and fintech partners within its scope, and scales practices to size, complexity, risk profile and the nature of the relationship.

For a startup, calibrate diligence to materiality rather than skipping it. The OCC's fintech due diligence guide for community banks is a usable checklist source for a young vendor's risk management, controls, audit work and information security. Add the questions specific to this category: where the software runs, who holds the data and evidence, how data residency is configured, which subcontractors are involved, what independent attestations exist, how the vendor's financial position is disclosed, and what transition support applies on exit.

Deployment model deserves particular attention. A self-managed deployment in the bank's own cloud, with configurable retention and data residency, keeps evidence under bank control and eases several diligence questions. Trussed offers this, and its approved attestations include SOC 2 Type II and ISO 27001. A bank should still verify any vendor's attestations directly and decide whether they satisfy its own requirements.