Why Model Changes Need Approval Controls
A ratemaking model can change through more than a new statistical fit. A data transformation may alter what a field means; an assumption may change the indicated premium; code may implement a formula differently; or a model revision may add a new rating variable. Without defined approval controls, an organization can release an unreviewed change, lose track of what was authorized, or be unable to show that production matches the approved version.
Approval controls specify how a proposed change is classified, what evidence must support it, who may approve it, and what records must be retained before release. The controls should be proportionate: a verified format correction does not normally need the same governance as a new model structure. At the same time, an apparently small code edit can have substantial consequences if it changes rating logic.
There is no single universally required classification system or monetary threshold. An insurer should define its own policy, align it with its governance framework and applicable regulatory obligations, and apply it consistently. The categories and roles below are an illustrative internal framework, not a regulatory rule. Where a rate filing, notice, or other external authorization is required, internal approval does not replace it.
Classify the Change Before Assigning Approvals
Classify a change by its purpose, scope, and potential to alter model meaning or rating outcomes—not merely by the number of lines of code or the size of a file. A change may affect several areas at once. When it does, route it according to the most consequential affected area rather than selecting the easiest category.
| Illustrative category | Typical scope | Typical evidence and authority |
|---|---|---|
| Routine controlled change | Equivalent formatting, documentation, or a pre-authorized operational correction that does not change data meaning or rating logic. | Change description, focused checks, and approval under delegated operational authority. |
| Controlled nonstructural change | A change within an approved methodology, such as a data mapping correction or an assumption update within an established range. | Impact rationale, validation or reperformance evidence, relevant technical review, and approval by the designated model or pricing owner. |
| Structural or elevated-risk change | A new rating variable, a changed model form or population, a change outside approved assumption bounds, or a change with unresolved material limitations. | Broader validation and independent review, formal governance approval, and any required external filing or authorization before use. |
The classification is a routing decision, not a substitute for analyzing the change. For example, calling an assumption update “routine” does not establish that its effect is acceptable. Conversely, the next step after routing may include detailed impact analysis, which should be conducted under the organization’s applicable review process.
Evidence, Authority, and Release Records
Evidence should be specific to the change. A useful submission generally states the current and proposed state, the reason for the change, affected data and model artifacts, the intended effective date, and any dependencies. It should attach checks that address the actual failure modes: data reconciliation for a mapping change, calculation reperformance for code, or documented rationale and sensitivity evidence for an assumption update.
Approval roles should be explicit. A technical reviewer assesses whether the change is correctly designed and supported; an accountable model or pricing owner accepts the business and actuarial decision; and a release owner verifies that release conditions are satisfied. These roles can sometimes be held by the same person under an approved policy, but separating preparation, independent review, and release authorization reduces the risk that an error passes unchecked. A reviewer’s sign-off is not automatically the same as approval to use a change.
Release records connect the decision to the actual artifacts. They should identify the approved data extract or specification, code and model versions, configuration or factor tables, test results, approval date, release date, and the person authorizing deployment. Where version control is used, a commit identifier or other immutable version reference helps make the link precise. Record any conditions, such as an effective-date restriction or an outstanding item that must be resolved before release.
How the Approval Logic Follows
The purpose of tiering is to match review effort to the risks created by the change. A formatting-only edit has a narrow set of plausible errors; a changed model structure can affect which risks receive which rates and may require broader scrutiny. This is a governance rationale, not a claim that every change in a given category has the same impact.
Record what will change, why it is changing, and which data, assumptions, code, model components, and rating uses are affected.
Compare the scope with the organization’s written definitions. If multiple categories apply, use the most stringent applicable route.
Require checks that demonstrate the proposed change works as intended and that relevant limitations have been considered. Obtain the reviews assigned to that category.
Confirm the required approvers have acted, release conditions are met, and the production artifacts match the approved versions. Record the decision and deployment.
The final identity check follows directly from the purpose of approval. Approval applies to a particular proposed model and its supporting artifacts. If production uses a different code version or configuration, the approved decision does not establish that the deployed version was reviewed. Therefore, the release record must link approval to the exact version released, and any post-approval change must be routed again under the change policy.
Worked Examples
Worked Example: Converting Claim Amounts Stored in Cents
A hypothetical insurer’s approved model expects claim amounts in dollars. A new upstream feed supplies the same amounts in cents, so a developer proposes dividing the incoming field by 100 in the data pipeline. One claim is recorded as 2,487,500 cents. Classify the change, identify evidence and authority, and state a release check.
Step 1: Calculate the intended conversion. The amount in dollars is \(2{,}487{,}500 \div 100 = 24{,}875\). The existing model input is still dollars; the source representation has changed.
Step 2: Classify the change. This is not just a label or display edit: executable transformation code is changing. Under the illustrative framework, treat it as a controlled nonstructural change because the purpose is to preserve the existing field meaning and rating methodology, not to introduce a new one. If investigation showed the incoming field had a different definition—for example, it included an additional amount not present in the old field—the change would need a more elevated review.
Step 3: Specify evidence and approval. Retain the source-field definition, the mapping specification, and reconciliation checks showing that test records convert correctly. Test boundary values and missing-value handling as well as the example record. Obtain technical review of the transformation and approval from the designated data and model owners.
Step 4: Define release conditions. Confirm that the production job uses the approved conversion code and that a representative output is in dollars before it enters the model. Record the approved code version, test results, approvers, and release identifier.
Common mistake. Treating every change described as “unit conversion” as a routine documentation edit skips the fact that executable code has changed. The correction is to classify the implementation as a controlled code and data-pipeline change, then test the transformation and route it under the appropriate authority.
Worked Example: Updating a Trend Assumption
A hypothetical personal-lines pricing team uses a one-year trend assumption of 4% in a model. Its written policy permits the designated pricing owner to approve trend updates from 3% through 6% after review; changes outside that interval require elevated governance approval. The team proposes 5%. The affected annual premium base for an illustrative calculation is $12,000,000. Determine the modeled premium change from applying the new trend relative to the old trend, and identify the approval route.
Step 1: Calculate the relative change. Since the old and new trend factors are 1.04 and 1.05, respectively, the relative change is \(1.05/1.04-1=0.0096153846\), or about 0.9615%.
Step 2: Apply the relative change to the stated base. The modeled dollar difference is \($12{,}000{,}000 \times 0.0096153846 = $115{,}384.62\), rounded to the nearest cent. Equivalently, the old indicated amount is \($12{,}000{,}000 \times 1.04 = $12{,}480{,}000\), and the new amount is \($12{,}000{,}000 \times 1.05 = $12{,}600{,}000\); their difference is \($120{,}000\). These two calculations use different interpretations of the base: the first applies the ratio of trend factors to an already trended old amount, while the second applies each factor to the same untrended base. For the stated $12,000,000 untrended base, the correct difference is $120,000.
Clarify the calculation before using it. The problem states that $12,000,000 is the untrended premium base, so the applicable calculation is \(12{,}000{,}000(1.05-1.04)=$120{,}000\). The ratio calculation would be appropriate only if $12,000,000 represented the already-trended old premium. This distinction must be made explicit in an approval record.
Step 3: Classify and route. The proposed 5% is within the stated 3%–6% delegated range, so it follows the controlled nonstructural route in this hypothetical policy. The designated pricing owner approves after review; the model owner confirms which model version uses the assumption. A proposal above 6% would require the elevated route under the stated policy.
Step 4: Retain supporting evidence. The record should include the rationale for 5%, the applicable policy range, the calculation using the correctly defined premium base, relevant sensitivity or validation evidence, the reviewed assumption version, and the approval. Any separate filing or effective-date requirements must also be satisfied before use.
Common mistake. Applying a ratio of trend factors to an untrended base, or applying a percentage-point difference to an already-trended base, confuses the denominator. State what the premium base represents before calculating; here, the stated untrended base gives a $120,000 difference.
Worked Example: Adding a Rating Interaction and Releasing It
A hypothetical insurer has a base premium of $500. Its approved rating algorithm multiplies that amount by a class factor of 1.10 and a territory factor of 1.20. A proposal adds an interaction factor of 0.95 for one specified class-territory combination. Determine the old and proposed premiums for that combination and the required governance approach.
Step 1: Recalculate the current premium. Under the approved algorithm, \($500 \times 1.10 \times 1.20 = $660\).
Step 2: Calculate the proposed premium. Applying the proposed interaction gives \($500 \times 1.10 \times 1.20 \times 0.95 = $627\). The difference for this one example is \($627-$660=-$33\). This calculation describes the example combination; it does not by itself establish the overall effect of the change.
Step 3: Classify and obtain approval. Adding an interaction changes the rating structure, even though the arithmetic is a single additional multiplication. It belongs in the structural or elevated-risk category under the illustrative framework. The submission should document the interaction’s rationale, the affected combinations, model and validation evidence, and relevant limitations. It should receive independent technical review and the designated governance approval, as well as any other required internal or external authorization.
Step 4: Gate the release. After approval, the release owner verifies that the approved specification, code, and factor configuration are the versions being deployed. The record includes their version identifiers, test evidence, approvals, release date, and any conditions of use.
Common mistake. Routing this as a routine code edit because it adds only one multiplication ignores that the model now treats a class-territory combination differently. Classify based on the change in rating logic, not the apparent size of the code patch.
Common Approval-Control Failures
- Using one approver for every change. A single approval route may be too burdensome for low-risk maintenance and too weak for structural changes. Define categories and authorities in advance.
- Confusing review with approval. Technical review evaluates evidence; an accountable approver authorizes the decision under policy. Record both when they are separate roles.
- Approving a description instead of an artifact. “Trend updated” does not identify the exact assumption, model, or code version approved. Link the decision to specific versions.
- Assuming internal approval satisfies external requirements. Internal governance cannot replace a required filing or authorization. Identify those requirements before the release decision.
- Skipping re-approval after a change to the approved package. If the implementation differs from the approved package, pause release and determine whether the difference requires a new review and approval.
Well-designed approval controls make decisions traceable without treating every edit as a major model redevelopment. The central discipline is to identify what changed, route it according to its scope, obtain evidence and authority appropriate to that route, and preserve a record that connects the decision to the released version. These practices are aligned with the CAS Exam 8 (Advanced Ratemaking) syllabus.
Check Your Understanding
For each hypothetical situation, identify the appropriate route under the stated or implied control logic and the key evidence or release check.
- A team corrects a misspelled heading in an internal model report. No data, calculations, or rating outputs change. What category is appropriate, and what should still be recorded? (Answer: Routine controlled change; record the edit and verify the report output, with the delegated approval required by policy.)
- A feed changes claim amounts from dollars to cents. A sample record is $6,340 in the old feed and 634,000 in the new feed. What conversion is required, and what evidence should support release? (Answer: Divide the new value by 100 to obtain $6,340; retain the mapping specification, reconciliation and boundary tests, reviewer and approver sign-offs, and approved code version.)
- A hypothetical policy permits a trend assumption between 2% and 4% to be approved by the pricing owner after review. The proposed assumption is 3.5%. What is the route, and which facts should the record establish? (Answer: Controlled nonstructural route under that policy; document the rationale, confirm 3.5% is within the delegated range, retain supporting review evidence, and identify the approved assumption and model versions.)
- A model team proposes a new interaction between vehicle use and territory. The code change is small and a sample premium decreases from $900 to $855. How should it be classified, and does the sample establish the overall effect? (Answer: Structural or elevated-risk change; obtain the required broader review and approval. No—the sample only demonstrates that one illustrated premium changes by $45, not the overall effect.)
- An approved release record identifies code version A17, but the production package is version A18. What should the release owner do? (Answer: Block release until the discrepancy is resolved; verify that production uses the approved artifacts or obtain the required review and approval for the changed version, then update the release record.)