Effective Challenge in Model Risk Management: Document the Disagreement

TL;DR

• Model risk management effective challenge is not the existence of a validator. It is evidence that an informed, objective reviewer changed—or credibly tried to change—the decision.
• Preserve material disagreement in a challenge memo: issue, evidence, request, response, disposition, unresolved limitation, condition, owner, due date, and escalation.
• “Approved with comments” is dangerous shorthand. State exactly what may proceed, what remains prohibited, when the decision expires, and who accepted the residual risk.

The cleanest validation report in the room can still hide a governance failure: everyone disagreed in email, the model launched anyway, and the final PDF says “approved with comments.”

That is why model risk management effective challenge needs its own decision trail. The Federal Reserve’s SR 26-2, issued April 17, 2026 with the OCC and FDIC, defines effective challenge as critical analysis by objective experts who evaluate model risk and effect appropriate changes across the model lifecycle. It also says those reviewers need appropriate expertise, sufficient independence to maintain objectivity, and organizational standing and influence to effect change.

The word that matters is effect. A reviewer who raises a technically correct objection but cannot obtain a response, impose a condition, escalate a dispute, or constrain use has produced commentary—not an operating control.

What changed under the 2026 model risk guidance?

SR 26-2 replaced SR 11-7 and moved to a more risk-based, principles-focused approach. The OCC’s Bulletin 2026-13 explains that the guidance addresses model development and use, validation and monitoring, governance and controls, and vendor products. It is expected to be most relevant to banking organizations above $30 billion, while potentially applying below that level where model-risk exposure is significant.

The revised guidance is less prescriptive about organizational structure. Its validation section says the quality of the process depends on the rigor and effectiveness of review rather than the structure of the risk function. That is flexibility, not permission to erase independence.

The OCC’s April 17 news release and the FDIC’s interagency letter confirm the joint issuance. Those short pages are useful for policy citation; the attached SR 26-2 text is where the operating details live.

The challenge memo is not another validation report

A validation report explains what was tested and what the reviewer concluded. A challenge memo preserves the governance of a material dispute.

Use one when disagreement could affect:

• whether a model may enter or remain in production;
• permitted products, populations, geographies, thresholds, or decisions;
• the reliability of an input, assumption, benchmark, outcome test, or override;
• the severity of a limitation or finding;
• a validation or remediation deadline;
• required monitoring, fallback, or compensating controls;
• model-risk tier, issue rating, or approval authority; or
• acceptance of use before validation is complete.

Routine clarification does not need committee treatment. If the owner fixes a mislabeled chart and the reviewer verifies it, leave the exchange in working papers. The memo is for disagreement that changes—or should change—the risk decision.

The minimum effective-challenge record

Do not bury this in meeting minutes that say “discussion followed.” Minutes can reference the challenge ID and final decision. The challenge record should hold the technical substance and the exact disposition.

A challenge-memo teardown

Realistic hypothetical: a regional bank plans to expand a deposit attrition model from retail deposits to small-business accounts. The model owner argues that observed back-testing error is within the existing tolerance. The validator disagrees because the business-account segment has a different balance distribution and the stressed period contains too few observations.

A weak record says:

Validator requested additional testing. Business provided support. Approved with monitoring.

That language hides every important decision. A defensible record looks more like this:

Decision: approve expansion of Model DEP-014 v3.2 to small-business accounts.

Challenge: the validation sample contains 84 stressed-period business accounts, versus 8,420 retail accounts. Aggregate error remains within the model’s approved tolerance, but segment-level evidence is insufficient to conclude that the business-account attrition assumption performs reliably under stress.

Evidence request: provide segment-level back-testing, sensitivity analysis using a range of attrition assumptions, and the liquidity impact at the adverse bound.

Owner response: historical observations cannot be increased before launch. Sensitivity analysis shows the adverse assumption increases modeled 30-day outflows. Treasury proposes a narrower initial population and weekly monitoring.

Reviewer disposition: unresolved limitation; expansion is supportable only with conditions.

Conditions:

