Underwriting & Rating System Modernization

Part 3 modernized the system of record. This part goes to the system the record depends on for its most consequential number — the price. The rating engine and the underwriting rules that gate it are an insurer’s crown jewels: they are where the company’s actuarial judgment, its competitive position, and its regulatory filings all converge into code. They are also, reliably, the most undocumented code in the building. Recovering them faithfully is the single highest-leverage move in an insurance modernization, and the one most likely to go wrong.

Why this is the crown jewel — and the crown risk

Everywhere else in software, a bug is a defect to fix. In a rating engine, a bug is a mispriced policy — and depending on direction, that’s either margin you’re giving away on every renewal or a premium that no longer matches what you filed with the state. The blast radius isn’t one transaction; it’s every policy the rule touches, compounding silently until someone notices.

What lives in this system:

• The rating algorithm — how base rates combine with rating variables (territory, class, exposure, prior history) to produce premium.
• Credits and surcharges — every modifier, and critically, the order they apply in, because order changes the answer.
• Minimum premiums, rounding, and capping rules — the unglamorous arithmetic that’s wrong more often than anyone expects after a careless rebuild.
• Underwriting rules — the gates that decline, refer, or accept a risk, and the conditions attached.
• State-by-state variation — all of the above, multiplied by every jurisdiction you write in, because each state regulates its own filed rates and forms.

That last dimension is what makes insurance rating uniquely dense. The same product can rate differently in twenty states because twenty regulators approved twenty variations, each negotiated over years. The record of those variations is the code that executes them.

The rules are tribal knowledge with a regulator attached

The tribal-knowledge series makes the general case: the rules a system runs on live in the code and in a few people’s heads, not in documentation. Rating is that problem at maximum intensity, with two aggravating factors.

First, the knowledge is leaving. The people who built and tuned these engines are part of the retiring COBOL generation from Part 2 — average age around 58, with roughly 10% of the workforce retiring annually (IBM, 2020, via Fujitsu). When they go, they take the why with them: why a surcharge caps where it does, why one class of risk gets special handling, what a cryptic rating step was actually compensating for.

Second, the rules are accountable. A regulator can ask you to demonstrate that your system rates in accordance with your filings. “We’re not entirely sure how it works, the person who knew retired” is not an answer that survives a market-conduct examination. This is why recovering rating rules as explicit specs isn’t just modernization hygiene — it’s risk reduction that pays off whether or not you ever rebuild the engine.

Recover the rules as living specs — first

The highest-leverage step in the whole program is to turn the rating and underwriting logic into living specifications before touching the rebuild:

1. Read the entire rating path, not a sample. Rules are spread across programs, tables, copybooks, and config; a partial reading produces a partial rule, which is worse than none because it looks complete. The full algorithm — including the state overrides and the edge-case branches — has to be recovered as a whole.
2. Separate genuine rules from plumbing and fossils. A rating program interleaves real pricing logic with data access, error handling, and dead branches left over from products you no longer sell. Capturing the rules means telling the live rules from the fossils — and capturing a fossil as a live rule means faithfully reproducing pricing the company abandoned years ago.
3. Make each rule traceable and reviewable. Every recovered rule points back to the code it came from, so an actuary or senior underwriter can confirm it’s real, correct an inferred intent, and supply the why the code can’t.
4. Decide deliberately, rule by rule. Surfacing a rule lets you finally choose: replicate it exactly (the default for anything load-bearing and filed), fix it (if it’s a genuine error), or retire it (if it’s a fossil) — on purpose, with the decision recorded. Buried rules get the default decision, which is “reproduce blindly or lose silently,” and you don’t get to pick which.

The output is an asset in its own right: an auditable, current statement of how the company rates and underwrites, owned by the team rather than trapped in code only a retiree understands.

A note on rating tables specifically: much of an engine’s behavior lives not in code but in data — rate tables, factor tables, territory and class lookups. It’s tempting to treat that data as “just configuration” you can lift wholesale, but the tables and the code that interprets them are a single system. The same factor table can mean different things depending on how the program applies it, the rounding it does between steps, and the order it combines factors in. Recovering the rules means recovering the interaction of table and code, not just exporting the spreadsheets — another place a careless rebuild silently changes the price.

Then rebuild, and prove it to the cent

Recovered specs become the basis for the rebuild — but the specs are a hypothesis until proven against the running system. That proof is parity validation, and on a rating engine it is absolute: the modern engine runs in parallel with the legacy one on real submissions, and every output premium and underwriting decision is compared across the full range of states, products, and edge cases. Identical inputs must produce identical outputs. A one-cent divergence on a rounding rule is a finding to resolve before cutover, not a rounding error to wave through — because in aggregate, across a book, one cent is real money and a filing mismatch.

Only once a rating slice — typically a product or a line of business — proves parity does a facade begin routing live quotes to it, gradually, with rollback available. The legacy engine keeps pricing everything it hasn’t been proven safe to hand over.

Where AI changes the economics

Recovering an entire rating path by hand is the work that historically made rating modernization a multi-year slog: it’s slow, it requires the scarcest people, and sampling isn’t safe. AI-accelerated discovery reads the full rating codebase, tables, and state overrides together and drafts the algorithms and rules as specs — the analysis-time gain of roughly 10× over manual review that makes comprehensive recovery feasible. Actuaries and senior engineers validate the drafts; parity validation proves the rebuild. AI does the reading at the scale rating demands; humans and evidence decide what’s true and what’s sacred.

Replicate exactly, unless you decide otherwise

Two honest limits. First, the code tells you what a rule does, never why — and on a rating rule, the why decides whether it’s sacred policy or a disposable workaround. Where the actuary or underwriter who knows is still here, capture that reasoning now; where they’re gone, the safe default is to replicate exactly what the code does, because you can’t justify changing pricing you don’t understand. Second, modernizing the engine is not a license to silently “improve” the rates — any change to filed behavior is a business and regulatory decision made deliberately, not a side effect of a rebuild. Parity is the guarantee that you changed nothing you didn’t choose to change.

Where this leads

We’ve priced and gated the risk. The other half of the core is what happens when that risk turns into a loss. Part 5, Claims System Modernization, takes on adjudication, reserving, and the claims lifecycle — where the rules are just as undocumented and the cost of getting them wrong shows up directly in loss reserves and customer trust.