Rate tables that live in the platform, not in a workbook
An insurance rating engine where each product carries its own rate table as configuration rather than code — changed without a release, versioned so a quote written months ago is still explainable, and regression-tested so a rate change cannot quietly move the price on something else.
Rating ends up in Excel because changing it in the core system is slower than the business moves
Almost every specialty operation has the same arrangement. There is a core system that officially holds rating, and there is a spreadsheet that actually holds rating. The spreadsheet exists because a rate change in the core system means a change request, a quote, a development cycle and a release window — and the market moved three weeks ago.
So the workbook wins. It is faster, the underwriter controls it, and it produces the right number. What it does not produce is any record of why that number was right. When a carrier audits the book, or a broker disputes a renewal price, or the person who maintained the workbook leaves, the rating basis is whatever the file says today — not what it said when the quote was written.
The fix is not a better spreadsheet. It is a rating engine fast enough that nobody needs one.
Bring us your rating basis
Send the workbook. In a working session we configure it as a rate table, price a real submission against it, then change a rate and show you what the regression check catches.
Four properties that decide whether a rating engine gets used
Not features so much as conditions. Miss any one of them and the operation goes back to the spreadsheet, whatever the platform can technically do.
Each product carries its own rate structure
Rate tables are held per product rather than as one shared model every product has to fit. A programme whose rating looks nothing like the rest of your book is a configuration exercise, not a reason to be told the platform is not a fit. The sellable set of products is your configuration too — it is deliberately not a fixed list you have to map onto.
Changing a rate is configuration
No code, no release, no migration, no deployment window. This is the property that decides whether rating stays in the platform, because a change process slower than the market guarantees a shadow spreadsheet.
Rates are versioned
A change does not rewrite the basis of quotes already written. What a given quote was priced on remains recoverable afterwards, which is what makes an underwriting file defensible when a carrier audits it or a broker disputes a renewal.
Changes are regression-tested
Rating runs against captured baselines, so a change intended for one product that moves the price on an unrelated one is caught before production rather than found in a renewal three months later. In a configurable system, changes reach production faster than releases do — which is exactly why they need a safety net.
Rating is one stage, not a standalone tool
A rate table only earns its place if the price it produces goes somewhere. On Regure the same record carries on through the quote and into the policy.
Before: the submission
The data being rated comes off the submission itself — extracted with a confidence score per field and reviewed before anything is created — rather than being typed into a pricing sheet. See document processing.
During: the quote
The calculated premium sits on a quote record with its product, period, currency and broker, and every revision is its own record. See the quote-to-bind path.
After: the policy
An accepted quote converts into a policy and runs its lifecycle — endorsements, renewals, invoicing, commissions — without the premium being re-entered. See policy administration.
Where a rating engine is staying in place as the pricing authority, Regure works with the premium that system produces and runs the operational path around it. Which model applies is a deployment decision — see the two deployment models.
Configured as part of implementation, changed without a release
Rating logic and product rate tables are configured without changing application code, and that configuration is managed as part of the Regure implementation and operating process.
Changes move at the speed of the business
A rate change is a configuration change: no development cycle, no release, no migration and no deployment window. That is what keeps pricing inside the platform instead of drifting into a workbook the moment the market moves.
Set up with you, not handed over cold
Our implementation team configures your rate tables with you and stays with the operating process afterwards, so a rate change is a request that gets actioned rather than a project that gets scheduled.
For the full picture of what is held as configuration across the platform, see configuration. For the underlying concept, see the insurance rating engine glossary entry.
What buyers ask about rating
What is an insurance rating engine?
The component that turns risk information into a premium by applying rates, factors and rules to the data on a submission. In practice the question that matters is not whether a platform has one, but how quickly a rate can be changed in it — because a rating engine slower than the market produces a shadow spreadsheet, and then the platform is no longer the system of record for pricing.
How long does a rate change take on Regure?
It is configuration rather than code, so there is no release, no migration and no deployment window. Rate tables are versioned so the change does not rewrite the basis of quotes already written, and rating runs against captured baselines so a change that moves an unrelated product is caught before production. Rate tables are configured as part of the Regure implementation and operating process.
How are rate table changes managed?
Rating logic and product rate tables are configured without changing application code, and that configuration is managed as part of the Regure implementation and operating process. Our team configures your rate tables with you and stays with the operating process afterwards, so a rate change is a request that gets actioned rather than a development project that gets scheduled.
What happens to quotes already written when we change a rate?
Nothing. Rate tables are versioned, so a quote remains explainable against the rates that were in force when it was priced. That is what makes the underwriting file defensible when a carrier audits the book or a broker disputes a renewal price.
Can Regure work with a rating engine we already have?
Yes. Where an existing rating engine stays as the pricing authority, Regure works with the premium it produces and runs the operational path around it — submission intake, quote versioning, documents, conversion to policy and the lifecycle after. Where there is no rating system worth preserving, or the real one is a spreadsheet, Regure holds the rate tables itself.
Does it handle multiple currencies?
Yes. Quotes and policies carry their own currency, and the reinsurance side of the platform holds explicit FX rates with the rate applied recorded on the document. For premium in a currency other than the one an agreement settles in, the converted figure and the rate used are both shown rather than silently applied.
Bring us your rating basis
Send the workbook that actually prices your business. We will configure it as a rate table, price a real submission against it, and show you what happens when a rate changes.