How an explainable insurance rating engine works

A practical model for insurance rating that is traceable, reproducible and safe for underwriter-led product change.

Written by Alex Clark Published

An explainable rating engine does more than return a premium. It can show an underwriter which product version applied, which inputs were used, which tables and rules matched, and how each adjustment changed the result. That makes a rate decision reviewable before it goes live and defensible after a quote has been issued.

This guide is based on our team’s first-hand work translating underwriting logic into configurable rating and workflow systems. It uses a synthetic example only. It is not a rate filing, pricing recommendation or consumer insurance advice.

The model

A product definition is a chain of decisions

Explainability starts with structure. A product version should bring together the definitions that produce a price, rather than leave the important logic in a spreadsheet, a deployment or an underwriter’s memory.

Product version: the approved package of cover, definitions and effective dates used for a quote. It is the anchor for historical replay.

Factors and tables: the questions and lookup dimensions that select a base price, such as sum insured, location band or insured object type.

Rules and loadings: explicit eligibility conditions and adjustments, applied in an agreed order and retained in the calculation trace.

Levies and excess: separately visible charges and the selected claim contribution, so the customer price is not a black-box total.

Worked premium

A synthetic premium waterfall that reconciles

All values below are synthetic NZD, selected to demonstrate the trace rather than represent a real product or current levy treatment.

Calculation stepArithmeticNZD
Base premium from tableSelected from version 3 table$1,250.00
Territory loading12% × $1,250.00+$150.00
Claims loading8% × $1,250.00+$100.00
Subtotal$1,250.00 + $150.00 + $100.00$1,500.00
Selected excess adjustment−10% × $1,500.00−$150.00
Adjusted premium$1,500.00 − $150.00$1,350.00
Synthetic levyFixed amount+$45.00
Administration chargeFixed amount+$30.00
Tax15% × ($1,350.00 + $45.00 + $30.00)+$213.75
Final synthetic premium$1,350.00 + $45.00 + $30.00 + $213.75$1,638.75

A useful trace keeps the table row, factor values, rule identifiers, calculation order and money precision with this result. The underwriter should not need to reverse-engineer the final premium from a screen recording.

Reproducibility

Effective dates make a rate decision reproducible

A rate change should create a draft product version with a future effective date, not overwrite the product that produced yesterday’s quotes. At quote time, store the chosen product version and the effective date used to select it. Later, a reviewer can re-run the same inputs against that version and see the same trace.

That distinction matters when a quote remains valid across a rate change, when a renewal has its own pricing basis, or when an operator needs to explain why two similar submissions received different prices on different dates.

Underwriting control

Referral is not the same as an automatic decline

Automatic decline

Use for a clear, non-negotiable appetite boundary. The engine should state the failed condition and stop the purchase path without suggesting an underwriter will reconsider it.

Referral

Use where underwriting judgement can change the outcome. Keep the calculation trace and the triggering condition, pause binding, and route the case to the right person with enough context to decide.

Both need to be versioned with the product. Otherwise a team cannot later establish whether a result came from an approved appetite rule, a configuration error or a manual exception.

Rate change testing

Test a rate change as a product decision

  1. Build a compact control set

    Keep approved examples for ordinary risks, each important factor combination, table boundaries, referral cases and decline cases. Give every example an expected outcome, not just an expected premium.

  2. Run old and candidate versions side by side

    Compare premium deltas, referral outcomes and decline outcomes. Investigate every unexpected movement, including a price that did not move when the change should affect it.

  3. Test dates and rounding explicitly

    Exercise the day before, on and after the effective date. Include monetary rounding, table edges and selected excess options. These are common sources of quiet drift.

  4. Approve the trace, then observe production

    Record the reviewer, expected commercial effect and version. After release, reconcile a small set of real operational results against the approved test cases and retain a path to withdraw the version if needed.

Bring the rate sheet and the exceptions with it.

The automatic rating capability is built for versioned definitions and transparent calculation traces. Alongside our wider InsureOS platform and MGA operating model, this control operates directly alongside quoting, payment, and renewal workflows. We turn product definitions into versioned calculation models with testable audit trails for underwriting and operations teams.

Get in touch

We'd love to hear from you

hello@os.insure
Built by
The Caretakers

A small New Zealand product studio. We design, build, and operate software for insurers.

caretakers.io