Rate changes without the risk: a step-by-step process for pricing teams
A step-by-step process for making insurance rate changes safely, from analysis and draft versions to testing, approval, release and monitoring, and where AI fits in.
Rate changes are routine for any pricing team, but each one carries risk. A wrong factor, a missed band or a rule applied in the wrong place can misprice a book for weeks before anyone notices. A clear, repeatable process reduces that risk and makes it practical to change rates more often.
This article sets out a process that works for most personal and commercial lines, and shows where AI can speed it up.
1. Analyse and decide
Every rate change starts with analysis: claims experience, inflation, mix of business, competitor positioning and any regulatory requirements. The output should be a clear statement of what is changing and why, for example "increase the London region factor from 1.25 to 1.30 to reflect higher vet-fee inflation".
Write the change down in this form before anyone touches the model. It becomes the reference for testing and approval.
2. Record the baseline
Before changing anything, run the current model's full test suite and keep the results. This baseline shows what every test case priced at before the change, so you can see exactly what moved afterwards.
If the test suite is thin, add cases now. Every factor being changed should have tests on either side of it, and every rule should have a case that triggers it and a case that does not.
3. Make the change in a draft
Never edit the live model. Create a new draft version, copied from the version in force, and make the change there. Live quotes continue to use the published version until the draft is approved and released.
Keep the change as small as possible. If several unrelated changes are planned, consider separate versions so each can be tested and approved on its own.
4. Test and review the differences
Run the test suite against the draft and compare it with the baseline:
- Tests the change was meant to affect should move by the expected amount.
- Tests the change was not meant to affect should not move at all.
- Any unexpected movement needs an explanation before the change goes further.
Update expected results only for cases the change was meant to affect, and record why each one changed. Our article on regression testing for insurance pricing covers this in more detail.
5. Check individual quotes
Tests show that prices moved as intended. It is also worth looking at how a few individual quotes were calculated, especially near band boundaries and for risks close to decline or referral rules. A full trace of each step shows whether the new factor was picked up in the right place. The quote debugging guide explains how to read one.
6. Approve
A named person, separate from the person who made the change where possible, reviews the change statement, the test differences and any sample quotes, then approves the version. The approval, the approver and the time should be recorded.
7. Release
Publish the approved version. Every quote from that point records which version priced it, so you can always tell which rates applied to a given policy. If something goes wrong, you can move back to the previous version.
Plan the timing. For regulated lines in the US, the effective date must match the approved filing. For aggregator business, consider releasing outside peak hours.
8. Monitor
The change is not finished when it is released. Watch quote analytics over the following days:
- quote volumes and conversion;
- average premium against the expected movement;
- the share of quotes declined or referred;
- errors and response times.
If the numbers move differently from the analysis, investigate before the next change.
Where AI helps
AI can speed up most of these steps without removing the controls:
- Drafting the change. An AI agent can apply a described change to a draft version, for example a new factor or an added table row.
- Running tests. The agent can run the test suite after each edit and report which tests passed and which failed, with the actual and expected values.
- Explaining differences. The agent can summarise what moved and why, using the quote traces.
- Preparing the approval pack. The agent can collect the change statement, test results and sample quotes in one place.
The approval and release stay with people. On Ptally, AI clients connected through MCP can edit drafts and run tests, but only people can approve and publish a version.
Getting started
On Ptally, rate changes are managed for you by the team that built your model, with a draft, tests and an approval step every time. There is no implementation fee and nothing to pay upfront. Talk to our team.