TL;DR

• What it takes to be real: a model risk governance structure that exists on paper and one that actually functions look identical in an org chart and completely different in an examination.
• What the committee reviews: validation outcomes, escalated drift flags, inventory changes, and exception approvals, on a standing agenda, not an as-needed basis.
• What goes to the board instead: risk appetite changes, policy endorsement, and anything a committee can’t resolve on its own authority.
• The evidence that separates the two: minutes that show a decision got made, with a documented rationale for every exception, rather than a record that a meeting simply occurred.
• Honest caveat: a committee that meets on schedule and approves everything without pushback is closer to no governance than to good governance.

A model risk governance chart looks the same whether the structure behind it works or not: a board, a risk management committee, a senior management function, each with a box and a reporting line. What separates a functioning structure from a decorative one shows up only when someone asks what the committee actually reviewed last quarter, and whether the board could point to a decision it made rather than a policy it rubber-stamped.

The model risk management framework, layer by layer covers governance as one of five layers RBI’s draft guidance structures a framework around. This piece stays inside that one layer and goes deeper: what a committee’s actual agenda looks like, where the line sits between committee and board authority, how often the board needs to engage, and the evidence that proves any of it happened for real.

What a model risk management committee actually reviews

A model risk management committee’s standing agenda covers validation outcomes since the last meeting, drift or performance flags escalated from ongoing monitoring, changes to the model inventory, and any exception request a model owner couldn’t resolve within existing policy on their own.

That’s a working list, built to be acted on rather than performed. A committee that reviews validation outcomes is checking whether independent validation actually happened and what it found, beyond whatever a model owner reported. A committee reviewing escalated drift flags is deciding whether a model needs remediation now or can wait for its next scheduled cycle, a decision monitoring data alone can’t make on its own. Inventory changes get reviewed here too, since a model added or retired without the committee’s knowledge is a model the governance structure has already lost track of. RBI’s draft guidance names this review function directly under Chapter II’s committee roles, including validation review as a specific, named duty rather than an implied responsibility.

Exception requests are the item most committees handle worst. A model owner who wants to keep running a model past its scheduled revalidation date, or deploy with a known limitation while a fix is in progress, needs somewhere to bring that request, and a committee that approves exceptions without a documented reason is building a file of undocumented risk one exception at a time. The standard worth holding a committee to is simple: every exception on the agenda should leave with a written rationale attached, beyond a bare yes or no.

The line between committee-level and board-level sign-off

A model risk management committee handles routine validation results, standard exception approvals, and inventory changes within established policy. The board gets involved only for risk appetite changes, policy endorsement, and anything a committee determines it lacks the authority to resolve on its own.

That division only works if the criteria for escalation are written down in advance, not decided in the moment a hard case shows up. A committee facing a model that failed validation twice in a row, or a new AI model crossing into the highest risk tier, needs a pre-agreed rule for when that goes to the board rather than a judgment call made under time pressure. RBI’s draft guidance assigns risk appetite approval and policy endorsement to the board specifically, which sets the floor: anything touching the institution’s overall risk appetite belongs at board level regardless of how minor the triggering model seems on its own, since the decision is about the appetite, not the single model that surfaced it.

How often the board needs to look at model risk, and what forces an off-cycle review

The board’s model risk oversight has to be genuine and evidenced, though RBI’s draft guidance does not fix an exact review frequency. In practice, a periodic scheduled review, at minimum annually, paired with clear off-cycle triggers, is what most functioning governance structures run on.

The scheduled review matters less than the triggers that force an unscheduled one. A validation failure on a high-tier model, an examiner finding, an incident where a model behaved in a way nobody anticipated, or a new AI or machine learning deployment that changes the institution’s risk profile, each of these should pull a model risk item onto the board’s agenda outside its normal calendar. A board that only ever sees model risk once a year, on schedule, with no mechanism for anything to arrive early, is a board that finds out about a problem at the same pace it would have without governance at all.

A genuine annual review also looks different in content, beyond simply arriving on schedule. It should include the current state of the model inventory by risk tier, a summary of exceptions granted and why, and any validation finding the committee escalated during the year rather than resolving on its own. A board that receives a one-page summary stating that model risk was managed appropriately, with no supporting detail underneath it, is receiving a conclusion rather than the evidence a conclusion is supposed to rest on.

The evidence that proves governance happened, rather than merely existing on paper

Evidence that model risk governance actually functioned means minutes documenting what decision got made and why, an escalation log connecting each flagged issue to what the committee or board did about it, and a maker-checker record showing who approved each model change and when.

A meeting that happened is not the same as a decision that got made, and an examiner asking for evidence is asking for the second thing, not the first. Minutes that record “reviewed and approved” with no rationale attached are close to no record at all, since they can’t show whether the committee actually engaged with what it was reviewing or simply signed off. iTuring’s platform keeps this evidence as a byproduct of the approval workflow itself, an immutable, timestamped maker-checker record tied to every model change, rather than a document a secretary reconstructs after the fact from memory and calendar invites. That distinction, evidence generated as governance happens versus evidence assembled afterward to look like it did, is usually the difference an examination actually surfaces.

The escalation log deserves the same discipline as the minutes. Every issue that reaches the committee from ongoing monitoring should carry a record of what happened to it: escalated on a given date, reviewed at a given meeting, resolved with a specific action or formally accepted as a documented exception. A drift flag that appears in a monitoring dashboard but never surfaces in a committee record is a finding the governance structure produced and then lost, which looks the same to an examiner as a finding nobody ever generated in the first place.

If your last committee meeting produced minutes but not a decision anyone could point to later, that gap is usually where an examination starts. Book a working session with our data science team to see what a fully evidenced governance record actually looks like.