Ratemaking Model Risk Inventory and Tiering

Why Inventory and Tiering Matter

An organization cannot govern ratemaking models consistently if it does not know which models are in use, what decisions they influence, and who is accountable for them. A model inventory makes that information findable. Risk tiering then helps direct review and control effort toward models whose errors could have greater consequences or whose methods are harder to assess.

A tier is a governance classification, not a statement that a model is correct, incorrect, or a particular probability of failure. The scoring framework below is an illustrative internal policy. An organization should document its own definitions, weights, thresholds, and escalation rules and apply them consistently. These governance practices are aligned with the CAS Exam 8 (Advanced Ratemaking) syllabus.

Define What Belongs in the Inventory

The inventory should cover more than a fitted statistical model. It can include a GLM, a spreadsheet that transforms experience into a rate indication, an algorithm that converts indications into rating factors, or a tool that supplies an assumption used in pricing. A simple tool may still be important if it has substantial influence on production rates. Conversely, a technically complex model used only for exploratory analysis may have limited direct reliance.

Set the inventory unit clearly. It may be a model, a model version, or a model-and-use combination. If one model supports materially different decisions, record those uses separately or explain how their differing risks are reflected in one tier. Record dependencies as well: a downstream tool may rely on an upstream model's output, and both uses need to be visible. Do not count a model twice simply because several teams use it; link the uses to the same inventory record where appropriate.

Useful inventory fields include a unique identifier, name and purpose, owner, business use, lines and jurisdictions, status, model type, input and output descriptions, upstream and downstream dependencies, implementation location, version, last review date, current tier, scoring rationale, and required controls. Link to the relevant model documentation, assumption register, validation evidence, and change history where those records exist. Earlier material on data lineage and version control is useful for tracing inputs and identifying the version in force.

Score Risk Using Four Dimensions

A practical framework scores four dimensions on a scale from 1 (low) to 4 (high). The scale definitions should be written down before scoring begins. Assess each dimension using evidence about the model's intended and actual use; do not treat the score as a substitute for a reasoned explanation.

For an illustrative scoring policy, assign the following weights: materiality 35%, complexity 20%, uncertainty 25%, and reliance 20%. Let \(M,C,U,R\) denote the four scores. Calculate the weighted score as follows.

The weights sum to 1, so \(S\) is a weighted average on the same 1-to-4 scale. For this illustrative policy, Tier 1 applies when \(S\geq 3.25\), Tier 2 when \(2.50\leq S<3.25\), and Tier 3 when \(S<2.50\). An organization may instead use different thresholds, but it should specify them in advance and explain any changes.

Why the Weighted Score Works

The score is a transparent combination of the four assessed dimensions. Because the weights sum to 1, if all four scores equal \(k\), then the aggregate is also \(k\). For example, substituting \(M=C=U=R=k\) gives \(S=(0.35+0.20+0.25+0.20)k=k\). Increasing one dimension by one point increases \(S\) by that dimension's weight, holding the other scores fixed. Thus a one-point increase in materiality changes the score by 0.35, while a one-point increase in complexity changes it by 0.20. This makes the framework's priorities explicit and reproducible.

This justification does not establish that the weights are universally correct. They are policy choices. The useful properties are that the weights and thresholds are visible, the same rule can be applied consistently, and the resulting tier can be traced back to its inputs.

Worked Applications

Map Tiers to Controls

Tiering is useful only if it changes governance in a predictable way. The table gives one illustrative mapping. These are internal control examples, not universal regulatory requirements. An organization should align its requirements with its own policy and applicable obligations.

Controls should be specific enough that a reviewer can tell what is required and whether it happened. For example, “review model” is less useful than a requirement naming the reviewer, review timing, evidence to retain, and approval condition. Keep the inventory tier and its rationale current when the model's use, dependencies, implementation, assumptions, or impact changes. Findings and open issues can inform reassessment, but tiering should not replace the separate tracking and resolution of those findings.

Common Scoring Errors

• Ignoring reliance. A simple spreadsheet can have high risk when production decisions depend directly on it.
• Scoring only technical complexity. A sophisticated exploratory model may have limited direct influence, while a simple model may affect many rates.
• Dropping a dimension without recalibrating the policy. Every required dimension should be scored; do not silently omit an inconvenient score.
• Treating the numeric score as objective truth. Scores require documented judgment, consistent anchors, and an escalation route for exceptions.
• Failing to reassess changed use. A model's tier can change when it moves from exploration into production or becomes a more direct input to a decision.