On April 17, 2026, the Office of the Comptroller of the Currency, the Federal Reserve, and the Federal Deposit Insurance Corporation jointly issued revised guidance on model risk management, replacing the framework supervised institutions had worked under since the SR 11-7 era. It is guidance: it sets out supervisory expectations, and examiners read an institution’s practices against it. It is not a rule, and it is not a court decision.
Most of the revision is continuity. The discipline it describes is the one banks already recognize. A model should be developed with evidence, documented so that a competent reviewer can follow it, validated by someone independent of the people who built it, monitored against realized outcomes, and changed only under control.
One part is not continuity, and it is the part that reaches outside the bank. The revised guidance treats generative and agentic AI as sitting outside the validated-model framework institutions apply to the models they rely on. Such systems can still be used, and they carry expectations of their own. They are simply not the thing that gets validated and then relied upon as a model. For anyone producing analytics that a credit committee will lean on, that boundary is the whole story.
What counts as a model, and what validation asks of it
Under the guidance a model is, in substance, a quantitative method that takes inputs, applies theory or technique, and produces an output an institution uses to make a decision. The label does not depend on the software. A spreadsheet is a model if a decision rests on its output. So is a dispatch optimizer. So is a pro forma.
Validation, in practice, asks four questions.
Is the design defensible? Development evidence covers the theory behind the method, why it was chosen over the alternatives, and what it is known not to handle. A method with no stated limits is a method nobody has tested at the edges.
Can a reviewer follow it without the author in the room? Documentation is the deliverable, not a by-product. If the only route to understanding a result is asking the person who produced it, the result cannot be validated.
Does it perform? Outcomes analysis compares modeled results against what actually happened, on a schedule, with the differences explained rather than absorbed.
Is change controlled? Versioning, change logs, and the ability to regenerate an earlier result on demand. If last quarter’s number cannot be reproduced, there is nothing to compare this quarter’s against.
Three of those four are about evidence and traceability rather than mathematics. That is usually where third-party analytics fail review.
Why the generative AI boundary reaches the vendor
An institution that relies on an external analytics provider does not outsource the expectation along with the work. The institution remains responsible for understanding and validating the models informing its decisions, whoever built them. In practice, the vendor has to hand over enough to satisfy a reviewer who was not present when the work was done.
Now set the exclusion next to that. If a figure in a credit memo came out of a generative model, the institution is relying on an output its own validated-model framework does not cover. The difficulty is not that the figure is necessarily wrong. It is that the figure cannot be validated the way the framework expects: the same prompt against the same source can produce different text on a different day, and the reasoning behind the number is not recoverable in a form a reviewer can test.
Two workflows can produce an identical figure and land in completely different places under review. In the first, machine reading extracts a charge from a scanned tariff sheet, and a deterministic engine applies that charge to interval data to produce a bill. In the second, a language model is asked what the bill would be. The first is a document-intake step feeding a validated calculation. The second is a model output the framework does not recognize.
The distinction is not whether AI is present. It is where AI sits in the chain, and whether its work is checkable. CFPB Circular 2026-03, addressing adverse-action explainability, points at the same property from the consumer side: an institution has to be able to say why, specifically, in terms it can stand behind.
What this implies for storage underwriting
Storage underwriting is unusually exposed here, for a plain reason. The revenue comes from arithmetic against a tariff and a market, not from a growth assumption. What a battery is worth at a site is what it changes about the bill and what it earns in the market, computed from inputs that are all, in principle, documented somewhere. Which means the result is auditable in principle, and a reviewer will expect it to be auditable in fact.
Five properties do most of the work.
Deterministic engines. The calculation that produces a number produces the same number the next time it runs against the same inputs. This is a design decision, made once, at the point where you choose what computes the answer.
Versioned methods. Engines change: a tariff is amended, a market rule is revised, a modeling choice is improved. A result should carry the version of the method that produced it, so a figure from March can be explained in September without archaeology.
Input manifests. Every run should be able to state exactly what went into it: which meter file, which tariff version, which market data, which assumptions. A result whose inputs are not enumerable cannot be reproduced, and a result that cannot be reproduced cannot be validated.
Source traceability. Each extracted value points back to the document and the location on the page it came from. That is what converts a spreadsheet cell into evidence.
AI confined to intake. Paperwork arrives as paperwork: scanned bills, tariff filings, meter exports in inconsistent shapes. Machine reading is genuinely good at turning that into structured values. Keeping it there, with human-checkable provenance on every value, keeps it out of the part of the chain that gets validated.
None of this is exotic. It is ordinary engineering discipline applied deliberately and early, because retrofitting reproducibility onto a workflow that was not built for it is close to impossible.
Questions a credit team should ask any analytics vendor
Most of the distance can be covered with a handful of direct questions.
- Which numbers in this output were produced by a language model, and which by a deterministic calculation?
- If we run this again in six months against the same inputs, do we get the same result? What would make it change?
- Can you show us the version of the method that produced this figure, and what has changed since?
- For any extracted value, can you show us the source document and the location on the page?
- What are the stated limitations of the method, and which conditions is it known to handle poorly?
- What documentation would you give our validation group, and has anyone reviewed it before?
- How are modeled results compared against realized performance, and who sees the differences?
A vendor that answers these easily has thought about review. A vendor that finds them unusual has not.
The short version
The revised guidance did not make model risk management harder. It drew a line, and it drew it in a place that rewards work already built to be checked. For storage underwriting the practical reading is short: keep generative AI on the paperwork, keep the arithmetic deterministic and versioned, and keep every input to every number enumerable.
Utilyzed is built to that standard, and the methodology behind it is readable without a login.