1. exclude business accounts above the institution’s approved balance cutoff from automated model treatment;
2. apply the documented conservative attrition assumption to excluded or thin-data segments;
3. monitor actual-versus-predicted attrition weekly by segment;
4. escalate when the approved error tolerance is breached in two consecutive reporting periods, or immediately when the liquidity-impact threshold is breached;
5. complete the expanded outcomes analysis by October 31, 2026; and
6. expire the approval on that date unless the Model Risk Committee renews it using updated evidence.

Authority: Head of Model Risk recommends conditional approval; the designated business and risk authorities approve within policy. Any use outside the conditions requires escalation.

The sample sizes and conditions above are hypothetical, not benchmarks. Each institution should use its own model materiality, tolerance framework, and governance authority. What makes the example defensible is not the number 84. It is the visible path from evidence gap to restricted use, monitoring, expiry, and decision authority.

Write challenge statements that can be answered

“Methodology seems weak” invites a memo war. Use this structure instead:

Because [specific evidence or criterion], the reviewer concludes [precise limitation or disagreement], which could affect [decision, output, population, or risk], and requests [analysis, control, restriction, or remediation] by [date or gate].

Example:

Because the benchmark test excludes the two highest-volatility quarters in the development window, the reviewer cannot determine whether the model remains reliable during the conditions that drive its material use. This could understate the approved performance limitation. Re-run the benchmark across the complete window or restrict use to the previously validated population before production approval.

That formulation gives the owner something concrete to rebut or satisfy. It also lets an approver see the consequence without rereading the whole validation package.

What if the owner and reviewer still disagree?

Do not force artificial consensus. Preserve the positions and use the escalation path in the model risk policy.

A workable sequence is:

1. Reviewer records the challenge and evidence.
2. Owner responds with evidence, not only a business deadline. Urgency can inform the decision; it cannot prove the model is sound.
3. Reviewer assigns a disposition. The owner should not close the reviewer’s objection.
4. The appropriate authority decides. The decision-maker must be authorized for that model tier and type of residual risk.
5. Conditions enter operating systems. A use restriction belongs in deployment configuration or procedure; a monitoring trigger belongs in the monitoring record; remediation belongs in the issue tracker.
6. Expiry forces reconsideration. A conditional approval without an expiry is a permanent waiver wearing temporary clothing.

This is where ownership often breaks. Model Risk writes a condition, the committee approves it, and no one translates it into a production ticket. Link every condition to a system-enforced control, operating procedure, monitoring job, or issue ID. Then map completion evidence back to the challenge.

The AI governance decision-log guide provides a parallel structure for systems outside the formal SR 26-2 scope. Remember that SR 26-2 explicitly excludes generative and agentic AI from its scope; do not casually claim the revised model guidance directly governs those tools.

Using a model before validation is complete

SR 26-2 states that validation generally occurs before first use, while recognizing that urgent business needs may sometimes require earlier use. In those cases, the guidance points to heightened attention to limitations, stakeholder notice, and controls such as use limits or closer monitoring.

The challenge memo should therefore answer:

• Why is early use necessary?
• Which validation work remains open?
• What could that missing work reveal?
• Which uses, customers, decisions, or exposures are prohibited?
• What fallback exists if performance is unacceptable?
• What monitoring runs, at what frequency, and who receives exceptions?
• When does the authorization expire?
• Who can stop use immediately?

“Business criticality” should never be the whole rationale. If the need is truly urgent, the control package should look more restrictive, not less.

For the broader program update, see the OCC 2026-13 seven-item checklist and the model documentation guide. The first explains the current guidance; the second helps connect model design and validation evidence, with appropriate care around its older SR 11-7 references.

So what?

Pull the last three validation reports marked “approved with comments.” For each one, try to identify the material objection, owner response, reviewer disposition, decision effect, condition owner, expiry, and closure evidence. If those answers live across email, minutes, Jira, and somebody’s memory, build the challenge record now—before the next disagreement is attached to a production incident or examination request.

The AI Risk Assessment Template & Guide includes inventory, assessment, approval, limitation, and monitoring artifacts that can support this decision trail for AI use cases while your model risk policy addresses traditional models under SR 26-2.