If your bank uses a credit scoring model, an interest rate risk model, an ALCO model, a BSA transaction monitoring system, or an allowance for credit losses methodology, you have models. And if you have models, examiners expect some form of model risk management. The question isn't whether MRM applies to your bank; it's how much rigor your MRM program needs relative to your model inventory and risk profile. This guide covers the regulatory framework, what qualifies as a "model," what validation means for community banks, and how to approach vendor models.
Key Takeaways:
- OCC Bulletin 2011-12 and Federal Reserve SR 11-7 define the model risk management framework applicable to all supervised banks
- A "model" is any quantitative method that processes inputs to produce quantitative outputs used for decision-making, this includes vendor systems
- Community banks are not exempt from MRM but may apply a proportional approach based on model complexity and usage
- Vendor models require the same governance as internally developed models, the bank cannot outsource model risk
The Regulatory Framework: OCC 2011-12 and SR 11-7
Two companion supervisory documents define the MRM framework for U.S. banks:
OCC Bulletin 2011-12: Supervisory Guidance on Model Risk Management: Issued by the OCC in April 2011, this bulletin applies to national banks and federal savings associations. It establishes expectations for model development, implementation, validation, and governance.
Federal Reserve SR 11-7: Supervisory Guidance on Model Risk Management: Issued by the Federal Reserve Board in April 2011, this letter applies to state member banks and bank holding companies. The substance is identical to OCC 2011-12, the agencies coordinated the release.
For FDIC-supervised banks, the FDIC has adopted the OCC/Federal Reserve framework as its supervisory standard, though it has not issued a separate standalone bulletin.
The guidance defines model risk as the potential for adverse consequences from decisions based on incorrect or misused models. Model risk arises from two sources: (1) the model itself may be flawed (errors in design, methodology, or implementation), and (2) the model may be used inappropriately (applied to situations outside its intended scope or relied on without understanding its limitations).
What Counts as a "Model"
The regulatory definition is broad. A model is:
A quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates.
Three components define a model:
- An information input component, data and assumptions that feed the model
- A processing component, the methodology, mathematics, or algorithms that transform inputs into outputs
- A reporting component, quantitative outputs used to inform decisions
Under this definition, the following common community bank tools qualify as models:
- ALCO/interest rate risk models (rate shock analysis, net interest income simulation, economic value of equity)
- Allowance for credit losses (ACL) methodology, particularly under CECL, which requires forward-looking loss estimates
- Credit scoring models (FICO, internal scoring, behavioral scoring)
- BSA/AML transaction monitoring systems, the rules and thresholds that generate alerts
- Loan pricing models
- Stress testing models (even informal stress tests)
- Appraisal review models (AVMs, automated valuation models)
- Vendor-provided fair lending analytics
- ALM prepayment models
What does NOT qualify as a model:
- Simple calculations without statistical methodology (e.g., a basic interest accrual calculation)
- Static reports that present data without transformation
- Spreadsheets that perform arithmetic without statistical estimation
The line between "model" and "tool" is judgment-based. When in doubt, examiners apply the three-component test: inputs, processing methodology, and quantitative outputs used for decisions.
Model Validation Requirements
Model validation is an independent assessment of model quality, appropriateness, and limitations. OCC 2011-12 describes validation as having three core elements:
1. Conceptual Soundness
Is the model's methodology appropriate for its intended use? Does the underlying theory make sense? For a CECL model, this means evaluating whether the loss estimation methodology (cohort, vintage, probability of default, etc.) is appropriate for the bank's loan portfolio composition and data availability.
Conceptual soundness review doesn't require a PhD in statistics. For community banks using vendor models, it means understanding the vendor's methodology documentation, what assumptions the model makes, what data it requires, and what limitations the vendor discloses.
2. Outcomes Analysis (Back-Testing)
Does the model produce accurate results? Back-testing compares model predictions to actual outcomes over a meaningful time period. For an ACL model, this means comparing predicted loss rates to actual loss experience. For an interest rate risk model, it means comparing projected NII or EVE to actual results.
Back-testing should be conducted at least annually and whenever significant changes occur in the portfolio, market conditions, or model parameters. The results should be documented, including an explanation of any significant deviations between predicted and actual outcomes.
3. Benchmarking
How does the model's output compare to alternative approaches? Benchmarking involves comparing the model's results to those from a different model, methodology, or data source. For vendor models, this may mean comparing the vendor's outputs to the bank's own calculations using a simpler methodology, or comparing to peer institution data.
Benchmarking doesn't require building a competing model. It requires having a reference point to assess whether the model's outputs are reasonable.
Proportionality: What Examiners Expect from Community Banks
OCC 2011-12 acknowledges that model risk management should be proportional to the bank's size, complexity, and model usage. A $500 million community bank with a handful of models doesn't need the same MRM infrastructure as a $50 billion regional bank with hundreds.
What proportional MRM looks like at a community bank:
- A model inventory: A documented list of every model the bank uses, including vendor models, with the model's purpose, owner, and last validation date. This can be a spreadsheet, it doesn't need to be a database.
- Risk ranking: Classify each model as high, medium, or low risk based on its impact on decision-making, complexity, and data sensitivity. Your CECL model and interest rate risk model are almost certainly high risk. A simple liquidity ratio calculator is low risk.
- Validation on a risk-based schedule: High-risk models should be validated annually. Medium-risk models every 2-3 years. Low-risk models may be validated less frequently, with monitoring in between.
- Documented limitations: For each model, document what it can and cannot do. What assumptions does it make? Under what conditions might it produce unreliable results?
- Governance: Someone must own MRM. At a community bank, this is typically the CFO or risk officer, with board oversight through the audit or risk committee.
Examiners don't expect community banks to employ a model validation team. They expect the bank to demonstrate it understands what models it uses, has assessed their risk, and has a plan for validating them.
Vendor Model Oversight
Most community bank models are vendor-provided; ALCO models from ALM vendors, credit scoring from bureaus, transaction monitoring from BSA/AML vendors, and ACL calculations from accounting or risk management platforms. Vendor models present a specific challenge: the bank may not have full visibility into the model's methodology.
What the guidance requires for vendor models:
- The bank cannot delegate model risk to the vendor. Purchasing a vendor model does not transfer the risk. The bank remains responsible for understanding the model's inputs, methodology, limitations, and output quality.
- Request and review vendor documentation: Methodology whitepapers, validation reports, performance testing results, and known limitations. Reputable vendors provide these, if yours doesn't, that's a red flag.
- Conduct independent validation: This doesn't mean reverse-engineering the vendor's code. It means conducting outcomes analysis (comparing vendor model outputs to actual results), benchmarking (comparing to alternative data sources), and sensitivity analysis (testing how outputs change when inputs vary).
- Understand model settings and parameters: Vendor models typically allow configuration, alert thresholds, risk weights, assumption inputs. The bank must document what settings it uses and why those settings are appropriate for its portfolio.
- Monitor ongoing performance: Track model accuracy over time. If a BSA monitoring model's alert-to-SAR conversion rate drops significantly, or an ACL model consistently over- or under-predicts losses, the bank needs to investigate and adjust.
A common MRM examination finding at community banks: the bank purchased a vendor model, implemented it with default settings, and never assessed whether those defaults are appropriate for its specific risk profile. Default settings designed for a large bank's customer base may not work for a community bank's portfolio.
Building a Practical MRM Program
For a community bank starting or strengthening its MRM program:
Step 1: Build the model inventory. List every model, including vendor systems and spreadsheets that meet the three-component definition. Capture the model name, vendor (if applicable), business owner, purpose, and risk tier.
Step 2: Establish a governance framework. Assign MRM responsibility (the CFO, CRO, or a designated officer), define board reporting expectations, and create a model approval process for new models.
Step 3: Develop a validation plan. Based on the risk ranking, schedule validations over a multi-year cycle. High-risk models (ACL, IRR, BSA monitoring) get validated annually. Others on a longer cycle.
Step 4: Document everything. The validation itself matters, but the documentation matters more for examination purposes. Validation reports should describe the scope, methodology, findings, and recommendations.
Step 5: Monitor between validations. Ongoing monitoring, back-testing, performance tracking, and exception reporting, fills the gap between formal validations. This doesn't need to be elaborate for low-risk models, but high-risk models should have quarterly or semi-annual performance checks.
How Canarie Helps Banks Manage Model Risk Compliance
MRM generates a recurring set of obligations, annual validations, ongoing monitoring, documentation updates, board reporting, and vendor oversight. Tracking validation schedules across a dozen models, ensuring documentation is current, and demonstrating governance to examiners requires organized record-keeping.
Canarie maps each model's validation cycle, monitoring requirements, and governance tasks to a compliance execution workflow. Validation deadlines are assigned to responsible owners, completion evidence is captured, and board reporting tasks are calendared. When your examiner asks for the model inventory, validation reports, and governance documentation, it's in one place with a clear audit trail.
See how Canarie helps banks track recurring compliance obligations →
Frequently Asked Questions
Does OCC 2011-12 apply to community banks under $1 billion in assets?
Yes. OCC 2011-12 applies to all national banks and federal savings associations regardless of asset size. The Federal Reserve's SR 11-7 similarly applies to all state member banks. However, both guidance documents state that MRM expectations should be proportional to the bank's size, complexity, and model usage. A community bank is not expected to maintain the same MRM infrastructure as a global bank. Examiners evaluate whether the bank has identified its models, assessed their risk, and implemented validation and governance practices proportional to that risk.
Is a spreadsheet a model under OCC 2011-12?
It can be. If a spreadsheet applies statistical, financial, or mathematical methodology to process inputs into quantitative estimates used for decision-making, it meets the regulatory definition of a model. An ACL calculation built in Excel, an interest rate sensitivity analysis in a spreadsheet, or a loan pricing tool with embedded assumptions, all can qualify. Simple arithmetic (totaling a column of numbers) does not. The determining factor is whether the spreadsheet involves a processing methodology that transforms inputs using assumptions or statistical techniques.
How should a community bank validate a vendor BSA/AML transaction monitoring model?
Start with the vendor's documentation, review the methodology, understand the alert rules and thresholds, and confirm the model is designed for an institution of your size and risk profile. Then conduct outcomes analysis: what percentage of alerts lead to SARs? What is the false positive rate? Are there patterns of activity that should generate alerts but don't (below-the-line testing)? Compare your alert metrics to peer data if available. Review the model's settings and document why your specific thresholds are appropriate. Finally, ensure you're monitoring performance on an ongoing basis, not just during annual validation.
What happens if a bank doesn't have a formal MRM program?
Examiners will cite the absence as a deficiency. Depending on the models the bank uses and the risk they present, this could result in a Matter Requiring Attention (MRA) or, for more significant gaps, a Matter Requiring Immediate Attention (MRIA). The examiner will expect the bank to develop a model inventory, risk-rank its models, and establish a validation plan within a specified timeframe. Banks that rely on high-risk models (ACL under CECL, interest rate risk models used for ALCO decisions) without any MRM framework face the most significant scrutiny.