Short answer: how do bank examiners view AI underwriting tools in 2026? As workflow technology that has to be classified honestly, governed proportionately, and kept inside visible human decision authority. After April 17, 2026, the current supervisory guidance is no longer SR 11-7 by itself. It is the revised interagency guidance issued through SR 26-2 and OCC Bulletin 2026-13, with OCC Bulletin 2025-26 still shaping proportionality for community banks.
That means the first examiner question is no longer just "is this an AI tool?" It is "what, exactly, is this stack?" Which parts are deterministic workflow software? Which parts are model-driven quantitative estimates? Which parts use generative features? If your bank cannot answer that cleanly, the control story will sound underdefined.
The good news is the standard is still practical. Community banks do not need a money-center model risk program for every analyst-assist workflow. They do need a documented inventory, a validation posture that matches the risk, a visible override path, and records that let an examiner reconstruct the file without calling the vendor. If you want the companion explainer on the April 2026 shift itself, read what OCC Bulletin 2026-13 means for community banks using AI in underwriting.
This guide expands the regulatory and readiness pieces of the AI-Assisted Underwriting Playbook into the version you would hand to a chief credit officer, model risk owner, or examiner prep team. If you need the workflow side next, pair it with AI underwriting use cases already in production, the AI underwriting implementation guide, and what examiners actually ask about AI in lending.
Scannable summary
How do bank examiners view AI underwriting tools after April 2026?
| Question | 2026 answer |
|---|---|
| What is the current guidance? | The revised interagency guidance issued through SR 26-2 and OCC Bulletin 2026-13. SR 11-7 was superseded on April 17, 2026. |
| Does every AI feature count as a model? | No. The revised guidance narrows scope to complex quantitative methods and excludes simple arithmetic and deterministic rule-based software. |
| What still matters for exam readiness? | Classification, validation, monitoring, governance, vendor oversight, and a file-level audit trail that preserves human review and overrides. |
| What matters most for community banks? | OCC Bulletin 2025-26 still says validation cadence and scope should be risk-based, and annual full-scope validation is not automatic. |
Section 01
Start with the question examiners are actually asking
Most banks still frame AI governance as a technology question. Examiners frame it as a control question. They are not trying to decide whether OCR is impressive or whether a language model can summarize tax returns. They are trying to decide whether the bank understands what this tool does, where it sits in the credit process, and what happens when it is wrong.
That distinction catches teams off guard. A lender says, "This tool only helps with spreading." Maybe. But if the spread feeds the global cash flow, the memo, the committee package, and the final recommendation, the workflow matters. Examiners want to know whether the bank can classify the moving parts, validate the model pieces, preserve the human review path, and explain what changed when the vendor updated production logic.
The current guidance gives banks a cleaner way to answer. Some underwriting components may be deterministic software. Some may be models. Some may be generative features that need separate controls because the April 2026 guidance explicitly leaves them out of scope. The hard part is not memorizing the bulletin. The hard part is documenting the product map clearly enough that a chief credit officer, internal audit, and an examiner would all describe it the same way.
Practical line: examiners do not need you to call every AI feature a model. They do need you to know which parts are models, which parts are not, and what controls sit around each one.
Section 02
What changed when SR 26-2 and OCC Bulletin 2026-13 replaced SR 11-7
1. SR 11-7 is not the current guidance anymore
The revised interagency guidance issued on April 17, 2026 superseded and replaced SR 11-7. That matters because a lot of AI lending content, vendor decks, and even internal bank notes still talk as if SR 11-7 is the live guidance. It is not. If your documentation still frames examiner readiness as "SR 11-7 plus community-bank clarification," it is stale.
2. The definition of a model is narrower
The revised guidance defines a model as a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates. It also explicitly excludes simple arithmetic calculations and deterministic rule-based processes or software. That is a real shift for underwriting teams evaluating vendors that bundle workflow software, statistical estimation, and generative features into one product story.
Probably not a model under current guidance
Deterministic document routing, fixed checklist logic, simple spreadsheet-style ratio rollups, and policy thresholds that always do the same thing with the same inputs.
Likely still a model
Probabilistic scoring, quantitative estimation, trained risk classification, or other outputs driven by statistical, economic, or financial modeling rather than fixed rules.
3. The old habits still matter, even though the label changed
The revised guidance still centers the same serious disciplines banks should care about: model development and use, validation and monitoring, governance and controls, and considerations for vendor and third-party products. So the practical spine of examiner readiness did not disappear. The bank still needs documentation, a validation posture that matches the risk, monitoring after go-live, and governance that survives staff turnover.
- Classification: know what part of the workflow is deterministic, what part is model logic, and what part is generative assistance.
- Validation: test model-driven outputs on your own document mix, especially the ugly files, not the vendor's clean demo pack.
- Monitoring: track overrides, regressions after vendor changes, and where the workflow breaks by form type or deal shape.
- Governance: preserve human decision authority, version history, and a record that lets someone cold-read the file later.
4. The guidance is expected to matter most above $30 billion, but smaller banks should not tune out
The revised guidance says it is expected to be most relevant to banking organizations with over $30 billion in total assets. That is important context, especially for larger regional and super-regional institutions building deeper model stacks. But the same guidance also says it may still matter for banks at $30 billion or less when model risk exposure is significant because of the prevalence or complexity of models, or because of activity outside traditional community banking.
Do not over-read the asset threshold: it is a relevance signal, not an invitation for community banks to stop classifying vendor AI honestly.
5. Generative and agentic AI being out of scope is not a free pass
OCC Bulletin 2026-13 says generative AI and agentic AI are not within the scope of this guidance. That does not mean memo drafting, analyst chat, or document Q&A features are invisible to examiners. It means banks should not pretend the April 2026 bulletin settled those control questions. Community banks still need usage rules, data handling boundaries, human review, and product-level controls for those features. That is one reason the OCC 2026-13 explainer matters as a companion read.
Section 03
What OCC Bulletin 2025-26 still does for community banks
OCC Bulletin 2025-26 did not get erased by the April 2026 update. It is still the clearest proportionality explainer for community banks. The bulletin says community banks can 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. It also says OCC guidance should not be interpreted to require annual model validation.
That matters because smaller institutions can now read the stack more cleanly. Bulletin 2026-13 helps classify what is and is not a model. Bulletin 2025-26 helps decide how heavy the bank's validation and monitoring posture should be for the model pieces that remain. Read together, they push community banks toward a tighter answer than either one alone.
| What 2025-26 still does | What it still does not do |
|---|---|
| Confirms validation cadence and scope should be risk-based for community banks | Eliminate inventory, change control, or oversight responsibilities |
| Says annual model validation is not automatically required | Let a bank skip validation because the vendor says the tool is low risk |
| Tells exam teams not to criticize validation frequency or scope by itself when the bank made a reasonable risk-based decision | Protect a bank whose controls, documentation, or override path are weak |
| Gives smaller institutions room to stay proportional | Transfer accountability from the institution to the vendor |
The real operating answer for community banks after April 17, 2026 is simple. First classify the workflow honestly. Then govern the model-driven parts with validation and monitoring proportionate to the actual risk. Then put generative assistance under separate data and review controls. That approach is easier to defend in examiner prep than either "everything is a model" or "nothing here counts because the vendor called it automation."
If you need a shorter practical summary for the credit team, the companion post on OCC Bulletin 2026-13 and community-bank AI underwriting is the best handoff note. This guide is the fuller examiner-prep version.
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 software role, the model role if one exists, the human role, and the required record. Then you need the product to enforce that matrix in code.
| Function | System role | Human decision authority | Examiner-ready record |
|---|---|---|---|
| Document ingestion | Classifies files, matches them to checklist items, and logs completeness | Human confirms missing items and exceptions | File inventory, timestamps, missing-item log |
| Spreading and extraction | Extracts fields, computes spreads, maps entities, and preserves citations | Human reviews, corrects, and signs off | Original value, override value, user, reason, timestamp, source citation |
| Ratio and trend analysis | Calculates DSCR, leverage, liquidity, and trend views | Human validates interpretation against policy and context | Formula trace, inputs, review attestation |
| Risk flagging | Applies policy thresholds and surfaces exceptions | Human dispositions each flag | Flag log, dismissal reason, escalation record |
| Memo support | Assembles facts, spreads, and cited support | Human authors narrative and recommendation | Named author, cited support, approval chain |
| Credit decision | None | Human officer or committee approves, conditions, or declines | Final recommendation, approver identity, conditions, timestamps |
System may propose
- Classify documents
- Extract fields
- Compute ratios
- Generate flags
- Assemble memo support
No credit authority
Humans must decide
- Whether outputs are correct
- Whether exceptions matter
- Whether a deal fits policy
- What narrative goes to committee
- Whether the loan advances
Full decision authority
The record must preserve
- What the system produced
- What the human changed
- Why it changed
- Who acted
- When it happened
Queryable during an exam
If you are evaluating tools for spreading, tax return analysis, or memo support, this matrix is the fastest serious filter. If a vendor cannot show how the product preserves original outputs, captures overrides, and prevents silent machine approvals, the exam conversation will get worse later. That is true whether the underlying feature is deterministic software, a model, or a generative assistant.
Section 05
The five examiner questions, updated for the current guidance
These are still the questions that separate banks that understand their control environment from banks that bought software and hoped compliance would sort itself out.
Question 1
"Show me the inventory, and show me how you classified the workflow."
Under the current guidance, a good answer does more than list vendor names. It shows which parts of the workflow are deterministic software, which parts qualify as models, which parts use generative assistance, what decision authority each part has, who owns it, what version is live, and what controls apply. If the tool contains multiple AI components, classify them separately.
Weak answer
"We use Vendor X for spreading and memo prep. Compliance has the contract somewhere."
Good answer
"Here is the inventory. Here is the classified workflow map. Here is what we treat as model logic, what we treat as deterministic software, and what controls sit around the generative assistant."
Question 2
"Walk me through what happens when the system is wrong."
Examiners love this because it exposes whether the institution built for reality or screenshots. A good answer shows the actual override flow, not a theoretical one. Pick a real example where the system misread officer compensation, missed a continuation schedule, or mapped a K-1 incorrectly. Show the original output, the human correction, the recorded reason, and whether the case fed any monitoring metric.
Weak answer
"Our underwriters would catch it."
Good answer
"Here is the original output, here is the override, here is who made it, here is why, and here is how the case rolled into monitoring after the correction."
Question 3
"If I pull a random loan file, can you reconstruct the decision lifecycle right now?"
This is the audit trail test. The file should show document receipt, extraction, human review, overrides, flags, memo authorship, approval, and any later changes. Not in four systems that require manual stitching. In a form a reviewer can follow live. If your answer depends on waiting for IT to export logs, the lifecycle is not actually examiner-ready.
Question 4
"How do you handle changes in model logic or vendor updates?"
This is where weak change management gets exposed. Every meaningful update should have a record of what changed, what the vendor said the impact would be, what dataset the bank used to test it, what happened to known edge cases, who approved production release, and what post-release monitoring followed. If the vendor can update production logic without your team knowing which version is live, you do not control the workflow.
Question 5
"What guardrails exist around generative features and human review?"
Because generative and agentic AI sit outside the scope of the April 2026 guidance, examiners will still care about how you constrained them. Can the assistant draft only from approved sources? Does it preserve citations? Can it move a file forward on its own? Does a human author the final memo and recommendation? If those boundaries are fuzzy, the control environment is fuzzy too.
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.
- Classified workflow inventory. Current production state, owners, decision authority, versions, and which parts are deterministic, model-driven, or generative.
- Validation memo. Dataset design, document mix, accuracy results, override patterns, and conclusions about intended use.
- Decision authority matrix. Signed off internally and reflected in product controls.
- Change management log. Version history, release notes, re-testing evidence, and approvals.
- Operational monitoring. Override rates, exception trends, flagged edge cases, and remediation actions.
- Third-party risk and data controls file. Data flow, training restrictions, retention, hosting posture, and security documentation for any AI or generative features touching borrower data.
None of this needs to be enormous. That is still the point of OCC Bulletin 2025-26. A community bank should not be forced into a 200-page validation book for a narrow analyst-assistance workflow. But the artifact should be good enough that an examiner can follow the control logic without a tour guide.
Best operating habit: keep one current commercial file bookmarked as your demonstration file. If you can walk it cleanly in under five minutes, you are probably ready.
Section 07
Where community banks still get this wrong
- They keep citing SR 11-7 as if nothing changed. It makes the documentation look old before the discussion even starts.
- They treat the whole product as one black box. Under current guidance, classification matters. Not every component is the same control problem.
- They confuse a vendor packet with a bank control framework. Useful input, wrong owner.
- They overfocus on average accuracy. Examiners care more about overrides, edge cases, update discipline, and whether humans can still show their work.
- They treat generative features as marketing frosting. If those features touch borrower data or committee materials, they need explicit controls.
The point is not to make the program look sophisticated. The point is to make it legible. Good community-bank AI governance should feel like a tight credit administration function, not a science project with a vendor login.
Frequently asked questions
How do bank examiners view AI underwriting tools in 2026?
Examiners view AI underwriting tools as workflow technology that has to be classified honestly, governed proportionately, and kept inside visible human decision authority. The current supervisory frame is the April 17, 2026 revised interagency guidance issued through SR 26-2 and OCC Bulletin 2026-13, with OCC Bulletin 2025-26 shaping proportionality at community banks. The first question is no longer "is this AI" — it is "what part of this stack is deterministic software, what part is a model under the revised definition, and what part is a generative feature with its own control problem." Banks that classify cleanly and keep override authority visible pass exam reviews; banks that call everything AI without distinguishing the components do not.
Is SR 11-7 still the current guidance for AI underwriting tools?
No. The April 17, 2026 revised interagency guidance issued through SR 26-2 and OCC Bulletin 2026-13 superseded SR 11-7. The practical disciplines banks learned from SR 11-7, like validation, monitoring, governance, and vendor oversight, still matter. But the current supervisory frame is the revised 2026 guidance, with OCC Bulletin 2025-26 still important for proportionality at community banks.
Does every AI underwriting feature count as a model under the revised 2026 guidance?
No. The revised guidance narrows the definition. It covers complex quantitative methods that apply statistical, economic, or financial theories to produce quantitative estimates. It excludes simple arithmetic and deterministic rule-based software. That means a bank should classify the stack honestly instead of calling every feature a model or pretending none of it is one.
Do community banks still need annual model validation for AI underwriting tools?
No. OCC Bulletin 2025-26 says community banks can tailor the frequency and scope of validation based on risk exposures, business activity, and the complexity and extent of model use. It also says OCC guidance should not be interpreted to require annual model validation.
Does vendor AI change who owns model risk and examiner accountability?
No. The bank still owns the inventory entry, validation posture, override authority, change management, and monitoring. Vendor documentation helps, but it does not transfer accountability away from the institution.
What should a bank have ready before an AI underwriting exam?
A classified inventory of the workflow, evidence of what is deterministic software versus model logic, validation work proportionate to the actual risk, human override records, change management history, and a file you can reconstruct live from source document through final credit decision.
What should community banks do with generative AI features after OCC Bulletin 2026-13?
Treat them as a separate control problem. The bulletin says generative AI and agentic AI are out of scope of that guidance, not exempt from governance. Banks still need usage rules, data controls, human review, and clear boundaries on what those features can and cannot do in underwriting.
How this works in practice: Aloan was built so lending teams can show their work under scrutiny. Document extraction, spreading, risk flags, and memo support preserve source citations, override history, and human decision authority. If you want to pressure-test that workflow against your own policy and exam expectations, start with the demo.
Go deeper: Read the playbook section on what regulators expect, the companion post on OCC Bulletin 2026-13, and the workflow guide on AI underwriting use cases. For the CRE-portfolio side examiners check first, the CRE concentration ratio calculator runs both interagency supervisory criteria (100% CLD and 300% total CRE) against Tier 1 plus ACL with headroom and the 36-month growth flag.