Does SR 26-2 still cover traditional machine learning credit models?

Start with the guidance text, not the modeling technique

Supervisory guidance sets its scope through three things: how it defines a model, what institutions and activities it says it applies to, and how it relates to earlier guidance. Those passages are where any conclusion about credit models should start, and any internal scoping memo should quote them directly.

Technique labels such as "traditional machine learning" are rarely what scope turns on. Function is. A logistic regression and a gradient-boosted ensemble both take applicant and transaction attributes and return a score or decision that feeds underwriting or pricing. A definition built around quantitative methods that produce estimates used in decisions will not usually separate the two on technique alone.

It helps to keep two categories apart. Stated requirements are what the text says. Interpretation is what your institution concludes from it. A June 2024 Treasury request for information described regulators' model risk management principles as technology-agnostic, while also saying they may not be applicable to certain AI models and tools. A reasonable reading is that the boundary question is more open for complex AI tools than for traditional scoring models. That is an interpretation, and it should be recorded as one, with the reasoning and the approver.

Credit obligations apply however scope is read

Even if a scoping question were unresolved, credit models carry obligations that do not depend on model risk guidance. Regulation B 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 determines whether the applicant is deemed creditworthy, alone or with other information. Its criteria for an empirically derived, demonstrably and statistically sound system include being based on data from an empirical comparison of creditworthy and non-creditworthy applicants within a reasonable preceding period. Regulation B also states that a creditor may use such a system obtained from another person. These provisions are current in the eCFR as of November 2026.

Adverse action is the second pressure point. CFPB Circular 2022-03 states that ECOA and Regulation B require a statement of specific reasons when adverse action is taken, and notes that complex black-box algorithms can make it difficult, if not impossible, to identify those reasons accurately. A boosted-tree model with weak reason-code mapping is therefore a compliance question independent of model inventory status.

Pricing models need a separate check. The risk-based pricing rules in 12 CFR Part 1022 Subpart H apply to consumer credit and exclude credit extended primarily for a business purpose. One related caution: 12 CFR Part 1254 sets standards for how an Enterprise validates and approves credit score models used in its mortgage purchase procedures. It should not be presented as a bank model risk management requirement.

Which model risk disciplines remain relevant

The Treasury request for information summarized existing model risk management guidance as covering model development, use, validation including vendor and third-party models, ongoing monitoring, outcome analysis, and governance and controls. For a traditional ML credit model, each of those maps to an operating practice most risk teams already run.

Inventory: the model, its owner, its purpose and the decisions it feeds, including vendor-supplied scores used in underwriting or pricing. Validation: independent review of conceptual soundness, data and performance, scaled to the model's complexity and materiality. Ongoing monitoring and outcome analysis: performance, stability and fair lending outcomes after deployment. Governance and documentation: approvals, change records, limitations and exceptions.

Machine learning adds specific risks that sharpen these tasks. A Congressional Research Service overview describes dynamic updating, where models evolve over time without oversight, and models that do not perform as intended, with possible higher loan losses in new market environments or discrimination against protected groups. A 2021 interagency request for information states that overfitting is not unique to AI but can be more pronounced there than in traditional models. Both point to controlled retraining, change approval and out-of-time monitoring.

Where the guidance leaves room for judgment, such as how deep validation should go for a given model or how change is defined for a periodically retrained model, record the decision and rationale. Examiners generally look for reasoning that is consistent and documented, not only for a conclusion.

Where runtime policy enforcement and audit-ready evidence fit

This section is the publisher's position, not a statement of what SR 26-2 requires. Validation, inventory and monitoring are model-level disciplines. They do not by themselves show what a production system was permitted to do on a given day, or what it did. That operational layer is where runtime policy enforcement sits alongside model governance.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Policy is enforced at runtime, not reviewed after the fact, with outcomes such as allow, redact, block, rate limit or escalate for human approval, applied at the level of individual interactions and tool calls. Each enforcement decision produces audit-ready evidence, which gives a model risk or compliance team a record of policy decisions and exceptions for models that run through that path. Trussed runs under one policy plane across 100+ models and is deployed self-managed in the customer cloud, with configurable retention and data residency.

The boundaries matter. Trussed does not perform model validation, and it does not provide model lineage or dataset provenance. It is not a model risk management or compliance-certification product. Its evidence complements validation reports and monitoring results. It does not replace them. Whether a given credit scoring service sits in an enforceable execution path depends on how it is called, so the architecture review should establish that before any control is counted on.