How to Set Up Your Own Rating and Premium Calculation Rules in Openkoda PAS

What a Rating Engine Has to Be Good At

Pricing is the part of an insurance product that changes most often and is trusted least when it changes. Somebody notices the young-driver book is running hot, and between noticing and repricing there is usually a spreadsheet, a developer, a release and a nervous week.

A rating engine worth configuring has to be good at four things, and only one of them is arithmetic:

Readable rates. The numbers live in grids an underwriter can read without a translator, because the person who knows the rate is right is rarely the person who can edit code.
Honest structure. Bands that step rather than overlap, factors separate from the base rate, charges separate from the premium.
A visible calculation. You should be able to see the order in which the factors apply, in words, not infer it from a formula.
Cheap experiments. Changing a rate and seeing what it does to a real risk should cost seconds and commit nothing.

This walkthrough builds a motor rating engine from scratch, four tables, one calculation and two charges, prices a real risk with it, and then reprices that same risk after a one-cell change.

Before you start, you will need: an account that can reach the Product Builder. The product here is cloned from a library template, so no existing motor product is needed.

There is a video version if you would rather watch it. The written steps below are the ones worth having open while you build your own.

Part One: The Product the Rating Hangs On

Step 1 - Start the Product

The new product screen offering three routes: pick from the global library, clone an existing product, or build from scratch — Three ways into a new product. The library is quickest when something close already exists.

The global library filtered to motor, with the private motor template selected and imported — Filter to motor, take the private motor template, and the vehicle and driver structure and the motor covers arrive already defined.

Step 2 - Fork the Structure Before You Change It

The structure step with the risk type being given a new code, forking a private copy of the shared definition — Product risk types point at a shared definition, so giving it a new code forks your own copy - nothing here touches another motor product.

This is the step to get right before you touch anything else. Risk types point at a shared definition, and re-coding it forks a private copy. Skip it and the attributes you are about to add turn up on every other product using that definition.

Step 3 - Add the Attributes Rating Needs

The attribute list with fuel type, usage type, first registered and main driver date of birth added, each ticked as used in rating — Four attributes the template did not carry - fuel type, usage, first registered, driver's date of birth - each flagged *used in rating*, which is what makes it available to a table.

The used in rating flag is the one that matters. It is what makes an attribute selectable as a table dimension later. An attribute you forget to flag is invisible to the rating engine, and the symptom is a dimension dropdown that does not list the field you are sure you added.

Step 4 - The Quote Form Builds Itself

The quote form generated from the definition, with the four new attributes already rendered as dropdowns and date pickers — Save, and the form builds itself from the definition - dropdowns and date pickers in place, and the same form the rating engine will test against.

Part Two: The Rating Engine

Step 5 - Four Steps Make a Rating Engine

The rating tab showing its four numbered steps: rating tables, calculation formula, taxes and fees, and a test calculation — The whole engine in four steps: the tables that hold the rates, the calculation that combines them, the charges on top, and a panel to test it.

Counter-intuitively, start at step two.

Step 6 - Derive What You Do Not Store

Two derived fields defined as age in years of a date the record already carries - driver age and vehicle age — Neither age is stored anywhere. Derive them - *age in years of* a date the risk already carries - and the tables can band on them. No code.

Two of the things you want to price on, how old the driver is and how old the car is, are not stored anywhere, and should not be: an age recorded today is wrong next year. Derive them from the dates the record does carry, and the tables can band on them. Note the rounding is age last birthday, which is what a motor underwriter means by age.

Step 7 - The Base Premium Table

A base premium table in absolute amounts with two dimensions: fuel type matched exactly and engine size matched as a band — A base premium in absolute amounts, with two dimensions - fuel type matched exactly, engine size matched as a band. That gives you a grid.

Two dimensions and two match types. Fuel type is a list, so it matches exactly; engine size is a number, so it matches as a band. Between them they make a grid with one cell per combination.

The filled grid: one row per fuel type and engine band, with the rate for each combination — One row per combination. Note the bands step rather than overlap - one ends at 1599, the next starts at 1600, so nothing falls between them and nothing is counted twice.

Check the band boundaries as carefully as the rates. A band ending at 1600 and the next starting at 1600 is a double match; ending at 1599 and starting at 1600 is a clean step. This is the defect class that prices a whole book wrong while looking perfectly reasonable on screen.

Step 8 - Three Factor Tables

The base is an amount; everything after it is a multiplier.

