Examiner Readiness for AI Lending: What SR 11-7 and OCC 2025-26 Actually Require

The worst answer in an exam is not "no." It is "we'd need to check with the vendor." If AI touches spreading, ratio calculation, risk flagging, memo support, or any other step that materially informs a credit decision, the institution needs to understand exactly what that system does and how it is governed.

That does not mean every community bank needs a money-center model risk program. It does mean you need a real one. SR 11-7 gives you the core framework: model risk exists when outputs are wrong or misused, vendor models count, validation must be independent enough to create effective challenge, and governance has to be documented. OCC Bulletin 2025-26 then says the quiet part out loud for community banks: stop treating model risk management as if every workflow tool needs a full enterprise validation cycle every 12 months regardless of risk. Tailor the program to the bank's risk exposure, business activity, and model complexity.

Read together, those two documents point to a practical standard. If AI is extracting data from tax returns, calculating ratios, tracing K-1s, surfacing exceptions, or assembling memo support, the bank should be able to show what the tool is for, what its limits are, how humans override it, how changes are validated, and who owns oversight. If the system can move a loan forward without human authorization, you have a bigger problem than model documentation.

This guide expands the regulatory sections of the AI-Assisted Underwriting Playbook into the version you would actually hand to a chief credit officer, model risk owner, or examiner prep team. If you are still deciding where AI belongs operationally, start with the companion guide on AI underwriting use cases already in production. You can also browse the full guides hub if you want the complete AEO-oriented reading path. This one assumes you are past curiosity and into governance.

Section 01

Start with the question examiners are actually asking

Most banks frame AI governance as a technology question. Examiners frame it as a control question. They are not trying to decide whether OCR is good, whether language models are interesting, or whether your vendor demo looked polished. They are trying to decide whether a control environment exists around a system that affects credit analysis.

That distinction matters because it catches a lot of banks off guard. A lender will say, "This tool only spreads tax returns. It does not make the credit decision." True. But if the spread feeds the cash flow analysis, which feeds the credit memo, which feeds committee approval, then the tool sits inside the credit process and creates model risk if the outputs are wrong or misunderstood. You do not get to wave that away because a human signs the last page.

SR 11-7 defines a model broadly as a quantitative method, system, or approach that applies theories, techniques, and assumptions to process input data into quantitative estimates. That covers more than scorecards and probability-of-default engines. If your AI system extracts borrower financials, classifies documents, computes ratios, or generates quantitative risk flags, you are squarely in model risk territory. The question then becomes proportionality. How much governance is appropriate given the use case, the complexity, and the impact if it fails?

Section 02

What SR 11-7 actually says, without the hand-waving

1. Model risk comes from bad outputs and bad use

SR 11-7 says model risk exists for two primary reasons: the model can be fundamentally wrong, or it can be used incorrectly or beyond its limits. That second piece gets ignored constantly. A spreading model can be highly accurate on standard 1040s and still be dangerous if analysts assume it performs the same way on scanned, multi-entity 1065 packages with handwritten notes and missing schedules. A strong program does not just measure average accuracy. It defines the lane where the tool is trusted and the lane where extra review is required.

2. Vendor models count

The guidance is explicit that validation applies equally to models developed internally and to models purchased from or developed by vendors or consultants. This is where banks sometimes get lazy because the vendor arrives with a glossy validation deck and a SOC 2 report. Useful, yes. Sufficient, no. The bank still needs to validate the tool against its own document mix, policy framework, and workflow. If your institution underwrites owner-occupied CRE with layered guarantor structures and the vendor mostly trained on cleaner C&I packages, you need to know that before exam day, not during it.

3. Effective challenge is not optional

One of the most useful phrases in SR 11-7 is effective challenge. The guidance describes it as critical analysis by objective, informed parties who can identify model limitations and force changes. In practice, that means the people closest to the workflow must be able to question outputs, override them, document why, and feed those observations back into monitoring. If the system makes the underwriter feel like an observer instead of the accountable decision-maker, the design is backwards.

4. Validation is broader than a one-time accuracy test

SR 11-7 breaks validation into three core elements: conceptual soundness, ongoing monitoring, and outcomes analysis. That is a useful checklist for AI lending tools:

• Conceptual soundness: Is the tool designed appropriately for the use case, with documentation on data inputs, assumptions, limitations, and intended use?
• Ongoing monitoring: Are you tracking override rates, document types that fail more often, drift after updates, and cases where the tool is used outside its intended scope?
• Outcomes analysis: Can you compare AI-assisted outputs to actual spreads, actual file outcomes, or known-good benchmark results over time?

If your bank did one pilot six months ago, called the results "validated," and never revisited the tool after two model updates, that is not ongoing validation. That is wishful thinking with a PDF attached.

