NAIC AI Bulletin vs SR 11-7 for Insurers With Bank Affiliates, Including the 2026 Federal Reserve Revision

What changed and what this comparison covers

The NAIC adopted its Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on December 4, 2023. It is principles-based guidance. It reminds insurers that decisions or actions affecting consumers, when made or supported by advanced analytical and computational technologies including AI, must comply with all applicable insurance laws and regulations. It expects insurers to develop and maintain a written program for the responsible use of AI.

SR 11-7 was issued by the Federal Reserve and, as OCC Bulletin 2011-12, by the OCC. The FDIC adopted the same supervisory guidance on model risk management in 2017. On April 17, 2026, the Federal Reserve published a letter titled Revised Guidance on Model Risk Management. Bank affiliates should therefore treat the current Federal Reserve text as the authority for their own supervisory expectations.

This comparison uses the concepts that have defined SR 11-7 since its adoption: development, validation, ongoing monitoring and effective challenge. It sets them against the NAIC's program-centered approach. State adoption of the bulletin varies, so the NAIC side applies in the states where the insurer operates and where the bulletin or an equivalent requirement is in force.

Side by side: what each framework centers on

The table summarizes how an examiner would approach each dimension. It separates what each framework emphasizes from what it leaves to the institution.

• Scope: NAIC: AI systems used by insurers, including predictive models, where decisions or actions affect consumers. SR 11-7: models. The FDIC expects its adoption to generally pertain to FDIC-supervised institutions with $1 billion or more in total assets.
• Unit of oversight: NAIC: the written AI program for the insurer. SR 11-7: the individual model and its lifecycle.
• Governance: NAIC: program-level governance and accountability sitting with the insurer. SR 11-7: effective challenge, meaning critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate changes.
• Third-party and vendor oversight: NAIC: third-party oversight is a named element of the program. SR 11-7: vendor models fall within the model risk framework and are expected to be understood and validated like internal ones.
• Validation and testing: NAIC: verification and testing methods are encouraged to identify errors and bias and the potential for unfair discrimination. SR 11-7: disciplined, well-documented development and effective validation processes.
• Documentation and evidence: NAIC: documentation of the program and its controls. SR 11-7: documentation of development, validation, monitoring and challenge. Neither, as described, specifies runtime behavior evidence.

Where the frameworks overlap and where they diverge

The overlap is real. Both expect documented accountability, both expect testing or validation that looks for errors, and both expect the institution to show that results feed back into decisions. A control that records who owns an AI use, how it was tested and what happened to the findings is useful to either examiner.

The divergence is mostly about the unit of oversight and the vocabulary. An insurer's AI program is a portfolio-level construct. A bank model inventory is a list of discrete models, each with its own validation history. A single underwriting or claims-triage system, or a shared vendor service, may sit in the insurer's AI program, in the bank affiliate's model inventory, or in both. Where an insurer and a bank affiliate share AI systems or vendors, it helps to record which framework governs each use and which supervisor the owner answers to. Neither framework prescribes this.

The other point is tooling. The legal and regulatory framework for financial institutions is broadly technology neutral. Neither framework mandates a specific product or architecture, so the institution decides how to meet the expectation and what evidence demonstrates it.

The gap neither framework fills explicitly: runtime behavior

Both frameworks, as described, emphasize lifecycle activities: development, validation, testing and program documentation. These establish that a system was built and assessed responsibly. They do not by themselves show what a system did on a specific interaction in production.

This section is analysis, not a stated requirement of either framework. An examiner reviewing an AI system in production may reasonably ask what the system was permitted to do, what it actually did on a given interaction or tool call, which policy decisions were applied, and whether a human approved a consequential action. That evidence relates to the NAIC program as proof that stated controls operate in practice. It relates to SR 11-7 ongoing monitoring as a record of production behavior against the limits set during validation.

Runtime evidence complements validation and testing documentation. It does not replace them. A single evidence set is practical only if it is organized so it can be mapped separately to program documentation for state regulators and to validation and monitoring artifacts for bank supervisors. The NIST AI Risk Management Framework, which is voluntary, can serve as a shared reference vocabulary, though neither regulator is described as requiring it.

Evaluating a combined approach

A practical approach starts with scope. Map each AI use to the framework or frameworks that apply, then assign one accountable owner per use. Keep validation reports, monitoring records and program documents in a structure that allows each to be cited by either examiner. Treat runtime evidence as a separate layer with its own retention and access rules.

The tradeoff is specificity. Reusing one artifact across two examinations saves effort, but an artifact written for a model validation audience may not answer a program-level question, and the reverse is also true. Plan for a shared evidence base with framework-specific views rather than a single document that tries to satisfy both.

Where Trussed fits

Insurance is where Trussed is deepest. Trussed enforces policy in the execution path, on individual interactions and tool calls, across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction can be allowed, redacted, blocked, rate limited or escalated for human approval. Enforcement is applied at runtime, not reviewed after the fact, and it generates continuous audit-ready evidence mapped to NAIC and NIST, among other frameworks.

This addresses the runtime evidence question above: what the system was allowed to do and what it did. It does not replace model validation, pre-deployment testing or model inventory processes, which both frameworks continue to expect. Trussed does not claim bank or other financial-services deployments. Its production record is in regulated enterprises, including 18+ months of continuous production in one regulated enterprise and 99.95% uptime on live production traffic, and it can be self-managed in the customer cloud with configurable retention and data residency.

Neither framework requires a particular tool. The question for a risk leader is whether the runtime evidence you can produce would hold up when an examiner asks for it.