How insurance rating validation works

The bar, the three flows, and the result.

An independent premium, calculated from your approved rates and rules, that must equal your policy system’s premium. Every case. To the cent. Here is how the simulator is built, what each flow proves, and what a result looks like.

The bar

When a premium doesn’t match what you filed, four questions follow.

One bar answers all four. Each case comes back as a match, or a mismatch that shows the first step where the two calculations part ways. Anything unexplained is listed as open, never counted as passed.

Edition

Does the system rate what you filed, for the right effective date?

Rows

After a rate change, did only the intended rows move, with your deviations still on top?

Leaked

What has already leaked on the policies you have written?

Platform

When you move to the cloud or a new rating engine, does the premium hold?

Three flows

Built independently. Designed to mirror yours.

The simulator is drafted from what you already have: rate manuals, filings, bureau content, or the algorithm your business team describes. Every expected value comes from your source of truth. Never from the system under test.

01 · Set-up

Base rates, your deviations, each edition in force on its date

The simulator reproduces your system’s premium on the cases your QA team rates today. That proves it mirrors your rating before it is used to check anything.

02 · The change

A case for every changed row, and for policies either side of the effective date

Say an update changes 150 rows out of 1,000, from a bureau circular, a filing or your own actuaries, and you deviate on 15. Your developers export the system’s rate tables and it checks them row by row. Any row added, dropped or changed outside the update is flagged. ISO ERC files import directly.

03 · Back-test and parity

Find what already leaked. Prove a platform move the same way.

Apply an older circular to the edition in force before it. Rows that disagree surface as candidates, and a person classifies each one. And re-rate the policies you have already written against the edition that should have applied, to find what has already leaked in written business. For a move to the cloud or a new rating engine: legacy premium, new platform premium, one simulator in between.

The result

Not just wrong. Where it went wrong.

Every case is a match, or a mismatch that shows the first step where the two calculations part ways. Anything unexplained is listed as open. Never counted as passed.

System premium and simulator premium side by side, equal on every row, to the cent. Every number invented.

Illustrative · every number invented

See the work

Every premium shows its work.

  • The calculation, step by step. Edition in force, loss cost, base rate, every factor with its deviation marked, the fee, the minimum, the premium.
  • The logic, as a diagram. New or renewal, the edition by effective date, base rate, factors, premium, with the path this case took lit up. Business labels, never code.
  • Which rows changed between editions. Declared, missing, wrong value, or changed outside the update. Each graded, each a line in the report your reviewers sign.
  • Who checked the AI. AI drafts the rulebook on your own LLM, inside your network, and lists every assumption. Your analysts approve it the way they review a rate filing. Once approved, no model in the path.

Who checked the AI

AI drafts. Your analysts approve. Then no model in the path.

AI drafts the rulebook on your own LLM, inside your network, and lists every assumption it made. Your analysts review it with the trace, the diagrams and the analysis in front of them, the way they review a rate filing.

Once approved, it runs deterministically. The same inputs give the same premium every time, with no language model in the execution path and no API key needed. Bring your own LLM, including fully local models.

Assumptions, for your analyst

  1. 1Deviation edition layers over the base, not merged.
  2. 2Either side of the date uses the edition in force on the policy date.
  3. 3Coverage premium compared before taxes and fees.
  4. 4Row 640 is not in the update; flagged, not applied.

Illustrative · every number invented

Questions

Common questions

The questions rating teams ask first.

Short answers to the questions every enterprise evaluation surfaces. Deeper dive for your technical team on the enterprise evaluation page.

Is VeriQuant independent of our policy administration system?

Yes. The simulator is built independently and designed to mirror your rating. It is drafted from what you already have, rate manuals, filings, bureau content, or the algorithm your business team describes, and never from the system under test.

It runs as plain, sandboxed logic with no dependency on the policy system, no database and no language model in the execution path, so the same inputs give the same premium every time. It works beside any policy system or rating engine.

How are rate books kept up to date in the simulator?

Rate tables are plain data, versioned alongside the rules and the worked examples, so every change has an author, a diff and a review. Each edition is selected by its effective date, with your deviations layered on top of the base.

When a rate changes, the simulator shows the per-case and aggregate premium impact before anyone commits the change. ISO ERC files import directly as change sets.

Does updating the simulator need developers?

No. AI drafts the rulebook on your own LLM, inside your network, and lists every assumption it made. Your analysts review it with the step-by-step trace, the logic diagram and the rows-changed view in front of them, the way they review a rate filing.

Once approved, it runs deterministically with no model in the path.

What does a result look like?

Every case is a match, or a mismatch that shows the first step where the two calculations part ways. Anything unexplained is listed as open and is never counted as passed.

Reports are self-contained HTML that can be opened from a file share, archived with a change record or published from CI.

What about our pricing platform, and does VeriQuant replace our test tools?

Pricing and actuarial platforms sit upstream of VeriQuant. They build the rates; VeriQuant checks what your policy system charges. An engine can’t grade its own homework.

No. VeriQuant does one job: it checks that your rating system charges the premium your filings say, and it runs beside the tools you have. If you later want API, UI or performance testing on the same engine, that is the Karate platform VeriQuant is built on. Start narrow: one line of business, one state.

Can it run inside our network?

Yes. VeriQuant deploys as a container or a single Java file inside your network. The licence is offline and nothing calls home. The deterministic parts run with no LLM and no API key at all.

An LLM is only used when drafting a rulebook, and you bring your own, including fully local models.

The next step

Bring us the rating case you worry about most.

A rate revision. A bureau update. A new state. An edge case nobody trusts. In 45 minutes, a senior member of our team walks your VP of Pricing, Head of QA and CIO through how the simulator is built for that case, and how your team runs the comparison in your own QA environment, exactly as you test today.

  • The three flows on your case: set-up, the change, the back-test
  • A live run of the private rate-revision demo, on synthetic data
  • A scoped build for one line of business and one state, then a demo and an evaluation on your rates

45

minutes

or email info@karatelabs.io

Need a rating check we don’t list? We build it during your evaluation.