On 17 April 2026 the Federal Reserve, FDIC and OCC jointly issued SR 26-2, "Supervisory Guidance on Model Risk Management", replacing SR 11-7, which had defined how US banks think about model risk for more than a decade. The core framework is retained — model development and use, independent validation and ongoing monitoring, and governance and controls — but with more flexibility in how institutions meet it.
The main themes: expectations are scaled by materiality and proportionality to an institution's size, complexity and reliance on models; institutions remain fully responsible for vendor and third-party models; and the guidance is most directly relevant to larger institutions, generally those above $30B in assets. SR 26-2 explicitly does not address generative AI or advanced AI tools — the agencies expect to issue separate guidance on AI.
This article is not legal advice, and banks should read supervisory guidance directly with their own counsel. Our aim is practical: what changes for teams running credit decisioning, and how to design for it.
Speed is now a model-risk question
In FinbotsAI deployments, the time from data to a production credit model has fallen from nine to twelve months to two or three weeks (Partner-reported). That is a business advantage. It is also a governance challenge, because validation, documentation and monitoring processes designed for annual model releases cannot keep up with weekly ones.
The answer is not to slow down. It is to generate the evidence as the model is built: data lineage, feature definitions, performance by segment, stability tests and reason-code logic produced automatically and reviewed by people who understand them.
Explainability that a customer can read
Under ECOA and Regulation B, a declined applicant is entitled to specific principal reasons. FCRA adds obligations where consumer reports are used. Machine-learning models can meet these requirements, but only if reason codes are designed into the scorecard rather than reverse-engineered afterwards. Every score in a well-governed system carries readable reason codes that an adverse-action notice can use directly.
Third-party models are still your models
Supervisors have been consistent: using a vendor's model does not transfer the risk. Banks need enough transparency into a third-party model to validate it, monitor it and explain its outputs. When evaluating platforms, ask for model documentation, the ability to run challenger models, access to performance data by segment, and clear contractual rights to the evidence.
Human authority, recorded
The most robust pattern we see separates the recommendation from the decision. The model recommends; an authorised credit officer approves, overrides or refers; and the system records who decided, under which policy, with which model version. Six months later, when an examiner asks why a loan was approved, the answer is a trace, not a reconstruction.
Monitoring as a first-class deliverable
Drift, stability, approval rates by segment, override rates and early-delinquency performance should be monitored from day one, with thresholds and owners agreed before go-live. Disparate-impact testing belongs in the same dashboard, not in an annual report.
Beyond the US
Banks operating across markets face overlapping expectations: the UK PRA's SS1/23 on model risk management, the EU AI Act's treatment of creditworthiness assessment as high-risk, and MAS guidance in Singapore. The common thread is the same — documented development, independent challenge, explainability, human oversight and ongoing monitoring.
What to do now
- Inventory credit models by materiality and release frequency.
- Automate documentation and reason-code generation in the build pipeline.
- Implement decision traces that record inputs, model version, policy and human authority.
- Agree monitoring thresholds and owners before the next model goes live.
Our credit platforms are designed to support SR 11-7 / SR 26-2 model-risk expectations, ECOA/Reg B adverse-action reasons, FCRA, UK PRA SS1/23, the EU AI Act and MAS guidance. Designed to support is the honest phrase: compliance is a property of how a bank operates, not of a piece of software.