The driver age factor table: a multiplier banded on driver age, loading the youngest band and the oldest — A multiplier rather than a base rate, banded on the driver age we derived: the classic motor shape, with a loading at each end and the standard rate in between.

First match wins, so the order of the rows is the order they are tested in. Worth knowing before you write bands that could overlap.

The vehicle age factor table, banded on the derived vehicle age, with a discount for new cars and a loading for old ones — Same pattern on the car: a discount up to three years old, the baseline to ten, and a loading beyond - older cars are dearer to repair.

Keep a baseline of exactly 1.00 in every factor table. It is what makes the others readable as “ten percent more than standard” rather than as numbers that have to be compared with each other.

The usage type factor table matched exactly rather than banded, with a row per usage value — Usage is an exact match rather than a range, because it is a list of values: social is the baseline, commuting, business and commercial each load it further.

Step 9 - Combine Them

The calculation pipeline - start with the base table, then multiply by each factor table in turn - with the generated formula and a plain-English readback beneath it — Start with the base table, multiply by each factor in turn. The formula is written underneath as you go, and read back in plain English - so what you built is what you meant.

The plain-English readback is the part to actually read. “Start with BASE_FUEL_CC, multiply by DRIVER_AGE, multiply by VEHICLE_AGE, multiply by USAGE_TYPE” is four lines anyone in the pricing meeting can check, and it is generated from the pipeline rather than written by hand, so it cannot drift from what will run.

Step 10 - Charges Sit Outside the Premium

The taxes and fees step with a flat policy fee and insurance premium tax charged on premium plus fees — A flat policy fee and premium tax at 12%, charged on premium plus fees - outside the premium formula, so neither is ever charged twice.

Keeping fees and tax out of the premium formula is not tidiness, it is correctness. A formula that has swallowed the fee applies every later factor to it, and a tax based on “premium plus fees” cannot be computed at all until both exist. Note the basis column, of premium + fees, which is the field people most often get wrong.

Part Three: Pricing, and Repricing

Step 11 - Price a Real Risk

The test panel asking only for the fields the calculation uses: engine size, fuel type, usage, first registered and the driver's date of birth — The test panel asks only for the fields the calculation actually uses - here a 1.9 diesel used for commuting, registered in 2019, driver aged twenty.

Do the arithmetic by hand once, on the first risk you price. A 1,900cc diesel lands in the 1600+ diesel cell at 510. The driver is twenty, so the 17–20 band gives 1.55. The car is seven years old, so the 4–10 band gives 1.00. Commuting gives 1.10.

The priced result: premium, fees, taxes and total, with a breakdown row per scope and charge — 510 base for the diesel, ×1.55 for the young driver, +10% for commuting - 869.55, then the fee and the tax, and the customer pays 1,013.10.

That is 510 × 1.55 × 1.00 × 1.10 = 869.55. Add the 35 fee, take 12% of 904.55 = 108.55, and the total is 1,013.10, exactly what the panel shows.

If your hand calculation and the engine disagree, you have found either a band boundary or a factor applied in the wrong place, and you have found it before a customer did.

Step 12 - Reprice Before You Commit

The driver age table with the youngest band's multiplier being changed from 1.55 to 2.3 — Suppose the young-driver book is running hot. Open the driver age table and change one cell: 1.55 becomes 2.30.

This is the step that changes how pricing work feels. The test panel rates against the configuration on screen, including unsaved edits, so a rate change can be priced on real risks before anyone commits to it. Change the cell, re-rate, look at the number, and decide. Nothing is persisted until you save the rating engine.

The identical risk rated again, showing a higher premium and total — The identical risk, re-rated: 1,290.30 premium, 1,484.34 all in - nearly 500 more from a single number, and none of it saved yet.

Build yourself two or three named test cases that represent the book, a young driver, a standard risk, an older car on business use, and re-run all of them after any rate change. A factor that looks sensible on the risk you happen to be thinking about is how books get mispriced at the edges.

Everything above is four grids, a list of multiplications, two charges and a test panel. No code, and nothing an actuary or an underwriter would need translated, which is the point. The reason pricing changes are slow in most insurers is not that the arithmetic is hard. It is that the rates live somewhere the people responsible for them cannot see or safely touch.

When the rates are tables, the calculation reads back in English, and a rate change can be priced against a real risk before it is saved, repricing stops being a project. It becomes what it should be: someone who knows the book changes a number, checks what it does, and commits.