A model risk management (MRM) audit is the assurance engagement over the framework a bank or other organization uses to govern its models: the policy that defines what a model is and how it is tiered, the inventory that lists them, the standards for building and implementing them, the validation function that independently challenges them, the monitoring that checks they keep working, the handling of vendor models, and the remediation of the issues validation finds. It is a second-line framework audit, like the operational risk and enterprise risk audits, with one distinctive feature: the subject matter is quantitative, and the auditor has to decide how far to re-perform the technical work of validators rather than assess the process that produced it.
This guide gives the program. It covers the criteria, which changed in April 2026 when the Federal Reserve, OCC and FDIC issued updated interagency guidance (SR 26-2 at the Federal Reserve) replacing the 2011 guidance known as SR 11-7; scoping and the proportionality the new guidance stresses; the nine audit areas with test steps and evidence; how to sample validations and what to re-perform; where end-user computing tools and artificial intelligence sit in relation to the model definition; the findings that recur; and a worked example of a regional bank’s audit that found a deposit assumption problem before the examiners did. It extends the site’s model risk explainers, ten things auditors must know, model risk and algorithm audit and vendor model validation, into a testable program, and it is one of the second-line entities in the bank audit universe.
In this guide
- Criteria: the 2026 guidance and what changed from SR 11-7
- Scoping with proportionality in mind
- Area 1: governance, policy and roles
- Area 2: model definition and inventory completeness
- Area 3: tiering and risk rating
- Area 4: development, implementation and documentation
- Area 5: validation coverage, independence and quality
- Area 6: ongoing monitoring and outcomes analysis
- Area 7: vendor and third-party models
- Area 8: issue remediation and model use restrictions
- Area 9: reporting to committees and the board
- Sampling validations and what to re-perform
- End-user computing and AI: where they sit
- The work program
- Findings that recur
- Worked example: Lakeshore Bancorp finds the deposit assumption problem first
- Questions about auditing model risk management
- Related guides
Criteria: the 2026 guidance and what changed from SR 11-7
From 2011 the reference for model risk management in US banking was the interagency Supervisory Guidance on Model Risk Management, issued by the Federal Reserve as SR 11-7 and by the OCC as Bulletin 2011-12, which defined a model as a quantitative method applying statistical, economic, financial or mathematical theories, techniques and assumptions to process input data into quantitative estimates, and set expectations for development, implementation and use, validation (conceptual soundness, ongoing monitoring and outcomes analysis) and governance (policies, roles, inventory and documentation). On 17 April 2026 the Federal Reserve, OCC and FDIC issued updated interagency guidance that replaced it (SR 26-2 at the Federal Reserve, with the OCC’s and FDIC’s issuances). The core framework is retained, with four changes an auditor measures against. Proportionality: the guidance states that practices should be scaled to the complexity, materiality and use of each model and to the institution’s size and risk profile, and that smaller institutions may concentrate on material, higher-risk models rather than treating every tool as a model. The definition: the revised language excludes simple arithmetic calculations such as those typically found in spreadsheets, while leaving complex spreadsheet tools with forecasting or estimation logic within scope. Applicability: the guidance is most directly relevant to institutions above about $30 billion in assets while remaining the reference, scaled, for all. Vendor models: institutions remain fully responsible for third-party models, with the expectation of conceptual understanding and appropriate validation regardless of the vendor’s own testing. The guidance does not address artificial intelligence, which the agencies indicated would be covered separately. The bank’s own policy, written to the guidance, is the primary criterion; the ten things guide covers the vocabulary.
| Element | SR 11-7 (2011) | 2026 interagency guidance | Audit implication |
|---|---|---|---|
| Model definition | Broad quantitative method definition; many banks swept in spreadsheets | Simple arithmetic spreadsheet calculations excluded; complex estimation tools still in | Test the bank’s boundary decisions on EUCs against the revised definition; look for both over- and under-inclusion |
| Proportionality | Implied through risk-based tiering | Explicit: scale practices to model and institution risk | Test that tiering drives differentiated validation depth and frequency, and that “proportionate” is not a label for “none” |
| Validation elements | Conceptual soundness, ongoing monitoring, outcomes analysis | Retained with flexibility in implementation | Test each element’s presence per tier, allowing for documented proportionate approaches |
| Vendor models | Expected validation with vendor cooperation | Institution fully responsible; conceptual understanding required | Test vendor model validation for substance, not vendor paperwork on file (guide) |
| Governance and inventory | Policies, roles, inventory, documentation | Retained | Inventory completeness remains the central test |
| Artificial intelligence | Not contemplated | Not addressed; separate agency work signaled | Test the bank’s own policy for AI tools; expect gaps; report the policy choice rather than a guidance breach |
Scoping with proportionality in mind
The engagement covers the framework, not the models: individual model audits (of the CECL allowance model, the ALM model, the BSA monitoring system) are separate engagements or components of process audits, and the framework audit asks whether the machinery that governs all of them works. Scope decisions to record in the planning memo: the criteria (the bank’s policy and the 2026 guidance, with the proportionate practices the bank has chosen documented as criteria rather than as findings); the period (the last full validation cycle); the sample of models for tracing (below); whether vendor models, EUCs and AI tools are in scope (they should be, at least for inventory testing); and the technical depth of re-performance, which depends on the function’s skills and the co-source available. A full framework audit at a mid-size bank runs 350 to 450 hours; Lakeshore budgets 420 with 180 hours of co-sourced quantitative review. The audit team should include someone who can read a validation report critically, which usually means a co-source quant or a former validator, because an audit that assesses validation only by whether reports exist has not audited validation.
Area 1: governance, policy and roles
The tests: a board-approved model risk policy exists, defines a model and the tiering, assigns roles (model owners, developers, users, the validation function, the model risk committee) and is current to the 2026 guidance; the model risk function is independent of model development and use, with reporting lines that protect it (typically to the chief risk officer) and resources proportionate to the inventory; a model risk committee or equivalent meets, approves tiering and validation plans, decides on model use restrictions and receives issue reporting; and the board or its risk committee receives model risk reporting at least annually. Evidence: the policy and its approval, organization charts, committee charters and minutes, the function’s budget and headcount against the inventory. The finding to look for is a policy updated for the new guidance’s vocabulary but with the same inventory and validation practices as before, or a validation function of two people for an inventory of seventy models, which proportionality does not excuse for the models in the top tier.
Area 2: model definition and inventory completeness
| Test | Method | Evidence |
|---|---|---|
| Definition applied | Review the bank’s documented boundary decisions (what was assessed and excluded as “not a model”) against the revised definition; sample ten exclusions and ten inclusions | Model determination records |
| Completeness against systems | Compare the inventory with the application inventory, the vendor inventory (third-party program) and the finance and risk functions’ tool lists; every application with estimation or scoring logic has a determination | Reconciliations |
| Completeness against end-user computing | Compare with the EUC inventory (the EUC audit‘s Tier 1 list); every Tier 1 spreadsheet with forecasting, valuation or estimation logic has a determination | EUC inventory; determinations |
| Completeness against regulatory processes | Confirm the models behind the allowance, capital planning, liquidity, interest rate risk, BSA monitoring and sanctions screening, fraud detection, credit scoring and pricing are all inventoried | Process walkthroughs; inventory |
| Attributes | Each inventory record carries owner, developer, user, vendor status, tier, purpose, inputs and outputs, implementation date, validation status and dates, open issues and use restrictions | Inventory extract; attribute completeness analysis |
| Change discipline | New models, material changes and retirements in the period entered the inventory through the governed process | Change log; committee minutes |
Inventory completeness is the central test because everything downstream (tiering, validation, monitoring, reporting) applies only to what is inventoried. The BSA/AML test at Lakeshore found the sanctions screening system outside the inventory; the framework audit’s reconciliation is designed to find such gaps across the whole bank.
Area 3: tiering and risk rating
Tiering is where proportionality lives: the bank rates each model’s risk (materiality of the decisions it informs, complexity, reliance, regulatory use, data quality) and sets validation depth, frequency and monitoring intensity by tier. The tests: the tiering methodology is documented with anchored criteria; a sample of fifteen models is re-tiered by the auditor from the inventory attributes and the use of each model, and disagreements analyzed; tier drives something (the validation schedule and scope differ by tier in fact, not only in policy); and tier changes follow use changes (a model promoted from analytical use to a regulatory calculation is re-tiered). The risk matrix guide’s calibration discipline applies; the finding pattern is a tiering that puts 70 percent of models in the middle tier and validates them all the same way.
Area 4: development, implementation and documentation
The tests: development standards exist (purpose, design, theory, data, testing, limitations, assumptions) and a sample of recently developed or materially changed models’ documentation meets them; implementation testing confirmed that the production model matches the developed one (code review, parallel runs, reconciliations) and that inputs flow correctly from source systems; assumption governance requires documentation and independent review of material assumption changes, with a log of changes in the period and evidence of review (this is where the Lakeshore deposit assumption finding lived); model documentation is sufficient for an independent party to understand and, in principle, reproduce the model; and changes to models in production go through change control with validation involvement proportionate to the change. Evidence: development documents for the sample, implementation test records, the assumption change log, change control records. The IT change management guide covers the platform side.
Area 5: validation coverage, independence and quality
| Test | Method | Finding pattern |
|---|---|---|
| Coverage | Every model validated at the frequency its tier requires; the validation plan for the period compared with completion; overdue validations listed with the reason and the interim measures | Top-tier models past their validation date; a plan the function could not deliver |
| Independence | Validators did not develop or own the models they validated; organizational separation; for small functions, the external validation used where independence is otherwise impossible | Developer-validated models; validation reporting to the model owner |
| Scope of each validation | Each validation in the sample addresses conceptual soundness (theory, design, assumptions, limitations), data and inputs, implementation, ongoing monitoring design and outcomes analysis, with depth proportionate to tier | Validations that review documentation and stop; no outcomes analysis |
| Quality of challenge | Co-source or skilled auditor reads the sample’s validation reports and judges whether the key conclusions follow from the evidence; re-performs one or two key tests (a sensitivity, a back-test) | Conclusions asserted; limitations accepted without challenge; the validator’s test could not be reproduced |
| Findings and rating | Validation findings rated by a documented scale; the model’s overall rating and any use restrictions follow from the findings | A model with three high findings rated fit for use without restriction |
| Validator competence | Qualifications and experience of validators against the models’ complexity; training records | Validators without the quantitative background the top tier requires |
Area 6: ongoing monitoring and outcomes analysis
Validation at a point in time is not enough; models drift as the world changes, and the guidance expects ongoing monitoring (performance metrics, stability, input quality, override rates, limit breaches) and outcomes analysis (back-testing predictions against outcomes) at a frequency proportionate to tier. The tests: each top-tier model has a monitoring plan with defined metrics, thresholds and owners; monitoring was performed in the period and results reviewed; threshold breaches triggered the documented response (investigation, re-calibration, escalation); back-testing results for predictive models exist and are analyzed; overrides of model outputs are logged, justified and analyzed for patterns; and monitoring results feed the next validation. Evidence: monitoring plans and reports for the sample, breach logs, override reports. The KRI program guide’s escalation discipline is the same one; the deposit beta guide shows what outcomes analysis of a behavioral assumption looks like.
Area 7: vendor and third-party models
Most mid-size banks run their highest-impact models on vendor platforms (the allowance, asset-liability management, credit scoring, BSA monitoring, sanctions screening, fraud detection), and the 2026 guidance’s statement that institutions remain fully responsible is the criterion. The tests: vendor models are inventoried and tiered like any other; the bank has obtained and reviewed the vendor’s development documentation and testing evidence, with gaps identified; the bank validated the model in its own context (data, configuration, calibration, use) rather than filing the vendor’s generic validation; configuration and parameter choices made by the bank are documented, governed and reviewed; vendor releases are assessed for model changes and tested; and contingency arrangements exist for critical vendor models (the concentration question). The vendor model validation guide gives the detailed method; the finding pattern is a vendor whitepaper in the validation file in place of a validation.
Area 8: issue remediation and model use restrictions
Validation produces findings, and the framework’s credibility rests on what happens to them. The tests: a single issue log carries all validation findings with ratings, owners, due dates and status; aging is measured and reported; closures are evidenced (the validator or model risk function confirms remediation, not the owner); overdue high findings trigger escalation to the committee; use restrictions (a model may be used only with overlays, only for certain purposes, or not at all) are imposed where findings warrant, communicated to users and lifted only on evidence; and management overlays applied to compensate for model weaknesses are governed, documented and time-limited. The issue validation discipline applies with one addition: internal audit samples closed validation findings and re-performs the closure test, because a model risk function that closes its own findings on the owner’s word has the same weakness as a management team that does.
Area 9: reporting to committees and the board
The tests: the model risk committee receives, at each meeting, the inventory status, validation plan progress and overdue items, new and changed models, open findings by rating and age, use restrictions in force, and monitoring breaches; the board or its risk committee receives an annual (at least) model risk report with the inventory summary by tier, validation coverage, the significant findings and the function’s own assessment of model risk against the appetite; and the reporting is accurate, tested by tracing the last two reports to the inventory and issue log. The audit committee calendar places model risk among the deep dives for banks; the finding pattern is a board that has never been told which models are overdue for validation or operating under restriction.
Sampling validations and what to re-perform
The model sample for areas 3 to 8 is judgmental and small: eight to twelve models, including every top-tier model that informs a regulatory calculation or a board decision (the allowance, asset-liability management, capital stress testing, BSA monitoring), two vendor models, one model materially changed in the period, one recently inventoried EUC and one model under use restriction. For each, the auditor reads the development documentation, the latest validation report, the monitoring reports and the issue log entries, and traces the chain from inventory record to board report. Re-performance is targeted: one or two of each validation’s key tests (a sensitivity analysis on a critical assumption, a back-test of a forecast against outcomes, a reconciliation of a model input to its source), chosen because the validation’s conclusion depends on them, performed by the co-source quant or skilled auditor, and documented so the committee can see that the function tested substance. The judgmental sampling guide covers the documentation; the cost lesson is that re-performing everything is impossible and re-performing nothing is not an audit.
End-user computing and AI: where they sit
Two boundary questions recur. End-user computing tools: the revised definition excludes simple arithmetic spreadsheets but keeps complex tools with estimation or forecasting logic, so the bank needs documented determinations for its Tier 1 EUCs (Lakeshore’s inventory of 212 EUCs with 31 in Tier 1, from the EUC audit, is the population), and the auditor tests both directions: spreadsheets treated as models that need not be, consuming validation capacity, and estimation tools treated as spreadsheets that escape it. Artificial intelligence and machine learning: the 2026 guidance does not address them and the agencies signaled separate work, so the criterion is the bank’s own policy; most banks treat machine learning models used for decisions (credit scoring, fraud detection) as models within the framework with additional validation elements (explainability, bias testing, data drift), and treat generative AI tools under a separate policy of the kind the AI usage policy guide describes. The auditor reports the bank’s policy choices and tests conformance to them, and the auditing AI and algorithms guide covers the model-level assessment.
The work program
| Step | Area | Procedure | Hours |
|---|---|---|---|
| 1 | Planning | Criteria, scope, model sample, co-source engagement, planning memo | 30 |
| 2 | Governance | Policy currency to the 2026 guidance; roles and independence; committee effectiveness; resources | 35 |
| 3 | Inventory | Determination review; reconciliations to application, vendor and EUC inventories and regulatory processes; attribute completeness | 60 |
| 4 | Tiering | Methodology review; re-tier fifteen models; tier-to-practice test | 25 |
| 5 | Development and implementation | Documentation standards on the sample; implementation testing; assumption governance log | 45 |
| 6 | Validation | Coverage against plan; independence; scope and quality on the sample; targeted re-performance (co-source) | 120 |
| 7 | Monitoring | Monitoring plans, results, breaches, overrides, back-tests on the sample | 35 |
| 8 | Vendor models | Vendor documentation, bank-context validation, configuration governance, release testing on the two vendor models | 30 |
| 9 | Remediation | Issue log; aging; evidenced closures; use restrictions and overlays | 25 |
| 10 | Reporting | Committee and board reporting traced to inventory and log | 15 |
| 11 | Conclusion | Findings, ratings, closing meeting, report | 40 |
| Total | 460 |
Findings that recur
| Finding | Area | Why it persists | Rating usually |
|---|---|---|---|
| Inventory incomplete | 2 | No reconciliation to systems and EUCs; functions decide for themselves what is a model | High if a regulatory or decision model is missing |
| Assumption changes without independent review | 4 | Assumption governance treated as the owner’s business; validation sees changes only at the next cycle | High for top-tier models |
| Validations overdue or shallow | 5 | Function under-resourced for the inventory; proportionality used to justify absence | High for top tier; Medium otherwise |
| Vendor models not validated in context | 7 | Vendor paperwork filed as validation | High for regulatory models |
| Monitoring not performed or not acted on | 6 | Metrics defined at validation and never produced | Medium |
| Findings closed on owner assertion | 8 | Model risk function lacks capacity to re-test | Medium to High |
| Tiering undifferentiated | 3 | Tier assigned once and never revisited; one validation approach for all | Medium |
| Board not told what is overdue or restricted | 9 | Reporting designed to reassure | Medium |
| Policy updated, practice not | 1 | Guidance change absorbed as a vocabulary exercise | Medium, with others as evidence |
Worked example: Lakeshore Bancorp finds the deposit assumption problem first
Lakeshore Bancorp is a $9 billion publicly traded regional bank holding company used in examples across this site, with a lead bank supervised by the OCC, a model risk management function of four within the risk organization and a 22-person internal audit function that audits the framework annually as a high-rated entity in its universe, with 180 hours of co-sourced quantitative review. The audit described here ran in the year the bank’s policy was updated for the 2026 guidance and some months before the OCC’s full-scope examination; its inventory then held 64 models, 14 in the top tier, of which 9 were vendor platforms.
| Area | What the audit found | Rating |
|---|---|---|
| Governance | Policy updated for the 2026 guidance with proportionate practices documented by tier; committee effective; function of four adequate for the top tier only with the co-source it used | Satisfactory |
| Inventory | Reconciliation to the application inventory found the sanctions screening system absent (confirmed independently by the BSA test); reconciliation to the 31 Tier 1 EUCs found two estimation spreadsheets (a loan pricing tool and a liquidity forecast) without determinations; 61 of 64 inventory records attribute-complete | Medium |
| Tiering | Re-tiering of 15 models agreed on 13; two credit scoring models tiered below their regulatory use | Low |
| Development and assumption governance | The ALM model’s non-maturity deposit average-life assumptions had been lengthened from 4.1 to 6.8 years in the fourth quarter of the prior year on the basis of 2015 to 2021 data, by the treasury function, without independent review by model risk management, and the change had moved the +200 basis point EVE result from outside the board limit to inside it; the assumption log showed the change approved by ALCO on treasury’s recommendation alone | High |
| Validation | All 14 top-tier models validated within cycle; co-source re-performance of two key tests (ALM model rate shock sensitivity; CECL back-test) reproduced the validators’ results; the ALM validation, performed before the assumption change, had flagged assumption governance as a limitation without a finding | Medium (the limitation should have been a finding) |
| Monitoring | Monitoring in place for 12 of 14 top-tier models; the two credit scoring models’ override rates not analyzed | Medium |
| Vendor models | CECL and BSA monitoring platforms validated in the bank’s context; the fraud scoring platform’s validation relied on the vendor’s documentation with no bank-context testing | Medium |
| Remediation | Issue log sound; three closures sampled, all evidenced; one overlay (on the CECL qualitative factors) in place for 14 months without a documented end state | Low |
| Reporting | Committee reporting complete; the board’s annual report omitted the ALM limitation and the overlay | Medium |
The High finding on deposit assumption governance went to the audit committee two months after the change with the re-run figures: under the prior assumption the +200 EVE result had been −16.2 percent against a −15 percent limit, and under the new one −11.6 percent, so that the assumption change, unreviewed, had moved the bank from outside its limit to inside it. The committee required an independent model risk review, which supported an average life of 5.3 years and an EVE result of −14.1 percent, inside the limit but by less than the board had been told; the governance standard requiring independent review of material assumption changes followed. When the OCC’s examination arrived four months later, the examiners issued a matter requiring attention on the same facts (the field guide follows it to closure), credited the function’s finding and relied on its validation of the remediation. The chief audit executive’s observation to the committee was that the finding had cost the co-source quant about six hours of reading the assumption log and asking who had reviewed each line, and that the framework’s weakness had been visible to anyone who asked that question of a document the bank already held; the EVE versus NII and deposit beta guides carry the technical content of what the question found.
Questions about auditing model risk management
What replaced SR 11-7?
Updated interagency guidance on model risk management issued by the Federal Reserve, OCC and FDIC on 17 April 2026 (SR 26-2 at the Federal Reserve). It retains the development, validation and governance framework while stressing proportionality, excluding simple arithmetic spreadsheet calculations from the model definition and restating institutions’ full responsibility for vendor models; it does not address artificial intelligence.
What is the most important test in a model risk management audit?
Inventory completeness, because everything else applies only to inventoried models: reconcile the inventory to the application, vendor and end-user computing inventories and to the regulatory processes, and test the bank’s determinations of what is and is not a model.
Does internal audit need quantitative skills to audit model risk?
To audit the framework, mostly not; to audit validation quality, yes, for the targeted re-performance of key tests. Most mid-size functions co-source a quantitative reviewer for that part and keep the framework audit in-house.
How are vendor models audited?
By testing that the bank inventoried and tiered them, obtained and reviewed the vendor’s documentation, validated the model in its own data and configuration rather than filing the vendor’s generic testing, governs its configuration choices and tests vendor releases. The 2026 guidance states the bank remains fully responsible.
Are spreadsheets models?
Simple arithmetic calculations are excluded under the 2026 guidance; spreadsheets with estimation, forecasting or valuation logic can still be models. The bank needs documented determinations for its significant end-user computing tools, and the audit tests both over- and under-inclusion.
How does proportionality affect the audit?
The bank may scale validation depth and frequency to model and institution risk, and the audit tests the bank’s documented proportionate practices as criteria. Proportionality does not excuse absent validation, monitoring or governance for the top tier, and the audit says so when it is used that way.
How often should the framework be audited?
Annually in most banks above a few billion dollars in assets, because examiners test it every cycle and the inventory and validation plan change every year; smaller institutions audit it every two to three years with inventory completeness checked annually.
Related guides
- 10 things internal auditors must know about model risk — the vocabulary.
- Model risk and algorithm audit — validating the models management relies on.
- Model risk simplified — the explainer.
- Vendor model validation — the method for third-party models.
- End-user computing audit — the EUC inventory the model inventory reconciles to.
- Auditing AI and algorithms — model-level assessment of machine learning.
- AI usage policy for internal audit — generative AI outside the model framework.
- Deposit beta modeling — the assumption behind the High finding.
- EVE vs NII — the measures the assumption moved.
- Interest rate risk — the model’s purpose.
- How to audit the BSA/AML program — monitoring and screening systems as models.
- The bank internal audit universe — model risk management as a second-line entity.
- Internal audit in banking — the supervisory context.
- MRAs, MRIAs and consent orders — the finding’s regulatory afterlife.
- How to audit operational risk management — the sibling framework audit.
- Auditing the ERM program — the enterprise framework audit.
- Issue validation — evidenced closure of validation findings.
- Judgmental sampling — documenting the model sample.
- IT change management audit — the platform side of model changes.
- The audit committee annual agenda — model risk as a deep dive.
- SR 11-7 and SR 26-2 Explained: Model Risk Guidance Compared — what changed when SR 26-2 replaced SR 11-7 in 2026.
- Auditing AI Governance: A Program for the NIST AI RMF Era — a program for auditing AI governance in the NIST AI RMF era.
- Auditing Agentic AI: Authority, Logging and Kill Switches — authority limits, identities, logging, kill switches and prompt injection tests.
- Auditing Trading Floor Controls: Limits to Rogue Traders — limits, trade capture, confirmations, cancel-and-amend red flags and the classic failures.
Leave a Reply