How SR 26-2 Applies to Machine Learning Credit Underwriting Models

How SR 26-2 reaches machine learning underwriting models

The practical question for a model risk leader is not whether a gradient-boosted ensemble or a neural network counts as a model in a different sense than a scorecard. It is which obligations attach to the model and at what stage each one can be met. The technique does not change that a system producing a creditworthiness determination is a model to be governed.

Regulation B gives a useful anchor for this. It defines a credit scoring system as one that evaluates an applicant's creditworthiness mechanically, based on key attributes of the applicant and aspects of the transaction, and that determines, alone or with additional information, whether the applicant is deemed creditworthy. A machine learning underwriting model that does this fits the definition whatever its architecture. Opacity, drift, frequent retraining and use across several systems make the model harder to govern. They do not take it out of scope.

The working method is to start from the model inventory entry for each underwriting model and sort every SR 26-2 expectation by the stage at which it can be satisfied and evidenced. That sort is the basis for showing a supervisor how controls were applied to a specific model.

Obligations met before deployment

Development, documentation and independent validation happen before a model version reaches production, and their evidence is produced by the development and validation process. Regulation B illustrates the point. To qualify as an empirically derived, demonstrably and statistically sound system, a credit scoring system must be based on data from an empirical comparison of creditworthy and non-creditworthy applicants who applied within a reasonable preceding period. It must also be developed to evaluate creditworthiness in line with the creditor's legitimate business interests. Both are properties of how the model was built. No runtime control can establish them after the fact.

Explainability belongs here as well. Regulation B and ECOA require adverse action notices to be specific and to indicate the principal reasons for the action. A Congressional Research Service report notes that an overly complex model may make this difficult. It also notes that a bank's inability to explain model results may be a supervisory concern, because banks must understand the theory and logic of their models. For machine learning, this means validating that principal-reason explanations can be produced from model outputs before the model is approved for use.

Vendor-supplied models need the same treatment. Regulation B permits a creditor to use a qualifying system obtained from another person. The proposed NYDFS circular letter states that insurers remain responsible for compliance when relying on external vendors' models. The inventory should record whether each model is internally developed or vendor-obtained, and what documentation can be obtained for each.

Separating pre-deployment and production-time obligations

The table below shows the split for a single underwriting model. Which stage each expectation falls into should be confirmed against the SR 26-2 text for your entity.

• Model development and documentation: Pre-deployment. Evidence: design records, data selection rationale, intended-use statement. Runtime enforcement does not substitute.
• Independent validation: Pre-deployment and at revalidation after material retraining. Evidence: validation reports and findings. Runtime enforcement does not substitute.
• Ongoing performance monitoring: Production, but analytical. Drift and outcome analysis is a model-level activity. Runtime records can supply inputs but do not perform the analysis.
• Permitted use and limits: Production-time. Enforced on each interaction. Evidence: policy applied and decision taken.
• Human escalation: Production-time. Enforced where a policy requires approval. Evidence: who was asked, what was decided.
• Records of what the model did: Production-time. Evidence: interaction-level records tied to the policy in force at that moment.

Obligations that depend on production controls and evidence

Once a model is approved, a different question arises: is it being used only as approved? The documented intended use, the limits on what the model may do, the conditions under which a person must review its output, and the records showing what happened are all production-time matters. A validation report cannot show that a given underwriting call on a given day stayed inside the approved limits.

Machine learning makes this gap wider. Frequent retraining means the approved version may not be the one running. Use across several systems and decision points means one model may be called from places its validators never considered. A supervisor or auditor would reasonably ask for specific artifacts: the approved use and limits for the model, the policy that implemented them, the policy version in force at a given time, records of interactions that were allowed, modified or blocked, and records of cases escalated for human approval with the outcome.

The test is whether these artifacts exist for the specific underwriting model, not for AI in general. Evidence that describes a program but cannot be traced to one model and one point in time rarely answers an examiner's question.

Applicability to insurance-sector entities

SR 26-2 is a Federal Reserve document, so its reach to an insurance entity depends on whether that entity is supervised by the Federal Reserve. The Federal Reserve does examine model risk within governance and controls at supervised insurance organizations. A 2025 Federal Register notice on the large financial institution rating system observes that these organizations often rely heavily on models for pricing, reserving, risk and capital management and other decisions. That notice does not mention credit underwriting models specifically, so entity-level scoping should be documented rather than assumed.

State insurance regimes sit alongside it. The NAIC adopted its Model Bulletin on the Use of Artificial Intelligence Systems by Insurers at its 2023 Fall National Meeting. Whether it applies to a given carrier depends on state adoption. NYDFS has published a proposed circular letter on AI systems and external consumer data in underwriting and pricing. As of November 2026 it should be read as proposed. It defines AI systems around medical, property or casualty underwriting and pricing, and it states that insurers should not use such systems unless they can establish that the data source or model is not based in any way on a protected class under Insurance Law Article 26.

A carrier may therefore face more than one regime for different models. Record, for each underwriting model, which regimes apply, and keep one body of evidence that can be presented against each.

What runtime enforcement evidences, and what it does not

Policy enforcement in the execution path applies rules to individual model interactions and tool calls as they occur: allow, redact, block, rate limit, or escalate for human approval. Because the decision is enforced at runtime, not reviewed after the fact, the record it produces shows what the model was permitted to do and what it did, under the policy in force at that moment. That maps directly onto permitted use, limits, escalation and records of use. Trussed does this in the execution path and generates audit-ready evidence mapped to NAIC and NYDFS requirements. It has run 18+ months in continuous production in a regulated enterprise, with 100+ models under one policy plane.

The limits are as important as the capability. Runtime enforcement does not validate a model, assess its conceptual soundness, or replace independent validation. It does not establish model lineage or dataset provenance, and Trussed does not provide either. It does not perform drift analysis or decide whether a retrained model needs revalidation. Its scope is individual interactions and tool calls, not business transaction identity across tasks and agents.

To judge whether runtime evidence supports your controls, ask four questions. Can the record be tied to a specific underwriting model and policy version? Does it show the action taken, including blocks and escalations? Is it retained for the period your examiners expect? Can it be produced without reconstructing events from other systems? If the answer to each is yes, the evidence strengthens the production-time half of the model risk file. Validation and development evidence must still stand on its own.