A working AI governance program at a community bank fits on four artifacts: a decision-authority matrix that names who can override AI outputs, a model inventory that classifies each workflow component, a validation test plan sized to the actual risk, and a quarterly monitoring report that tracks performance and drift. The rest of the controls — vendor oversight, change management, override records — hang off those four.
After the April 17, 2026 revised interagency guidance issued through SR 26-2 and OCC Bulletin 2026-13, the classification step matters more than it used to. Deterministic software, generative drafting, and quantitative models all sit in the AI underwriting stack, and each carries different validation expectations. A spreading tool that applies fixed rules is deterministic software. A risk-rating module that estimates default probability with statistical methods is a quantitative model. The governance controls scale with that classification.
What follows is a set of templates sized for a sub-$10B bank: the decision-authority matrix, the model inventory rows, a proportional validation test plan, and a quarterly monitoring report outline. They expand on the governance and validation sections of the AI-Assisted Underwriting Playbook and pair with the AI underwriting practical guide, the AI underwriting implementation guide, how bank examiners view AI underwriting tools, and what examiners actually ask about AI in lending for the regulatory context.
Decision-authority matrix (template)
The decision-authority matrix answers a question every exam team raises: when the AI output disagrees with the underwriter, who has the final call? The matrix has to make clear that the human with lending authority owns the decision and that any override is recorded.
The template below is a starting point. Fill in your bank's roles, approval thresholds, and override requirements. The rows that examiners look at first are AI-assisted spreading, AI-generated memo recommendations, and any model-driven risk estimates. Where the tool can recommend but not decide, the matrix should say so in plain language.
| Workflow step | AI role | Human decision authority | Override approval required |
|---|---|---|---|
| Document upload and classification | Automated classification and routing | Analyst verifies classification | None (deterministic) |
| Financial statement spreading | Automated extraction with source citations | Analyst reviews, adjusts, approves spread | Analyst approval required before memo draft |
| Ratio calculation and trend analysis | Automated calculation from approved spread | Analyst confirms ratios match policy | Senior analyst if ratios fall outside expected range |
| Credit memo draft generation | Generates narrative from spread and ratios | Analyst edits, approves, signs final memo | Analyst owns final memo content |
| Risk rating recommendation (if model-driven) | Outputs quantitative risk estimate | Senior analyst or chief credit officer assigns final rating | Chief credit officer if override moves rating more than one notch |
| Final credit decision | None | Per existing lending authority matrix | Per existing lending authority matrix |
Why this matters for examiners: The matrix is the document the exam team will reach for when they ask who owns the outcome on an AI-assisted file. A missing matrix or one that puts approval authority in the tool reads as a governance gap.
Model inventory template (one row per component)
The inventory classifies each piece of the AI underwriting workflow. Under the revised April 2026 guidance, not every AI feature is a model. Rule-based logic, arithmetic operations, and workflow automation are deterministic software. A model is a complex quantitative method that applies statistical, economic, or financial theories to produce a quantitative estimate.
A typical community-bank inventory ends up with one to three model entries (often zero) and several deterministic-software entries. Fill one row per component. Where the classification is genuinely ambiguous, document the rationale rather than defaulting to over-classification — that documentation is what an examiner reviews if they question the call later.
| Component name | Classification | Use in underwriting | Validation status | Next review |
|---|---|---|---|---|
| Document extraction engine | Deterministic software | Reads tax returns, financial statements; outputs structured data | Tested quarterly for accuracy | Q3 2026 |
| Global cash flow builder | Deterministic software | Applies bank's add-back policy to spread; calculates DSCR | Reviewed annually | Q2 2027 |
| Credit memo narrative generator | Deterministic software (template-based) | Drafts memo from approved spread and ratios; analyst edits and approves | Reviewed annually | Q2 2027 |
| Risk rating recommendation model (example) | Quantitative model | Estimates default probability using financial ratios and industry benchmarks | Validated Q1 2026; monitoring quarterly | Q1 2028 |
| Covenant monitoring alerts | Deterministic software | Compares covenant thresholds to quarterly financials; flags violations | Tested quarterly | Q3 2026 |
Proportionality note: OCC Bulletin 2025-26 says community banks can tailor validation frequency based on risk. A deterministic spreading tool with stable performance might validate every 18-24 months. A quantitative risk model might validate every 12-18 months or when material changes occur.
Validation test plan (proportional to risk)
Validation under the revised 2026 guidance covers three domains: conceptual soundness, ongoing monitoring, and outcomes analysis. At a community bank that translates into testing the tool's outputs against known-good examples, confirming it handles edge cases predictably, and watching whether performance stays consistent quarter over quarter. It does not require reverse-engineering a vendor's algorithm or rebuilding the model from scratch.
The test plan below is sized for a typical community-bank AI spreading and memo workflow. Adapt the rows to your stack. Deterministic-software components warrant lighter testing; quantitative models warrant deeper testing and more frequent monitoring.
| Validation test | What to test | Pass criteria | Frequency |
|---|---|---|---|
| Extraction accuracy | Run 20-30 known-good tax returns and financial statements through the tool | 95%+ field-level accuracy on key financial metrics (or per bank's tolerance) | Annually or when vendor updates extraction logic |
| Edge case handling | Test with multi-entity structures, K-1 distributions, restated financials | Tool flags uncertainty or analyst review required; no silent errors | Annually |
| Policy adherence | Verify add-back policy, DSCR calculation, covenant threshold logic matches bank's credit policy | 100% match to documented policy | Annually or when policy changes |
| Override rate analysis | Track how often analysts override AI-generated spreads or memo recommendations | Set threshold based on baseline; pattern review if rate increases significantly | Quarterly |
| Performance drift monitoring | Compare current-quarter extraction accuracy to baseline from initial validation | Accuracy remains within 3% of baseline | Quarterly |
| Vendor change management | Review vendor release notes and test new features before production use | No material changes deployed without bank review and testing | As vendor releases occur |
What community-bank validation is not: rebuilding a vendor's model, reading every line of source code, or duplicating an in-house model risk team's workpapers. Vendor documentation and third-party validation reports are useful inputs. The bank still owns the responsibility to test outputs against expected behavior and document the findings.
Quarterly monitoring report outline
Monitoring is where the governance program shows up in operations. A quarterly report tracks whether the AI underwriting workflow is behaving the way it was approved to behave, where analysts are overriding outputs, and whether accuracy or processing patterns have drifted from the validation baseline.
The outline below is a working template. Populate it each quarter and circulate to the model risk owner, chief credit officer, or whoever owns governance oversight at the bank. Material performance degradation or a spike in overrides should trigger a review before the next scheduled cycle.
Quarterly AI Underwriting Monitoring Report Template
1. Executive Summary
- Reporting period and number of loan files processed
- Key performance metrics: accuracy, override rate, processing time
- Material changes to the workflow or vendor platform
- Issues requiring management attention
2. Performance Metrics (vs. Baseline)
- Extraction accuracy: [current %] vs. [baseline %]
- Spread approval rate: [% of spreads approved without manual correction]
- Memo draft acceptance rate: [% of memos used with minor edits only]
- Average processing time per file: [minutes] vs. [prior quarter]
3. Override Analysis
- Total overrides: [count] ([% of total files processed])
- Override reasons: [categorize by type—extraction error, policy mismatch, analyst judgment, etc.]
- Pattern review: [any systematic issues or concentrated override triggers?]
- Escalated overrides requiring senior approval: [count]
4. Vendor and Platform Changes
- Vendor releases deployed during the quarter
- New features enabled or tested
- Performance impact of changes (positive/neutral/negative)
5. Issues and Corrective Actions
- Performance degradation or drift requiring attention
- Analyst feedback or usability concerns
- Planned updates to validation or governance controls
6. Attestation
[Model risk owner or chief credit officer signature and date]
Frequency guidance: Quarterly is the default for an active AI underwriting workflow. Mid-quarter, an override spike or accuracy degradation should produce an interim report rather than waiting for the next scheduled cycle.
What changed in April 2026 and why it matters for proportionality
The April 17, 2026 revised interagency guidance — issued through SR 26-2 and OCC Bulletin 2026-13 — superseded SR 11-7. The practical shift for community banks is a clearer boundary between what counts as a model and what is deterministic software.
Models are defined as complex quantitative methods that apply statistical, economic, or financial theories to produce quantitative estimates. Simple arithmetic and deterministic rule-based software fall outside that definition. That narrows the scope compared with how some banks read SR 11-7, where defensive over-classification often pulled every automated workflow into the model risk perimeter.
Applied to AI underwriting: a spreading tool that extracts numbers from tax returns and applies the bank's add-back policy with fixed rules is deterministic software. A credit memo generator that drafts narratives from templates without producing quantitative estimates is deterministic software. A risk-rating tool that uses statistical methods to estimate default probability is a model and warrants the corresponding validation.
OCC Bulletin 2025-26, issued in October 2025, reinforces proportionality for community banks. It states that community banks have flexibility to tailor model risk management practices — including validation frequency and scope — to their risk exposures, business activities, and the complexity and extent of model use, and that OCC guidance does not, and should not be interpreted to, require annual model validation.
Read together, these updates allow a sub-$10B bank with a stable, low-risk spreading workflow to operate on a different validation cadence than a regional bank with a credit risk model driving automated approvals. The bar is risk-based controls sized to the workflow, not a uniform checklist applied across institutions.
For the broader regulatory framing, the examiner readiness guide covers how OCC, FDIC, and NCUA exam teams approach AI underwriting tools, and the revised model risk management guidance for community-bank AI walks through SR 26-2 and OCC 2026-13 in detail.
Where to stay proportional and where not to under-build
Proportionality means sizing controls to the actual risk of the workflow. For a community bank, that often means validating less frequently when performance is stable, leaning on qualified third-party validation reports where available, and keeping documentation aligned to the way the tool is actually used rather than a generic template.
Three controls do not flex with bank size:
- A classified inventory. Each AI component in the underwriting workflow needs an entry that names it, describes what it does, and states whether it is a model under the revised guidance.
- Human decision authority on the credit file. The tool produces recommendations; a human with lending authority approves or overrides them. Overrides need to be recorded with the file so the next reviewer can see the path.
- Validation appropriate to the component. Cadence and depth can vary by risk — a stable deterministic spreading tool may validate every 18 to 24 months; a quantitative risk model typically warrants tighter cycles. Some validation has to happen on every component, even if the depth differs.
The table below is a practical sizing guide for sub-$10B banks: where to size down under proportionality, and where the bar holds regardless.
| Control area | Proportional approach (sub-$10B) | Non-negotiable minimum |
|---|---|---|
| Model inventory | Simple spreadsheet or database; one row per component | Must exist, must classify components honestly |
| Validation frequency | 12-24 months for low-risk deterministic tools; 12-18 months for models | Cannot skip validation indefinitely |
| Validation depth | Sample-based testing (20-30 files); compare to known-good results | Must independently verify outputs |
| Decision authority matrix | One-page table embedded in credit policy or governance framework | Must specify who can override and who approves final decisions |
| Override records | Track in underwriting system or spreadsheet; review quarterly | Must be visible and tied to analyst accountability |
| Vendor oversight | Annual vendor review; test new releases before production deployment | Must review vendor changes and test before use |
| Monitoring reports | Quarterly summary to model risk owner or chief credit officer | Must track performance, overrides, and drift |
When to size up: If the AI workflow directly drives credit decisions without human review, if it handles large-dollar exposures relative to capital, or if override rates suggest the tool is unreliable, proportionality does not apply. Build the governance controls to match the actual risk.
Frequently asked questions
What governance controls does a community bank need for AI underwriting tools?
A classified inventory showing what is deterministic software versus model logic, proportional validation matched to actual risk, a decision-authority matrix specifying who can override AI outputs, quarterly monitoring reports tracking performance and drift, and vendor oversight documentation. The revised April 2026 interagency guidance sets the framework; OCC Bulletin 2025-26 confirms community banks can size controls proportionately.
How often should a community bank validate AI underwriting models?
Validation frequency depends on the bank's risk exposures, business activities, and the complexity and extent of model use. OCC Bulletin 2025-26 explicitly states that OCC guidance should not be interpreted to require annual model validation. A low-complexity spreading tool with stable performance might validate every 18-24 months, while a high-stakes credit decision model might validate annually or when material changes occur.
Who should own AI governance at a community bank?
Credit leadership owns the underwriting outcomes and should drive governance day-to-day. The chief credit officer typically owns the decision-authority matrix and override approvals. Model risk management (if formalized) or an equivalent compliance/risk function owns the inventory, validation schedule, and monitoring reports. Smaller banks without a dedicated model risk function often assign this to the CFO or a senior credit executive.
What is the difference between model risk management and AI governance?
Model risk management specifically covers quantitative models that produce estimates using statistical, economic, or financial theories. AI governance is broader—it includes model risk controls where applicable, plus usage rules and human oversight for deterministic AI features, generative AI, and workflow automation that does not meet the definition of a model. Not all AI requires model risk treatment, but all AI underwriting requires governance.
Does vendor documentation satisfy validation requirements?
No. Vendor documentation helps, but the bank still owns validation responsibility. The revised guidance emphasizes that banks must independently verify the tool's performance, test outputs against expected behavior, and document findings. Vendor materials are inputs to validation, not substitutes for it.
What should a decision-authority matrix specify for AI underwriting?
Who can approve loans within AI-assisted workflows, who can override AI-generated spreads or memo recommendations, what approval thresholds apply when overrides occur, and who has final authority when the AI recommendation conflicts with the underwriter's judgment. The matrix should make clear that humans—not the tool—hold decision authority.