Model risk tiering means sorting every model in your inventory into a small number of risk tiers, usually three or four, so that validation depth, monitoring and approval authority grow with the risk each model poses. Set the tier on inherent risk. That covers how material the model’s use is (its purpose and its exposure) and how likely it is to fail (its complexity, assumptions and input quality). It does not cover how well the model happens to be governed today. For the tier to hold up, it should come from a documented tiering method, usually a scorecard or decision tree, applied consistently across the whole firm. It should also be recorded with its rationale, affirmed by a designated approver or committee, and reviewed when the model changes materially; most firms also reassess at least once a year. One boundary matters from the start: the US interagency guidance issued in April 2026 (SR 26-2) leaves generative and agentic AI out of scope, so those systems need a governance route of their own.
How model risk tiering decides high, medium or low
Most financial firms give models a tier using explicit procedures and decision tools. Nearly all of them use a handful of tiers rather than trying to rank every model from top to bottom. The tools come in two families. Scorecards are the more common, and a few firms use decision trees. Both generally combine the chance of a model failing with the impact if it does. Many firms treat it like credit analysis: probability of model failure plays the part of probability of default, and impact of failure plays the part of loss given default.
On the impact side, firms consider materiality. In the Federal Reserve’s SR 26-2 text, model purpose (for example regulatory requirements or managing financial risk) together with model exposure (such as portfolio size) determines materiality. Firms also make categorical distinctions among model uses. General business uses such as direct-mail targeting usually count as lowest impact, while financial accounting and regulatory reporting are often treated as the highest. On the failure side, common inputs are model complexity, the firm’s experience with the product or method, dependence on upstream models, use of the outputs in downstream models, whether the model runs on an end-user platform or an IT-controlled application, and the number of users.
Simple decision trees are easy to understand and transparent. In one published decision-tree example, the first question is whether the model measures risk, price or value. A “no” sends it straight to the low tier. A “yes” leads to a second question: is the model used in critical decisions or for regulatory or financial reporting?. A scorecard weights several factors instead. It can include overrides, such as a stress-testing flag that pushes a model into tier 1 whatever its score.
A few design choices separate a tiering method that holds up from one that drifts:
- Inherent, not residual. If the tier depends on how well the model is governed, the result goes round in circles: weak governance raises the tier, the extra oversight lowers it, and the assignment never settles. Inherent tiering also lets you compare validated and unvalidated models fairly.
- Relative to the whole firm. Rank each model against every other model under the same framework, which usually means the whole enterprise, not against its own business line.
- Transparent and not falsely precise. Put the weight on the tier itself rather than on intermediate scores, keep the tool simple enough to run, and accept that expert judgement plays a real part.
- Stable. A tier should change mainly when the risk changes materially.
Decide early whether you tier each model once or each model-and-use pair separately. Firms that validate each use separately can reasonably tier the pairs. Firms that validate all uses together might reasonably give each model a single tier.
What the tier is supposed to drive
The tier has to drive something downstream, in practice and not only in policy. OSFI and the PRA say this in their own words:
| Governance activity | How the tier shapes it |
|---|---|
| Model review or validation | Frequency, intensity and scope scale with the inherent risk rating (OSFI E-23) |
| Documentation | Requirements set by risk rating (OSFI E-23) |
| Approval authority | The level of authority needed to approve the model, and any exemptions, follow the rating (OSFI E-23) |
| Ongoing monitoring | Frequency set by model tier (PRA SS1/23) |
| Periodic revalidation | Frequency consistent with model tier (PRA SS1/23) |
| Re-assessment of the tier itself | Interval driven by the inherent rating (OSFI E-23) |
How to size each of those activities for a given tier is a separate question, covered in our piece on matching governance depth to a model’s impact.
Generative and agentic AI sit outside SR 26-2
The Federal Reserve’s SR 26-2 attachment says that generative and agentic AI models are not within its scope. It applies its principles to traditional statistical and quantitative models and to non-generative, non-agentic AI. For anything it does not cover, it points to the organisation’s broader risk management and governance practices. The OCC’s announcement confirms that the 2026 guidance replaces the 2011 guidance. It also says a planned request for information will consider banks’ use of AI, including generative and agentic AI. One practitioner guide draws the same practical line: do not claim SR 26-2 coverage for a generative system, and route it through an AI-governance process instead.
So does a generative model belong under your existing model risk policy, or does it need its own tiering category? Under the 2026 US banking guidance, the criterion for AI is your own policy. A 2026 internal-audit guide describes the split most banks make. Machine learning models used for decisions, such as credit scoring and fraud detection, stay inside the model framework with extra validation for explainability, bias and drift, while generative AI tools sit under a separate policy. The underlying logic still carries over. Research on GenAI model risk ties the rating to how the model is used: reliance on its output, the impact of errors, complexity, and whether the required controls can actually be implemented. For agentic systems, the TrustX ARC framework uses a “critical dimension” rule, so any single dimension scored high puts the system in the top tier rather than being averaged away.
We would give generative and agentic systems their own category, with their own rubric, inside the same inventory, rather than forcing them through a scorecard built for regression models. A firm-wide inventory helps identify model inter-dependencies across all of them. A separate rubric stops autonomy, output exposure and hallucination risk from being scored as if they were ordinary complexity.
Which fields should a model inventory template capture for tiering?
A model inventory should record for every model what it does, who owns and built it, where it came from, its risk rating, what it depends on, and when it was last reviewed. TechnoLynx builds this inventory, its intake workflow and the audit trail behind each tier as engineering work under AI Governance and Trust, producing artefacts a model risk committee can read and sign against.
You do not need to invent a format. OSFI’s Guideline E-23 publishes a minimum list of fields for every identified model and a longer list for models with non-negligible risk. The table below combines that list with the other sources:
| Field | Why it matters for tiering |
|---|---|
| Model ID, name, description of key features and use | Anchors every later decision to one record |
| Model risk rating (tier) | The output being defended |
| Model owner (a named person) | Owner is accountable for the tier being correct and the entry current |
| Model developer | Delineates who built the model from who validates it |
| Origin: internally developed or vendor | Vendor models are tiered like any other, and the institution stays responsible |
| Materiality or business impact | Impact half of the tiering logic |
| Complexity rating | PRA SS1/23 expects a materiality and a complexity rating per model |
| Dependencies and data sources | Upstream and downstream links, and alternative or unstructured data, raise complexity |
| Approved uses and limitations | Tier is a property of the model in its uses |
| Version and production deployment date | Records which version is in production and since when |
| Reviewer and approver | Approval affirms the assigned rating |
| Last validation date and next planned validation | Lets the validation schedule be checked against the tier |
| Monitoring status | Shows whether exceptions are open |
| Last owner attestation date | An entry older than its attestation cadence is unverified |
Adopt the standard fields first, and only add custom ones where your model population has attributes the standard list misses. Three caveats apply. The template decays unless owners re-confirm entries on a cadence, because decommissioning and pilots quietly going live do not update a row on their own. For vendor models, the institution is expected to obtain and review the vendor’s development documentation and testing evidence and identify the gaps. And materiality calls involve judgement, so the tiering approach itself needs periodic independent review. On tooling, a spreadsheet is a legitimate way to discover your models, but past a few dozen rows or a second editor it has no change history or attestation trail, so it works for discovery, not for governance.
What should the tiering decision record say, and who signs it off?
Each tier should come with a decision record showing how the model got it. It should show the criteria applied, any expert-judgement inputs or overrides, the uses considered, and the approval that affirms the rating. The decision authority matrix approach described by Void Vanguard says every approval should produce an evidence artefact: a signed approval record and a risk tier classification document among them.
We would keep that record separate from validation reports. Inherent-risk tiering is meant to be independent of what validation finds. If the rationale lives inside a validation report, an examiner cannot tell the original reasoning apart from later testing outcomes. A standalone record also handles a provisional tier cleanly: OSFI allows a temporary rating that is confirmed at model review or approval, and the record should show both steps. Treat “this is not a model” decisions the same way. A determination that a tool is out of scope should record who made it, what criteria they applied and when.
The sources describe sign-off as follows:
- In the Journal of Risk Model Validation study of industry practice, the head of MRM generally has final sign-off on tier assignments. Model owners and users can challenge and escalate disputed tiers.
- Some policies only let the head of MRM move a model up from the tool’s result, never down.
- OSFI describes the model approver as an individual, unit or committee, often part of a model risk committee or senior management function, whose approval affirms the assigned rating.
- PRA SS1/23 adds a named senior manager (SMF) accountable for the MRM framework as a whole.
Which role signs depends on your governance structure, so write it into the policy, along with a documented methodology and annual review of assignments.
What changes to a model should trigger a re-tiering review?
A model should go back through tiering review when its algorithm, parameters or supporting components change, when its data changes significantly, when monitoring shows a performance breach, when its use or output authority changes, and on a scheduled basis set by its tier. TechnoLynx can build the change-assessment record and inventory versioning that make each of these events traceable, as part of its AI Governance and Trust work, starting with how your current release process records model changes.
Retraining deserves special attention. Machine learning models can change behaviour as they retrain on new data, which breaks an assumption traditional validation relies on. One change-assessment guide states that “no code change” does not mean “no model change”. The assessment should classify impact across methodology, data, use, population, output authority, performance, limitations, exposure and controls. We read a change in the weight a blended model gives an ML forecast versus a traditional table as a change to methodology and output authority, even with no code change. We would treat that as a candidate material change by default.
The routing should be decided before the release ticket closes:
| Change assessment outcome | Route |
|---|---|
| Maintenance | A route from the guide’s list, such as inventory-only update or targeted testing |
| Model modification or significant data change | Model review, confirming or challenging the risk rating |
| New decision use, new population, changed output authority, higher tier | Revalidation or reapproval |
| Replacement running in parallel, or a fork for a different purpose | New inventory record with its own lifecycle |
| Otherwise | Keep the existing ID and add version history, change-assessment ID, validation status and approval date |
In each change assessment, the model owner drafts the facts, and model risk or an independent reviewer challenges the classification. Technology change management runs the release but should not decide materiality on its own. Define “material” in advance: an FDIC examination module asks whether models are revalidated after material changes and whether “material” is defined at all. Without that definition, every retrain becomes a judgement call argued after the fact. The monitoring and drift side of this loop is covered in more depth in building model risk management into the ML lifecycle.
How often a high-tier model is revalidated, and by whom
PRA SS1/23 and OSFI E-23 tie revalidation and review frequency to the tier. PRA SS1/23 asks for regular independent revalidation at a frequency consistent with the model’s tier, normally less detailed than the initial validation. The tier itself is reassessed as part of each validation and revalidation, using a review of the information behind it. Most firms in the Journal of Risk Model Validation study require tier reassessment at least annually. For inventory attestation, one practitioner source treats quarterly for high-risk systems and annually for the rest as a defensible cadence.
The revalidation is done by people with the expertise, independence and standing to challenge the model and get changes made. The approval authority has to make sure validation recommendations are acted on. For a model whose outputs feed statutory figures, check whether a statutory or supervisory body sets its own review cadence.
Showing examiners that tiering criteria were applied across the whole inventory
Evidence of consistent tiering has to cover the whole inventory, not one model. That means an independent re-tiering of a sample that agrees with the recorded tiers, validation schedules that actually differ by tier, and tier changes that follow changes in use. A 2026 internal-audit guide describes exactly those tests: re-tier a sample of fifteen models from their inventory attributes and uses, analyse any disagreements, and check that tier drives practice and not just policy. In that guide’s worked example, the re-tiering agreed on 13 of 15 models, and two credit-scoring models had been tiered below their regulatory use. The finding it lists is a tier assigned once and never revisited, with one validation approach for all models.
Have this ready before the examiner asks:
- The documented tiering methodology with anchored criteria, and the committee minutes approving it.
- A firm-wide tier distribution, ranked against the whole enterprise rather than by business line.
- Evidence that the tiering approach itself was independently reviewed, including how accurately tiers are recorded in the inventory.
- Validation and monitoring calendars that visibly differ by tier.
- A change log showing new models, material changes and retirements entering the inventory through the governed process.
When the evidence answers a specific finding
We would quote the finding text in the remediation memo and map each step to it line by line. For Critical or High findings, one practitioner source lists closure evidence: a remediation plan, updated documentation, updated code and test results, an updated validation opinion on that finding, and a use log showing the new version in production. For those findings, sign-off sits with the model risk committee.
PRA SS1/23 also expects remediation plans from MRM self-assessments to be documented, reviewed regularly and shared with the board.
Registering a pilot chatbot that never went through intake
A pilot in use that skipped formal intake still belongs in the inventory. Register it now, give it a tier using the standard criteria, and document its owner. TechnoLynx can set up the intake workflow and the inventory record for conversational AI tools as part of AI Governance and Trust, starting from the pilots already running outside the register.
An intake process so the next tool has somewhere to be tiered
The FDIC examination module asks whether models in use are missing from the inventory, and if so, what management’s reason is for leaving them out. Untiered shadow tools are described as the most dangerous gap in model risk management. Asking business units to declare any quantitative tool whose outputs feed decisions is one way to find them. A two-register approach suits conversational AI. Every new AI tool gets an ID in an AI use-case register at intake. If it meets the model definition, it gets an entry in the model inventory under the same ID. If not, the scope decision is recorded with the reviewer’s sign-off. An LLM-based chatbot is generative, so under SR 26-2 it falls to that use-case register and your AI-governance policy rather than the model guidance. A tool moves into the model inventory when its outputs start driving consequential decisions, when it is retrained on proprietary data, or when its volume or customer impact becomes material.
A starting record for the tool that is already live
For a tool already in production, a decision authority matrix source recommends a formal review: classify it, identify which authority should have approved it, and get a signed retroactive acknowledgement from that authority. The examiner will see that it is retroactive, but a retroactive record still counts for more than no trail at all. A tier assigned after the fact can understate risks that only surfaced in production use, so record what production experience showed alongside the original pilot scope.
When the underlying model is swapped, the owner updates the record. Keep the existing ID with version history where the lifecycle continues, or open a new record if the replacement runs in parallel or serves a different purpose. A model swap is exactly the kind of quiet change that leaves a row out of date, so the owner’s periodic attestation should cover it.
Who can build our model inventory and tiering evidence trail?
TechnoLynx builds the engineering side of a defensible tiering lifecycle: the model-risk inventory, its approval workflow, and lineage and traceability for production decisions. On build versus bring in, we would advise a firm with a small, stable inventory and an established MRM function to extend its own tooling. A specialist earns its place when inventories span ML, vendor and generative systems that need to share one register and produce comparable evidence. This work sits under AI Governance and Trust.
The engagement is engineering, not policy advice or certification. It produces the artefacts an audit needs and leaves the approval decisions with your head of MRM, your committee and your accountable senior manager. Independent validation of a specific model is also a separate second-line or external-validator role.
FAQ
What is model risk?
The FDIC defines model risk as the potential for adverse consequences from decisions based on incorrect or misused model outputs and reports, which can lead to financial loss or poor decision-making. The PRA adds possible regulatory non-compliance and reputational damage.
What is the SR 11-7 framework?
SR 11-7 was the Federal Reserve and OCC supervisory guidance on model risk management issued on 4 April 2011, which the FDIC adopted in 2017. In April 2026 the agencies replaced it with updated guidance, SR 26-2 at the Federal Reserve.
What is an AI inventory?
An AI use-case inventory registers AI tools, including LLMs and vendor-embedded features, that may fall outside the model definition but still carry operational and compliance risk. It is reconciled with the model inventory through shared IDs.
