Model Risk Assessment: Why It Should Start Before Validation

Model Design and Risk Assessment  

Why model risk assessment belongs alongside model development, and what it costs institutions when it is done only during validation.

The Build-First, Fix-Later Pattern

Development teams in financial institutions spend months on model structure, assumption setting and output calibration. Model risk enters the conversation late, usually once the build is close to complete. What could have run as a parallel exercise becomes a reactive audit. And when that audit surfaces a critical issue, the remedy requires a complete rebuild instead of minor parameter adjustments.

This fallacious approach costs financial institutions time, money, and credibility.  

Model Risk Assessment (MRA) is how you find where a model's assumptions might fail, where its data might mislead, and where its logic might break once it meets the real world. Even the standard definition of model risk, the chance of bad decisions coming from a wrong or misused model, tells you the risk is there from the moment someone first sketches the idea. Yet most of the industry still treats assessment as something you do after the model exists, not while it's being built.

Case Study: The Cost of Doing It in the Wrong Order

A regional bank spent months building a new credit risk model, with solid architecture, calibrated outputs, and thorough documentation, and expected a quick validation sign-off. However, validation team raised concerns.

• Finding: Validators caught a basic conceptual flaw: the model's borrower-behavior assumptions worked in calm markets but had never been tested against an adverse downturn scenario.

• Impact: A two-week sign-off turned into a four-month rebuild, because the flaw sat in the core design, not in a parameter that could be tuned.

• Root cause: The developers weren't the problem, the process was. The risk was catchable at the design stage; it just wasn't looked for until validation.

• Takeaway: Run MRA alongside the build, and this same risk shapes the design instead of derailing it four months later.

Why It Matters: Regulatory Expectations and the Real Cost of Late-Stage Risk

Supervisory guidance has been consistent on this point across jurisdictions.

The PRA's SS1/23 sets out model risk management principles spanning the model lifecycle, including development, implementation and use. OSFI's Guideline E-23, published in final form on 11 September 2025 and effective 1 May 2027, applies enterprise-wide model risk management to all models at all federally regulated financial institutions, including AI and machine learning models and those sourced from third parties. In the United States, SR 26-2, issued jointly by the Federal Reserve, the OCC and the FDIC on 17 April 2026, superseded SR 11-7 and SR 21-8, reframing expectations around proportionality and model materiality so that governance effort scales to each model's exposure and purpose. MAS set out good practices for AI model risk management in its information paper of 5 December 2024 and consulted on Guidelines on AI Risk Management from 13 November 2025 to 31 January 2026. The RBI has moved in the same direction, with a draft circular on the management of model risks in credit released on 5 August 2024 and draft Guidance on Regulatory Principles for Model Risk Management issued for comment on 24 June 2026, covering all models used by regulated entities, including third-party, AI and ML models.  

The common expectation is that governance operates across the lifecycle rather than at a single checkpoint before deployment. Proportionality under SR 26-2 sharpens the timing question: an institution cannot scale effort to model materiality if materiality is first assessed after the model has been built.

Examination practice follows the same logic. Examiners now ask less about whether validation took place than about whether risk considerations entered development at all. A validation report carrying a long list of findings the development team could reasonably have caught earlier points to an inefficient framework.

The pieces that most often get pushed to the end:

• Conceptual soundness: whether the theory behind the model fits its intended use. Settling this in design costs a fraction of settling it at validation.

• Data quality and limits: known data constraints identified early allow the model to be built around them instead of retrofitted afterwards.

• Assumptions: assumptions documented and challenged before deadline pressure sets in remain open to revision. Assumptions inherited at validation rarely do.

• Stress testing: expected model behavior at the extremes belongs in the design specification, not in a post-implementation review.

• Tiering and materiality: a risk tier assigned at the outset aligns development rigor with the consequence of failure, which is what proportionality-based supervision now expects.

• Ongoing monitoring: thresholds, triggers and reporting lines defined during the build are operational at go-live instead of assembled months afterwards.

Institutions that perform well in supervisory examinations are generally those where risk work sits inside development, and where the model owner and the risk function stay in contact throughout rather than meeting for the first time at validation.

Treating Risk Assessment as a Core Design Input

The practical shift is to stop treating risk assessment as a gate the model clears before launch and to start treating it as an input to design. Validation then contributes to preventing issues rather than recording them, which changes the working relationship between developers and validators.

Institutions that make the change tend to see two effects. Validation cycles shorten, because there is less late-stage rework to absorb. Models perform more reliably in production, because risk considerations informed the design.

How Solytics Partners Can Help

Solytics Partners works with financial institutions to build model risk management into how models are developed, not only how they are validated. Our teams work alongside yours from the design stage, so questions of soundness, data and assumptions are raised while they remain inexpensive to answer.

• Embed risk early: Parallel, not sequential: assessment runs next to development, not after it, catching soundness, data, and assumption issues before they harden.

• Build the framework: We set up parallel risk assessment processes and a clear tiering approach that matches effort to how much each model actually matters.

• Run it hands-on: Our specialists sit with your development and validation teams, running soundness reviews, challenging data and assumptions, and stress-testing at the design stage, all the way through independent validation and ongoing monitoring.

• Bring real depth: Regulatory expertise across SR 26-2, SS1/23, E-23, CPG 220, MAS, and RBI, paired with hands-on experience running these programs inside institutions like yours.

• Stay for the build: We don't drop off a template and walk away. We help you build the workflows, documentation standards, and governance checkpoints that turn MRA into something repeatable and exam-ready.

• Fit the engagement to you: Whether you're building an MRM framework from scratch, getting ready for a regulatory review, or breaking the build-first, fix-later habit, we scale from advisory and framework design to fully managed validation based on where you stand today.

Contact us for the Demo: Link

References

• Bank of England (PRA). Supervisory Statement SS1/23: Model Risk Management Principles for Banks. Link

• OSFI Canada. Guideline E-23: Model Risk Management. Link

• APRA Australia. CPG 220: Risk Management. Link

• Monetary Authority of Singapore (MAS). Technology Risk Management Guidelines. Link

• Reserve Bank of India (RBI). Guidelines on Model Risk Management for Banks. Link