Model risk management
Tier models, run independent validations, track findings, monitor metrics against thresholds, and produce a board-level attestation for SR 26-2, SS1/23, and OSFI E-23.
What is Model risk management?
Model risk management (MRM) brings bank-grade model governance into VerifyWise. Use it to tier your models by risk, run independent validations, track findings to closure, monitor live metrics against thresholds, and produce a board-level attestation. It covers both AI and traditional models from one register, so you keep a single view rather than a separate silo.
The module maps to the ongoing-monitoring, tiering, independent-validation, findings, revalidation, and attestation expectations in the US Federal Reserve SR 26-2, UK PRA SS1/23, and OSFI E-23 supervisory standards.
Opening the module
Open Model inventory from the left sidebar, then select the Model risk management tab. Six sub-tabs run across the top:
Overview
Portfolio roll-up: models by tier, validation coverage, overdue validations, and open findings. Generate the attestation report from here.
Tiering
Classify each model into Tier 1, 2, or 3 and record the materiality drivers behind the decision.
Validation
Run staged validations, complete the sectioned validation report, and sign off with an outcome.
Findings
Log validation findings and move them through remediation to verified closure.
Monitoring
Track the latest ingested metric values, trends, and breach history per model.
Settings
Assign model roles, manage thresholds and ingestion tokens, and review how alerts are routed.
Tiering models
The Tiering sub-tab lists every model in the inventory. Select Assign tier on a row to open the tier dialog, choose a tier, and record the materiality drivers, for example capital impact, regulatory reporting, or customer exposure. Tier assignment is manual, and the tier you set governs how deep validation goes and how often the model must be revalidated.
| Tier | What the tier drives |
|---|---|
| Tier 1 | Full independent validation and continuous monitoring, with annual revalidation. |
| Tier 2 | Standard validation and periodic monitoring, on an 18-month cycle. |
| Tier 3 | Lightweight review, with biennial revalidation. |
Running a validation
A summary strip at the top of the Validation sub-tab shows how many models sit at each stage. Select Start validation to begin a cycle for a model that has no active validation. Only one validation can run per model at a time.
Each validation moves through four stages:
- Not started: the cycle exists but no work has begun.
- In validation: the validator is working through the report.
- Under review: the draft report is being reviewed.
- Validated: reached only by signing off, not by changing the stage manually.
Select any row to open the validation report drawer. The report is the primary artifact an examiner reviews, and the validator completes six numbered sections:
- Purpose and scope
- Conceptual soundness
- Data review
- Outcomes analysis
- Findings and limitations
- Conclusion and sign-off
Select Sign off validation to close the cycle. You choose an outcome, Validated, Validated with findings, or Not validated, and the report becomes read-only afterward. The drawer also lists any revalidation triggers that opened or annotated the cycle, so the reason the model is being validated stays attached to the record.
Managing findings
Findings capture the issues a validation surfaces. Select Create finding, link it to a validation, give it a title, and set a severity of Critical, High, Medium, or Low. Each finding moves through a remediation lifecycle: Open, Remediation planned, In progress, Resolved, and Closed. Open a finding to set its owner, due date, and remediation plan.
Assigning roles and independence
Under Settings, the Roles and independence section lets you assign four roles per model. Select a model, choose a user for each role, then save.
| Role | Responsibility |
|---|---|
| Owner | Accountable for the model in production and responds to findings. |
| Developer | Builds and changes the model. |
| Validator | Independently reviews and signs off the validation. |
| Approver | Grants use or conditional approval after validation. |
Feeding metrics in
Your pipeline pushes computed metrics to VerifyWise over a single endpoint. The model key sits in the URL path, so one pipeline can report for many models by varying the path.
POST https://app.verifywise.ai/api/mrm/models/{externalModelKey}/metricsSend a metric key, a numeric value, and an ISO 8601 timestamp for when the metric applies. You can add an optional window (such as daily or rolling-30d), a segment for a sub-population, and a context object for audit metadata that is stored but never evaluated. Reposting the same metric, timestamp, segment, and window is treated as a no-op, so a retrying cron never creates duplicates.
Manage the credentials under Settings, in Metrics feed and tokens. Select Create ingestion token, name it, and copy the value.
Setting thresholds
Thresholds turn raw metric values into a pass or breach verdict. Under Settings, in Default thresholds, select Add threshold, pick the model and metric key, then choose a shape:
| Shape | Breaches when |
|---|---|
| Floor (≥) | the value falls below the floor. |
| Above (>) | the value rises above the limit. |
| Ceiling (≤) | the value rises above the ceiling. |
| Below (<) | the value falls below the limit. |
| Band (min–max) | the value falls outside the range. |
Set the value (or minimum and maximum for a band), a severity of Warning, High, or Critical, and what happens on breach: Notify only, or Notify and flag for revalidation. Unlike findings, thresholds can be edited and deleted. Every evaluation stores a snapshot of the threshold as it stood at the time, so later edits never rewrite the history an examiner sees.
Reading the monitoring view
Select a model on the Monitoring sub-tab to see each metric with its latest value, the threshold in force, a trend sparkline, when the value last arrived, and a status chip: Within threshold, Warning, Breach, No threshold defined, or No data yet. A breach history section below lists every warning and breach for the model, newest first, alongside the threshold snapshot recorded at evaluation.
Revalidation triggers
A revalidation trigger tells VerifyWise a model needs to be looked at again. Four sources converge on one task, and each firing is recorded in an audit trail you can see in the validation report drawer:
| Source | When it fires |
|---|---|
| Breach | a metric breaches a threshold set to flag for revalidation. |
| Change | you request revalidation after a material change to the model. |
| Tier increase | a model moves to a higher tier. |
| Scheduled | a daily sweep finds a validation past its next-due date. |
If a validation is already open for a model, a second trigger annotates that task rather than opening a duplicate, and still records its own audit event. This keeps one clear thread of work per model while preserving the full history of why revalidation was requested.
Attesting to the portfolio
The Overview sub-tab rolls the whole portfolio into four summary cards, models by tier, validation coverage, overdue validations, and open findings by severity, followed by a per-tier table showing tiering, validation, monitoring, and finding status. Each tier and the fleet overall reads either Ready or Blocked.
Select Generate attestation report to download a DOCX file for the board and audit committee. It states the overall attestation status in plain language, summarizes the fleet by tier, breaks down validation coverage and open findings by severity, and includes the per-tier attestation table.