Model risk management for underwriting asks whether the tools behind a credit decision work as intended and whether anyone would notice if they stopped. For bank statement analysis software, that means deciding which outputs count as models, keeping an inventory, validating outputs against hand-checked files, monitoring after updates and documenting each step.
What model risk management for underwriting means under SR 26-2
Model risk management for underwriting now follows SR 26-2, the revised guidance the Federal Reserve, the FDIC and the OCC issued on April 17, 2026. It replaced SR 11-7, the 2011 guidance most lenders knew. The new guidance is risk-based, is expected to matter most to banking organizations with over $30 billion in assets, and does not set enforceable standards.
The Federal Reserve's SR 26-2 cover letter says it supersedes SR 11-7 and SR 21-8, the 2021 statement on models used for Bank Secrecy Act compliance. The revised guidance on model risk management says non-compliance with it will not result in supervisory criticism on its own. It adds that supervisory action can still follow from violations of law or unsafe practices that stem from poor management of model risk.
That changes the tone more than the substance for a lending team. The ideas are familiar: know which models you use, understand their limits, test them, watch them and write it down. What is new is a clearer line around what counts as a model, and a plain statement that smaller institutions and simpler tools warrant less.
Model risk, in the guidance's words, is the potential for adverse financial consequences from decisions based on model output. In underwriting, the consequence is a loan approved on income that was not there, or a good borrower declined on income that was.
Is bank statement analysis software an underwriting model?
Bank statement analysis software is partly a model and partly not, depending on what each output does. SR 26-2 defines a model as a complex quantitative method that applies statistical, economic or financial theories to turn input data into estimates. It excludes simple arithmetic, such as spreadsheet calculations, and deterministic rule-based processes with no such theory behind them.
Split the tool's outputs and test each one against that definition:
- Monthly deposit totals and averages. Arithmetic. A sum of deposits divided by the number of months is not a model under the guidance.
- Rule-based flags. A deposit flagged because it exceeds a fixed share of the monthly average is a deterministic rule. The post on large deposits on bank statements shows the kind of thresholds underwriters apply.
- Transaction categorization. It depends how it is built. A fixed keyword list is a rule. A classifier trained on past transactions applies statistical methods and is closer to a model.
- Scores or predicted outcomes. A cash flow score that estimates default risk is a model by any reading.
The guidance also excludes generative and agentic AI from its scope, while saying the lender's own governance should still decide controls for those tools. It keeps traditional statistical models and non-generative AI inside.
Outputs outside the definition still need controls. An average that excludes the wrong transfers is still wrong. The difference is that a lender can test arithmetic and rules with ordinary checks rather than a full model validation.
Ask the vendor how each output is produced. A lender cannot classify a tool it does not understand, and the answer belongs in the inventory.
Model inventory entries for underwriting software
A model inventory is the lender's list of models in use or in development, with enough information to understand each one's risk. SR 26-2 calls it common industry practice and says the level of detail can vary with a model's complexity. For underwriting software, one entry per tool output that affects a decision is usually enough.
The guidance frames risk in two parts. Inherent risk comes from the model's assumptions, complexity, input quality and data limits. Materiality comes from exposure, meaning how much business depends on the output, and purpose, meaning what the output is used for. A tool that sets qualifying income on every mortgage file is material. A tool that only drafts a summary for the underwriter to rewrite is less so.
A practical inventory entry records:
- Tool and vendor. Name, version and the date it went into use.
- Output. What it produces, such as average monthly qualifying deposits.
- Classification. Model, rule or arithmetic, with the reason.
- Use. Which loan products rely on it, and whether a person reviews every output.
- Inputs. Statement types it reads and any known limits, such as scanned pages.
- Risk tier. High, medium or low, with the reason.
- Owner. The person accountable for it.
- Last validation and next review. Dates.
Keep the entries current. An inventory written at purchase and never touched again shows a reviewer that no one is watching.
Validating a vendor's statement analysis outputs before underwriting use
Validating a vendor's statement analysis outputs means checking that they are conceptually sound and match real outcomes, even without the vendor's code. SR 26-2 says vendor products may withhold code, data or methods, but the principles still apply. The lender should understand the design and performance, then test the outputs on its own files.
Conceptual soundness
Ask the vendor to explain, in writing, how each output is calculated: which transactions count as deposits, how transfers are matched, how categories are assigned. Compare that with the lender's own policy. A tool that counts every credit as a deposit does not fit a policy that excludes owner transfers, however accurate its arithmetic.
Outcomes analysis
Outcomes analysis compares outputs to real results. For a statement tool, the practical version is a sample of files where an experienced underwriter has calculated the figures by hand. The worked example below shows one such sample. All values are examples for illustration.
| Sample file | Months | Hand-calculated qualifying deposits | Tool output | Difference | Cause found |
|---|---|---|---|---|---|
| A, landscaping LLC | 12 | $31,420 | $31,420 | 0.0% | None |
| B, dental practice | 12 | $88,150 | $88,150 | 0.0% | None |
| C, sole proprietor, two accounts | 24 | $12,980 | $14,105 | +8.7% | Transfer between accounts not matched, savings statements missing from upload |
| D, scanned statements | 6 | $9,640 | $9,640 | 0.0% | None |
| E, restaurant | 12 | $52,300 | $51,870 | -0.8% | One refund reversal categorized as an expense |
File C is the useful row. The tool was not wrong about the data it had. It lacked the second account, so it could not see the matching debit. The finding is a process fix: require both accounts before running the analysis. File E is a categorization edge case to note as a known limitation.
Tools that link every total back to the statement lines behind it make this kind of test quick. TrueBankFlow works that way, so a validator can open a monthly figure and see which deposits made it up. TrueBankFlow is onboarding lending teams in small groups, and you can request a spot to try it on your own sample files.
Keep the sample, the results and the conclusions. They are the validation record.
Ongoing monitoring and change logs for underwriting tools
Ongoing monitoring checks whether an underwriting tool keeps performing as expected as products, borrowers, data and conditions change. SR 26-2 says a model that no longer performs as expected may need overlays, adjustment or redevelopment. For vendor software, the biggest source of change is the vendor's own updates.
Keep a change log with one line per vendor release that affects an output: the date, what changed and whether the lender retested. Ask the vendor for release notes that name changes to calculations or categories. A silent change to transfer matching can move qualifying income on every file.
Monitoring between releases can be light. Pick a few files each quarter, recheck one figure by hand, and record the result. Watch for drift in what the tool reads: a large bank redesigning its statement layout, or a rise in scanned uploads, can affect accuracy before any code changes.
Watch the data side too. Validation samples and test files contain borrower personal information. California residents' data in those files may fall under state privacy law, as the post on CCPA for lenders and where GLBA stops explains. Keep test sets small, access-controlled and deleted when no longer needed.
Some outputs leave the underwriting file. A gross revenue figure drawn from statements may feed data a lender reports under the section 1071 small business lending rule. An error there spreads into a regulatory report, which raises the output's materiality.
What do examiners ask about model risk in underwriting software?
The questions examiners ask about underwriting software can be read from SR 26-2 itself: does the lender know its tools, did it test them, and does it watch them? Its sections on inventory, validation, monitoring, governance and documentation point to the records a reviewer will want. Have them ready before the request.
The records that answer most questions:
- The inventory, with classification and risk tier for each tool.
- The validation record, with sample files, results and the conclusions drawn.
- The change log, showing vendor updates and whether each was retested.
- Monitoring results, even when nothing went wrong.
- Known limitations, and the controls for each, such as requiring both accounts before analysis.
- Roles, naming who owns each tool and who reviewed the validation.
SR 26-2 also describes effective challenge: critical review by people with the expertise, independence and standing to make changes. On a small team, that can mean the validation is reviewed by a senior underwriter or the compliance officer, not the person who chose the tool. The guidance says quality of review matters more than organizational structure.
Documentation is the thread. The guidance notes that it supports continuity, including tracking recommendations, responses and exceptions.
When formal model risk management is more than an underwriting desk needs
Formal model risk management is more than an underwriting desk needs when the tools are simple, every output gets human review and the lender is small. SR 26-2 says banking organizations with $30 billion or less in assets are generally outside its scope, and that a simple operation need not apply the same rigor as a complex one.
Being outside the guidance is not the same as having no controls. A nonbank lender or a community bank still answers for loans approved on wrong figures. The scaled-down version is short: a one-page inventory, a validation sample at go-live, a check after each vendor release that touches calculations, and notes kept in one place.
The mistake to avoid is the opposite one. A lender that adds a vendor cash flow score to its decline rules has moved a tool from arithmetic into model territory, and from low materiality to high. When the use changes, the guidance says to analyze the new use and review the controls. Do that before the first file runs under the new rule, not after the first complaint.