Bank Examiner Questions on AI Vendor Controls: What to Prepare as of November 2026

What examiners work from, as of November 2026

Two sets of expectations frame most questions. The interagency guidance on third-party relationships, published as an attachment to SR 23-4, covers due diligence, information security, audit and independent testing, and contract provisions. It asks banks to evaluate a third party's risk management, including its policies, processes and internal controls, and to consider whether its controls and operations are subject to effective audit assessments with objective reporting of results.

On model risk, the Federal Reserve now has SR 26-2, titled revised guidance on model risk management. It includes a section on vendor and other third-party products, and it recognizes that a bank may not receive underlying code or data from a vendor. It treats validation of vendor products, ongoing monitoring and outcome analysis as sound practice. SR 11-7, issued in April 2011, is earlier guidance and should not be cited as the current standard without checking its status.

The OCC issued Bulletin 2026-54 on November 4, 2026. It is a supervisory framework to support examiners evaluating banks' use of what it calls "super intelligence." It states that it does not establish supervisory expectations, but it identifies considerations that supplement existing model risk management, governance, technology, compliance and operational-risk practices. It is still a useful preview of how examiners may probe consequence, autonomy, data sensitivity, permission scope and vendor dependencies.

How vendor size changes the evidence, not the standard

Nothing in the guidance sets a different standard for small vendors. The OCC framework tells examiners to tailor reviews to materiality and to the bank's size, complexity and risk profile, and it ties risk classification to consequences, transfer of agency and degree of human oversight rather than technical sophistication.

The practical effect is on who carries the proof. A larger vendor may arrive with a long operating history, a full set of audit reports and mature documentation. A smaller vendor may not, and an examiner will still expect the bank to show how it assessed the vendor's controls. Gaps in the vendor's file become gaps in the bank's file unless the bank fills them with its own testing, contract terms and monitoring.

Start by tiering the use case. A control that blocks or escalates consequential actions with limited human review warrants a deeper package than one that advises a reviewer on low-impact work. Scale documentation to that consequence, and treat vendor size as one input to what you must produce.

Control scope and runtime enforcement

The first line of questioning is usually what the controls do. Examiners will ask which interactions, tool calls and agents fall inside scope, what policy applies to each, and what happens when a rule is triggered. Be ready to name the actions that are allowed, redacted, blocked or escalated, and who approves an escalation. Under the OCC framework, who approves escalated actions and how overrides are logged bear directly on the degree of human oversight.

The harder question is where enforcement sits. A control that reviews activity after the fact can describe what went wrong, but it cannot show that a prohibited action was prevented. A control in the execution path applies policy before the interaction completes. Test this directly. Ask the vendor to demonstrate a blocked action, then ask for the record the bank would retrieve for it. Confirm what the control does if the enforcement component is unavailable.

Trussed illustrates this pattern for a regulated enterprise. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval, at the level of individual interactions and tool calls. Trussed does not claim bank or financial-services customers. Insurance, a regulated financial sector, is where it is deepest.

Evidence durability, deployment model and data residency

The third-party guidance expects contracts to address the vendor's obligation to retain and provide timely, accurate and comprehensive information, the bank's ability to access its data in a timely manner, and how data and supporting documentation can be shared with regulators. The OCC framework adds that examiners may look at underlying evidence, such as logs, overrides, incidents and remediation, rather than only management summaries.

That translates into several tests. Can the bank retrieve control records without a vendor request? Are retention periods configurable and aligned with the bank's own schedule? Can the records be shown to be complete and unaltered, for example through integrity checks written at the enforcement point? Can an examiner follow a single event from policy to decision to record?

Deployment model decides much of this. The OCC framework treats prompts, outputs, embeddings, logs and feedback as data the bank may need to protect, and says contracts and configurations clarify whether a vendor uses bank data. If the vendor hosts the control and holds the evidence, the bank depends on the vendor for retrieval and residency. If the control runs in the bank's own cloud, evidence stays under the bank's access controls. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency.

Attestations, model risk and continuity

The guidance asks whether a third party's controls are independently tested and whether information security is consistent with the bank's own program. Independent attestations such as SOC 2 Type II and ISO 27001 are common ways to evidence this. A Type II report speaks to how controls operated over a period, not only how they were designed. Where a small vendor lacks them, the bank should expect to commission or perform comparable testing. Trussed holds SOC 2 Type II and ISO 27001, and has run in continuous production in a regulated enterprise for more than 18 months at 99.95% uptime on live production traffic.

For model risk, treat the control vendor as part of the bank's framework. Obtain developmental evidence on components, design and intended use. Where code or data is withheld, plan validation around testing, ongoing monitoring and outcome analysis. Ask how product changes and upstream model version changes are disclosed, and link the vendor to the model inventory, validation schedule and internal audit scope.

Continuity is the final test. Examiners will ask whether the bank has considered how to exit the activity or move it to another third party or in-house, and what record-keeping the vendor must support. For a small vendor, document the exit path, confirm the bank holds its evidence independently, and review contracts before execution and periodically afterward.