Why Ratemaking Models Need Model Cards
A model can be technically documented yet still be misapplied if its users cannot quickly determine what it was built to do, which risks it covers, or who is accountable for it. A model card is a concise, maintained summary of those points. It helps a user decide whether a model is relevant to a particular decision before relying on its output.
For ratemaking, this matters because a model developed for one product, population, or decision may not be suitable for another. A model card does not replace technical documentation, validation evidence, an assumption register, or change records. It provides a practical summary that points users toward the model’s boundaries and accountable owners. A clear card supports sound governance aligned with the CAS Exam 8 (Advanced Ratemaking) syllabus.
What a Useful Model Card Says
A card should be brief enough to consult during a real decision, but specific enough to prevent users from confusing the model’s intended application with any use that happens to be technically possible. Its central fields answer different questions; combining them into a general statement such as “pricing model for actuaries” leaves important boundaries unclear.
| Field | Question answered | Useful content |
|---|---|---|
| Purpose | Why was the model developed? | The decision objective and the quantity the model estimates or supports |
| Target population | For which risks is it intended? | Product, coverage, geography, time basis, eligibility, and unit of exposure |
| Intended users | Who is expected to use or interpret it? | Roles with appropriate context, such as pricing actuaries or designated reviewers |
| Approved uses | Which decisions may rely on it? | Specific permitted applications, with conditions or required review steps |
| Ownership | Who is accountable for the model? | A business owner and a technical or operational contact, with responsibilities stated |
| Known limitations | Where might reliance be misleading? | Material constraints, unsupported situations, or dependencies users should recognize |
A model’s purpose is not the same as its approved use. For example, a model may estimate expected loss cost, while its approved use is to support a portfolio-level rate indication subject to actuarial review. Nor are intended users and approved uses interchangeable: a pricing actuary may be an intended user, but that does not authorize every decision the actuary could make with the output.
The target population needs operational boundaries. “Commercial property” may be too broad if the model was developed only for a particular coverage, set of states, or type of insured location. State the unit to which an output applies, such as a location-year, policy-year, or vehicle-year. If exclusions are important, name them rather than relying on users to infer them.
A Short Justification for Population Boundaries
One reason to state the target population is that a portfolio summary depends on which risks are included and how much exposure each represents. Suppose a model produces an expected loss cost \(m_j\) per exposure for each segment \(j\), and segment \(j\) has \(E_j\) exposures. Assume the segments form a complete, non-overlapping partition of the portfolio; the \(m_j\) values are expected losses on the same basis and period; and the exposures are measured consistently. Then expected losses in segment \(j\) are \(E_jm_j\). Adding segment expected losses and dividing by total exposure gives the portfolio expected loss per exposure:
The result is exposure-weighted because each segment’s expected losses contribute in proportion to its exposure. An unweighted average of segment predictions does not generally represent the portfolio. The calculation also depends on the intended population: adding a segment outside the model’s supported scope does not become appropriate merely because an output can be produced for it.
Worked Examples
Worked Example: Turning a Brief into a Model Card
A hypothetical insurer has developed a model using 2022–2024 data for standard commercial property policies in two states. Its output is expected annual covered loss per insured location. The pricing team wants to use it to support prospective rate indications for eligible policies. Excess property policies and locations in other states were not included. Draft the key model-card fields and identify a common scope error.
Method. Translate the brief into separate fields, keeping the estimated quantity, covered population, users, and decision distinct.
Purpose: Estimate expected annual covered loss per insured location to support prospective commercial property ratemaking.
Target population: Eligible standard commercial property insured locations in the two included states, on an annual location basis. The development data cover 2022–2024. Excess property policies and locations in other states are outside the stated target population.
Intended users: Designated pricing actuaries and reviewers responsible for interpreting the output.
Approved use: Support prospective rate indications for eligible standard commercial property risks, subject to the insurer’s applicable actuarial and approval processes. The model card should not imply that the model alone determines a final premium.
Ownership: Identify the business owner accountable for the pricing application and the technical owner responsible for maintaining the model and its documentation. The brief does not provide names, so the card must obtain them rather than invent them.
Known limitations: The model’s stated scope excludes excess policies and locations in other states. The card should also point users to the relevant technical documentation for any further documented limitations; the facts given do not establish additional limitations.
Common mistake avoided: Writing “for commercial property” and treating that phrase as permission to apply the model to every commercial property risk. The correction is to preserve the stated product, geography, and exclusion boundaries in the target population and approved-use fields.
Check: The purpose names the quantity and objective; the target population names eligible risks; and the approved use explains how the output may support a decision. These fields are related, but none substitutes for another.
Worked Example: Describing a Portfolio Output Correctly
A hypothetical model is approved for a defined portfolio with two eligible segments. It predicts annual expected loss costs of $420 per exposure for Segment A and $660 for Segment B. The portfolio has 800 exposures in A and 200 in B. A user proposes to put the simple average, $540, in the model card as the portfolio’s expected loss cost. Determine the appropriate summary and explain what the card should say about scope.
Method. Use the exposure-weighted result because the segment predictions are per exposure and the portfolio contains different numbers of exposures in the two segments. The assumptions are that both predictions use the same annual loss basis, exposures are comparable, and the two segments together cover the stated portfolio.
Segment A’s expected losses are \(800 \times \$420 = \$336{,}000\). Segment B’s expected losses are \(200 \times \$660 = \$132{,}000\). Total expected losses are:
Total exposure is \(800+200=1{,}000\). Therefore the portfolio expected loss cost is:
The card should report $468 per exposure for this hypothetical portfolio, with the population and annual basis stated. The proposed simple average is \((\$420+\$660)/2=\$540\), which gives each segment equal weight despite their unequal exposure counts. It is not the portfolio average for these data.
Common mistake avoided: Averaging segment predictions without considering segment size. The correction is to multiply each per-exposure prediction by its exposure, add expected losses, and divide by total exposure.
Check: The result lies between $420 and $660, and its position is closer to $420 because 80% of exposures are in Segment A. This is consistent with the calculation.
Worked Example: Checking a Proposed Use Against the Card
A hypothetical model card states that Model 4.1 estimates annual expected loss cost for eligible renters policies in State R. Designated pricing actuaries may use it to support portfolio-level rate indications after review. It was not approved for claim-by-claim decisions or for other lines of business. The pricing team proposes using its output to support a renters rate indication in State R. A claims manager proposes using the same output to prioritize individual claims. Decide how each proposal should be handled and identify the documentation needed if the model’s scope is to change.
Method. Compare each proposed decision with the card’s stated purpose, population, user roles, and approved uses. A technically available output is not evidence of approval for a different decision.
Pricing proposal: It matches the stated product and state, and its objective is a portfolio-level rate indication. The designated pricing actuary may use it for that purpose, provided the stated review condition is met. The team should confirm that the particular risks are eligible under the card before relying on the output.
Claims proposal: It is outside the approved use. It involves individual claim prioritization rather than a portfolio-level ratemaking indication, and the claims manager is not identified as an intended user. The manager should not treat the pricing approval as authorization for this use.
If scope is to change: The accountable owner should arrange for the proposed change to be considered under the organization’s applicable governance process. If authorized, the card must be updated to identify the revised purpose, population, users, approved use, ownership, and relevant limitations, and it must identify the applicable model version. The card should not be silently broadened by a user.
Common mistake avoided: Assuming that approval to use an output for one ratemaking purpose carries over to every decision involving the same risks. Approval is purpose- and scope-specific; the claims proposal requires separate authorization and appropriate assessment before it could be represented as an approved use.
Check: The first proposal is within the stated purpose subject to its review condition. The second is outside the stated purpose and user scope. Neither conclusion depends on whether the model can technically generate a number for the proposed application.
Keeping the Card Useful
A card is useful only if its summary remains aligned with the model and the way the organization has approved its use. Identify the model version and the date or status of the card so that a reader can tell which model the description concerns. When model facts or approved uses change, the card should be reconsidered alongside the relevant assumption registers and change records; it is not a substitute for either.
Limitations should be specific enough to guide a decision. “Use with caution” gives little direction. “Not approved for policies in other states” or “supports portfolio-level indications, not individual claim decisions” tells the user what boundary matters. Do not invent limitations that have not been established, but do not omit known boundaries simply because they appear elsewhere in technical material.
Likewise, ownership should describe accountability rather than merely list a team name. A reader should be able to determine who is responsible for the business application and where to direct questions about technical maintenance. If those responsibilities are split, state the distinction.
Check Your Understanding
For each problem, distinguish the model’s stated scope from what a user proposes to do.
- A hypothetical model estimates annual expected loss per insured building for eligible small commercial property risks in State M. Its card permits pricing actuaries to use it in portfolio-level rate indications after review. A user wants to apply it to an excess property product in State M. Identify the relevant scope mismatch and state what the user should do. (Answer: Excess property is not established as part of the target population or approved use; do not treat the output as approved for that product, and seek the applicable authorization and scope assessment.)
- A model predicts $300 per exposure for Segment X and $500 for Segment Y. There are 900 exposures in X and 100 in Y, and both estimates are on the same annual basis. Calculate the portfolio expected loss cost and explain why the simple mean is not appropriate. (Answer: \((900 \times \$300 + 100 \times \$500)/1{,}000 = \$320\) per exposure; the simple mean of $400 gives equal weight to segments with unequal exposure counts.)
- A card says that designated pricing actuaries may use a model to support annual rate indications for eligible personal watercraft policies in State N. An underwriting manager proposes using it to set an individual policy’s premium override. Is this within the stated approved use, and which card fields explain the answer? (Answer: Not as stated; the approved use is a portfolio-level annual rate indication, and the intended-user field does not identify the underwriting manager as an approved user.)
- A model was developed for standard policies in States A and B, but the card only says “property pricing model.” A reviewer is asked to decide whether a State C portfolio is in scope. What must be clarified before the card can answer the question? (Answer: The target population must state the geographic boundary and relevant product or policy eligibility; with the stated development scope, State C is not established as supported, so use there should not be inferred.)
- A model card identifies the pricing team as owner, but says nothing about who handles technical maintenance. The business purpose and target population are clear. What accountability information is missing, and why does it matter? (Answer: The card should identify the technical owner or contact and distinguish that responsibility from business ownership; otherwise users cannot tell where to direct maintenance or technical questions.)