How to evaluate model risk management software

What this software does

Model risk management (MRM) software keeps an inventory of the models an organization uses and supports the work around them: risk tiering, validation, ongoing monitoring, findings and their remediation, and the approvals your policy requires. Some products also run tests themselves, for example on discrimination, calibration, stability and drift, produce explainability reports for complex models, or compare outcomes across groups for fair lending review. Others organize documents and workflow and leave testing to the model teams’ own tools.

Decide early whether you are buying a system of record, a testing environment or both, and which models it must cover: credit, fraud, anti-money laundering, allowance and stress testing models, vendor models, and machine learning models.

The rules that shape the work

On April 17, 2026 the Federal Reserve, the FDIC and the OCC issued revised interagency guidance on model risk management, published by the Federal Reserve as SR 26-2, by the OCC as Bulletin 2026-13 and by the FDIC as FIL-15-2026. It supersedes SR 11-7 of 2011 and the 2021 interagency statement on model risk management for BSA/AML systems, and the agencies rescinded their own issuances of both. Many policies and vendor materials still cite SR 11-7, so check which version a product was designed around. Points from the guidance itself that bear on software:

• Status and scope. The guidance states that it does not set forth enforceable standards or prescriptive requirements and that non-compliance with it will not result in supervisory criticism, although supervisory action may still follow violations of law or unsafe or unsound practices stemming from insufficient management of model risk. It is expected to be most relevant to banking organizations with over $30 billion in total assets, and may be relevant to smaller ones with significant exposure to model risk.
• What counts as a model. A complex quantitative method, system or approach that applies statistical, economic or financial theories to process input data into quantitative estimates. Simple arithmetic, such as spreadsheet calculations, and deterministic rule-based processes are excluded. Generative and agentic AI models are outside the guidance’s scope; traditional statistical models and non-generative, non-agentic AI models are within it.
• Materiality and tailoring. Model risk reflects a model’s inherent risk, exposure, purpose and use. Purpose and exposure together determine materiality, and higher-materiality models warrant more comprehensive and rigorous oversight. Sound practice assesses risk individually and in aggregate, including shared assumptions, data and methods.
• Effective challenge. Critical analysis by objective experts with the expertise, independence and organizational standing to effect change, across the lifecycle from development to ongoing monitoring.
• Validation and monitoring. Validation covers conceptual soundness, outcomes analysis and ongoing monitoring, with rigor aligned to the model’s approach, use and materiality. It generally occurs before first use; when a model is used earlier, sound practice calls for closer attention to its limitations and controls such as limits on use.
• Inventory, documentation and vendors. The guidance describes a model inventory as common industry practice, with enough information to understand model risk individually and in aggregate, and documentation that supports tracking of recommendations, responses and exceptions. Its principles also apply to vendor and other third-party models, including ongoing monitoring and outcomes analysis where code and data are proprietary.

Who should be on the evaluation team

• The head of model risk management, who owns the policy, the inventory and tiering.
• Validators, who will use the tool to provide effective challenge and need to reproduce tests.
• Model owners and developers from credit, fraud, AML, finance and data science, who will register models, supply data and close findings.
• Fair lending and compliance staff, if outcome testing across groups is in scope.
• Data and IT owners, because monitoring depends on regular feeds of inputs, scores and outcomes.
• Whoever supports the model risk committee, for reporting and approvals.
• Internal audit, which under the guidance generally evaluates whether model risk management is rigorous and effective rather than duplicating it.

Questions to ask and things to test

• Load your current inventory and see what the product’s tiering questions propose against your own tiers. Can you change the questions, and is every override recorded with a reason?
• Check the model definition. Can the inventory also track tools you oversee but do not treat as models under the revised guidance, such as rule-based processes, critical spreadsheets and generative AI tools, without mixing them up with models?
• Run the standard tests on one model’s development and recent outcome data and compare the results with your last validation.
• Re-run a test a week later and confirm it gives the same result from the recorded data snapshot, model version and code version.
• Review a drift alert and decide whether it gives the owner and validator enough to act on.
• Walk a finding from raise to closure and check the evidence it leaves, including the validator’s sign-off.
• Confirm independence. Who can validate, who can approve, and who can change a model’s tier? Can a developer sign off their own model?

Common limits to probe

• Software does not validate. It runs tests, organizes evidence and may suggest gaps; your validators provide effective challenge and reach the conclusions.
• AI-generated text is a draft. If the product summarizes results or suggests documentation gaps, those are not findings until a person records them. A generative AI feature falls outside the revised guidance’s scope, so decide how your other AI governance will cover it.
• Data dependence. Incomplete outcome data or a poorly defined baseline limits what monitoring can show.
• Fair lending conclusions. Bias testing applies the groups, proxy methods and measures your program defines. Whether a model complies with fair lending law is your institution’s judgment, with counsel where needed.
• Vendor models. Internal logic can be reviewed only as far as the vendor’s documentation allows.
• Policy stays yours. Tiers, thresholds and conditions on use are your institution’s decisions, recorded in the tool.

Implementation risks

• An incomplete inventory. Models outside the inventory get no oversight. Survey business lines, finance and vendor contracts, and repeat the survey periodically.
• Carrying over the old framework. Rebuilding a policy, templates and tiering written for SR 11-7 in a new tool can lock in a structure the agencies have since revised. Review your policy against the April 2026 guidance before configuration.
• Baselines and data feeds. Monitoring needs a stable baseline and timely outcome data for each model. Agree who supplies them and what happens when a feed is late.
• Migration gaps. Past validation reports, open findings, conditions on use and approval history are easy to lose. Check a sample after loading.
• Threshold ownership. Drift and performance thresholds need owners and a review cycle, or alerts will be ignored.
• Access to sensitive data. Development and outcome data can include personal information and protected characteristics. Review who can see it, at your organization and at the vendor.

Related reading on this site

Requirement pages: Model risk management guidance (SR 11-7).

In the glossary: Model risk management, Explainability.

This guide describes the category, not any one product. It is general information, not legal advice: for what a rule requires of your organization, read the rule itself or ask your counsel.