It is not a configuration change
The instinct from ordinary product engineering is that a factor is a number in a
table, so changing it is an update statement. In personal lines in much of the
world it is not: the rating algorithm and its tables are filed with a
regulator, and in the United States that filing goes to each state's insurance
department separately.
Three consequences follow immediately, and a candidate who names them has
understood the domain rather than the system.
The change is per jurisdiction. "The rating algorithm" is really fifty
algorithms sharing a skeleton, each with its own approved values and its own
effective date, and a change may be approved in some states and pending in
others.
It has an effective date that is not the deployment date. The new rate
applies to business written on or after a date the regulator agreed. Deploying
the code on Monday does not make the rate live on Monday, and deploying it late
does not move the date.
It applies to new and renewing business from that date, not to policies
already in force. An existing annual policy keeps its price until renewal, at
which point it is re-rated with whatever is filed and effective then.
Effective dating is the design
Because of the above, rates are never overwritten. Every table is a set of
versions with validity periods, and a quote selects the version that was
effective for its own dates.
rate_table: motor_liability_base, state IL
version effective_from effective_to filing_ref status
14 2025-04-01 2026-08-01 IL-2025-0412 superseded
15 2026-08-01 null IL-2026-0778 approved
The selection rule is the part to get right and the part interviews probe. The
version is chosen by the policy's effective date, not by today's date and
not by the quote's creation date. A quote issued in July for a policy incepting
in September is priced on version 15, because that is what will be in force when
cover attaches. Selecting on now() is the single most common implementation
bug here, and it produces quotes that silently reprice depending on when someone
opened them.
In-flight quotes are the awkward case
A quote is an offer with a validity period, commonly thirty days. So on the day a
rate changes there is a population of outstanding quotes priced on the old
version, and somebody has to decide what happens to them.
The usual answer is that a quote is honoured at the price quoted for its stated
validity period, because withdrawing a price a customer was given is both a
conduct problem and a commercial one. That means the quote must have stored
the version it used, not merely the number it produced, so that binding it
later reproduces the same calculation rather than re-running against current
tables.
The alternative — re-rate on bind and show the customer a different number than
they were quoted — is a decision some carriers make deliberately for long-dated
quotes, and it has to be disclosed. Either way it is a product decision the
system must be able to express, not a default that falls out of how the code
happens to work.
Reproducibility is the requirement that shapes everything
A market conduct examination samples policies and asks the carrier to
demonstrate that each was priced with the filed algorithm. Answering that means
reconstructing a calculation from years ago, exactly.
So the record against a quote is not the premium. It is the inputs, the version
of each table used, the filing reference, the order of operations, the rounding
applied at each step, and the resulting figure. Recomputing from today's tables
is not evidence of anything, because the tables have moved.
This is also why the sequence of a rating calculation is a specification rather
than an implementation detail. Changing the order in which a discount and a term
factor are applied changes the last penny, and across a book that is both a real
number and a deviation from what was filed.
Testing is a replay, not a unit test
The regression technique that fits this problem is unlike normal software
testing: keep a corpus of historical quotes with their known outputs, and re-run
every one against each build.
The failure it catches is specific and common. Rating tables share components —
a territory table used by three products, a rounding helper used by all of them
— so a change aimed at one product moves the price of another. Nobody notices
until a filing audit or a customer complaint, because nothing errors. A corpus
replay turns that into a failing build.
The corpus has to be per jurisdiction and per version, and it grows rather than
being replaced, because the purpose is to prove that old calculations still
reproduce.
Rollback is not a redeploy
Ask what happens when the change is wrong and has been live for a day. Reverting
the code does not undo the quotes issued and the policies bound at the wrong
price, and those are contracts.
The realistic handling is that the versioned data makes the exposure
computable — every policy priced on version 15 is identifiable — and the
remediation is a business decision: honour, re-rate at renewal, or refund the
difference, usually with the regulator informed. What the engineering must
provide is the list, quickly and defensibly.
Worth naming the one part that genuinely is a deploy: elements of the pipeline
that are not filed, such as which quotes go to a referral queue or how a broker
portal displays a price, can change on a normal release cadence. Knowing which
side of that line a given change falls on is what lets a team move quickly on the
things that permit it.
Deploying the code and making the rate effective are two different dates, and
the system's real obligation is to reproduce, years later, exactly which
version priced a given policy.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).