How to Test an Insurance Rating Engine, Step by Step

Testing an insurance rating engine means proving that the price a customer is shown and charged matches the price the pricing team approved, for every risk, channel and product that matters. That requires four layers of testing: the model itself, its deployment, the mapping between the policy system and the engine, and the price that finally reaches the customer.

Most rating defects do not come from a wrong model. They come from the journey between a correct model and the customer: a factor mapped from the wrong field, a table deployed to one environment but not another, rounding applied in a different order, a channel discount missed, or a timeout that quietly returns a default.

This guide gives a step-by-step method that catches all of them.

Where Does a Rating Engine Sit in the Insurance Estate?

A rating engine sits between the pricing team's models and the systems customers use. Pricing builds and approves models and tables, the engine deploys them, the policy system and portals send risk data in, and the price comes back out with discounts, fees and taxes applied. Each handoff is a place where the price can change.

Common engines include Earnix, WTW Radar, Akur8 and hyperexponential, alongside rating built into core suites such as Duck Creek Rating and Guidewire's rating capabilities. Whichever engine you run, the same four layers need testing.

What Are the Four Layers of Rating Engine Testing?

Rating testing works in four layers, each owned by a different team and each catching a different class of defect. Skipping a layer is how a correct model produces wrong prices in production.

Layer 1 belongs to pricing and actuarial validation. Layers 2 to 4 are where QA adds most value, and where most production pricing defects actually originate.

How Do You Test a Rating Engine Step by Step?

Follow eleven steps, from gathering the sources to running regression on every deployment. The core idea is a golden test set: a versioned set of risks with expected prices approved by the pricing team, run against every layer and every environment.

Gather the Sources

Rating guide, model release notes, factor dictionary, discount and loading rules, fee schedule and tax rules for each product.

Build the Golden Test Set

Representative risks, boundary risks and risks linked to past defects, each with an expected price produced and approved by pricing.

Test Factor Behaviour

Each factor moves the price in the direction and by the amount the rating guide says.

Test Boundaries

Values either side of every band edge, such as age, vehicle or property group, sum insured and postcode territory.

Test Combinations

Pairwise and risk-weighted combinations, because interactions break pricing that looks right one factor at a time.

Test Deployment Fidelity

Run the golden set directly against the engine in each environment and compare with pricing's expected prices, within agreed tolerances.

Test Factor Mapping

Quote the same golden risks through the policy system and portals, and compare with the direct engine results. Differences reveal mapping errors.

Test Channel Parity

Quote the same risks through direct, each price comparison site, brokers and partners, and confirm every difference is explained by an approved rule.

Test Renewal Pricing

For UK home and motor, compare renewal prices with the equivalent new business price.

Test Fallbacks

Simulate engine and enrichment service timeouts and errors, and confirm no default price reaches a customer unnoticed.

Run Regression on Every Deployment

Model, table, discount and fee changes, as well as code and platform releases, all trigger the golden set.

Automating that trigger is what turns the golden set into a safety net, and our guide to automated regression testing covers the process, tools and frameworks that keep it running without manual effort.

What Makes a Good Golden Test Set?

A good golden test set is small enough to run on every deployment, broad enough to touch every factor and band, owned by pricing and versioned with each model. It combines representative risks, boundary risks and the risks behind past defects, each with an approved expected price.

Keep three properties in mind:

• Coverage over volume: A few hundred well-chosen risks usually beat tens of thousands of random ones, because each is there for a reason.
  
  

• Approved expectations: Expected prices come from pricing, with a named approver, not from yesterday's production output.
  
  

• Versioning: When a model changes, the expected prices change with it, and the old version stays available for re-running past releases.

How Should You Handle Tolerances and Rounding?

Agree tolerances in advance, write them down as requirements and test against them. Rating engines, policy systems and portals can round at different stages, and taxes such as UK Insurance Premium Tax can be applied before or after discounts and fees. Each choice changes the final price slightly.

Define, per product, the acceptable difference between engine output and charged premium, the order in which discounts, loadings, fees and taxes apply, and the rounding rule at each stage. Then test that every layer follows the same rules. A one-penny tolerance agreed and tested is far better than an unexplained one-penny difference discovered in a complaint.

Which Rating Defects Are Most Common?

The same defects recur across insurers and engines. Most are invisible to functional tests, because the quote completes and a plausible price appears.

How is Commercial and Specialty Rating Different?

Commercial and specialty rating combines engine output with underwriter judgement: manual loadings, referrals, schedule-level rating and overrides. Testing has to cover the automated price and the controls around judgement, including the limits on overrides and who can apply them.

Check that overrides stay within the bounds the underwriting authority allows, that referrals trigger when risk characteristics fall outside automated authority, that overridden prices flow correctly to documents and billing, and that the reason and approver for each override are captured.

How Does Virtuoso QA Touchstone Test Rating Engines?

Touchstone turns rating guides, model release notes and factor dictionaries into approved requirements and runs the golden test set across every layer and channel on each deployment.

Every expected price has a named approver, and every run is deterministic, so a difference is a real signal.

• The Analyst reads the rating guide, release notes and fee and tax rules, and proposes requirements for factor behaviour, boundaries, channel parity, renewal pricing and fallbacks, each citing its source.

• The Architect builds journeys that quote golden risks directly through the engine's API, through the policy system and through each channel's front end, then compare the results.

• The Autopilot runs those journeys on a deterministic engine in your CI pipeline on every model, table, discount, fee or code deployment.

• Data checks compare prices across layers and channels within the agreed tolerances.

• Change tracing links a new model version or table to every dependent requirement and journey, and proposes updated expected prices for the pricing owner to approve.

• Evidence shows, for each pricing change, which model version was tested, against which expected prices, approved by whom, with what results.

Rating is only one stage of the policy lifecycle, and Virtuoso QA’s insurance testing carries the same approved expectations through quote, bind, billing and claims, so a correct price stays correct all the way to the customer’s schedule and first payment.

Illustrative Scenario: a Model Redeploy and a Renamed Field

This scenario is illustrative and does not describe a specific firm.

A UK motor insurer's pricing team deploys a refreshed model. In the same release window, engineering renames a field in the policy system that holds the vehicle's postcode territory.

The engine is deployed correctly: the golden set run directly against the engine API matches pricing's expected prices. But when the same golden risks are quoted through the policy system, a subset of prices differ. The renamed field means the territory input falls back to a default band for policies created through one route.

The mapping is corrected before release, and the evidence shows the model version, the deployment fidelity pass, the mapping failure and the fix.

Interesting Reads

Duck Creek Testing: How to Automate P&C Insurance Application Testing

Test Automation for SAP Commerce Cloud

Guidewire Testing: What to Test, When, and How to Keep Up With the Release Calendar

Microsoft Dynamics 365 Test Automation: Enterprise ERP Testing with Self-Healing AI

The Best AI Testing Tools for Enterprises