5. Governance has to survive staff turnover

SR 11-7 also says governance should include documentation detailed enough that someone unfamiliar with the model can understand how it operates, its assumptions, and its limitations. That matters because exams are brutal on undocumented tribal knowledge. If the only person who understands the override workflow is the credit admin who sat through implementation meetings, you do not have a governance framework. You have a witness.

The same section tells banks to maintain an inventory of models in use, under development, or recently retired. That inventory should not be a vague spreadsheet with product names. It should state what each component does, what decision authority it has, who owns it, which version is in production, what changed last, what validation was performed, and what compensating controls exist when it struggles.

Section 03

What OCC Bulletin 2025-26 changes, and what it absolutely does not

OCC Bulletin 2025-26 matters because it fixes a problem community banks have been living with for years. Risk-based guidance started getting treated like a prescriptive annual checklist. The bulletin pushes back hard on that. It says community banks have flexibility to tailor model risk management practices, including the frequency and nature of validation activities, based on risk exposures, business activities, and the complexity and extent of model use.

The most important line in the bulletin is the plainest one: the OCC's model risk management guidance does not, and should not be interpreted to, require community banks to perform annual model validation. That is a meaningful clarification for OCC-supervised institutions up to $30 billion in assets. It is not a free pass. The bulletin is saying the bank should make a reasonable, documented judgment about validation cadence. It is not saying the bank can stop validating because the tool feels low-risk.

Read carefully, the bulletin does one more important thing. It says the OCC will not provide negative supervisory feedback solely for the frequency or scope of validation that a bank reasonably determined based on its risk profile. That means your defense is not "we validate every three years." Your defense is "we classified this use case as analyst-assistance only, with no automated credit authority, with mandatory human review, with source traceability, with override logging, with quarterly monitoring, and we revalidate on material model changes. Based on that control design and observed performance, this cadence is reasonable." That is a real answer.

For banks not supervised by the OCC, do not over-read the bulletin as if it formally binds every agency. But do read it as an important supervisory signal. Community bank exam teams have been told explicitly that proportionality is not optional window dressing. It is how the guidance is supposed to work.

Section 04

The decision authority matrix is where most programs become real

A lot of AI governance documents stay abstract because they never answer the only question that matters operationally: what, exactly, can the machine do without a human? If the answer is fuzzy, the control framework is fake. You need a decision authority matrix that maps each workflow step to the AI role, the human role, and the required record. Then you need the product to enforce that matrix in code.

If you are evaluating tools for a workflow-heavy use case like tax returns or global cash flow, this matrix is a fast filter. If a vendor cannot show you how the product enforces human sign-off and preserves original outputs, stop there. You can always find another demo. You cannot explain a missing control to an examiner after the fact. If you need the operational counterpart to this governance lens, read the companion guide on AI underwriting use cases already in production.

Section 05

The five examiner questions, expanded into real answers

These are the questions that separate banks that understand their control environment from banks that bought software and hoped compliance would sort itself out.

Section 06

What the examiner packet should contain before the exam starts

If you want the exam conversation to stay controlled, prepare the packet before anyone asks. A good packet usually includes six things.

1. Model inventory. The current production state, including owners, versions, decision authority, and known limitations.
2. Validation memo. Golden dataset design, document mix, accuracy results, override patterns, and conclusions about intended use.
3. Decision authority matrix. Signed off internally and reflected in product controls.
4. Change management log. Version history, release notes, revalidation evidence, and approvals.
5. Operational monitoring. Override rates, exception trends, flagged edge cases, and any remediation actions.
6. Third-party risk and privacy file. Data flow, training restrictions, retention, US hosting posture if applicable, and security documentation. If you need the borrower-data angle broken out further, see Aloan's guide on AI data security in commercial lending.

None of this needs to be enormous. That is part of the point of OCC 2025-26. A community bank should not be forced into producing a 200-page validation book for a narrow analyst-assistance workflow. But the artifact should still be good enough that an examiner can follow the control logic without a tour guide.

Section 07

Where community banks get this wrong

• They confuse a vendor packet with a bank control framework. Useful input, wrong owner.
• They document the policy but not the product behavior. If the system can still bypass human review, the policy does not matter.
• They overfocus on average accuracy. Examiners care more about controls around edge cases, overrides, and change management.
• They skip the hard files in validation. A clean 1040 tells you almost nothing about whether the tool is ready for your real queue.
• They wait too long to socialize the program with examiners. Early conversations save pain later.

The point is not to make the program look sophisticated. The point is to make it legible. Community bank AI governance should feel like a tight, well-run credit administration function, not a science project pretending to be a policy manual.