Insurance Rating Software: How a Carrier Rating Engine Works and How to Choose One

Insurance rating software calculates the premium for a policy from a carrier's filed rates and rules. A rating engine takes the risk's characteristics, such as class, territory, limits, deductibles, and exposure, looks up base rates and factors, applies them in the order the rating algorithm specifies, and returns a premium the carrier can defend to a regulator. Two different products share the name. Agencies use comparative raters to compare quotes from many carriers at once. Carriers and managing general agents (MGAs) use a rating engine inside or beside the policy administration system to produce the price itself. This guide covers the carrier rating engine: what it does, how state filings and bureau content constrain it, and how to choose or build one.
What does a rating engine do?
A rating engine executes a carrier's rating manual. The manual, filed with each state, defines the base rates, the factor tables (territory, class, construction, protection class, driver age, and dozens more), the rules that decide which factors apply, and the algorithm: the order in which factors multiply or add, where minimum premiums apply, and how results round. The engine turns all of that into configuration or code and runs it every time the policy system asks for a price, at quote, at bind, at each endorsement, and at renewal.
Three properties matter more than raw speed. The engine must be exact, because a one-cent difference between the engine and the filed manual is a rate the state never accepted. It must be versioned, because a commercial policy written in March and endorsed in September may need March's rates for the original coverage and September's for the change, depending on the carrier's filed rules. And it must explain itself: every premium should come with a rating worksheet that shows each factor and step, so an underwriter, an auditor, or a market conduct examiner can reproduce the number from the manual.
Comparative raters vs carrier rating engines
The search results for rating software mix two markets, and a buyer should know which one they are in before reading vendor pages.
| Question | Comparative rater | Carrier rating engine |
|---|---|---|
| Who uses it | Independent agencies | Carriers and MGAs |
| What it does | Sends one set of risk details to many carriers and lines up the quotes | Calculates the carrier's own premium from its filed rates and rules |
| Where the rates come from | Carrier rates loaded by the vendor or returned through carrier connections | The carrier's filed rating manual or the bureau content it adopted |
| Examples | EZLynx, TurboRater, Applied Epic Quotes | Rating modules in core suites, standalone engines such as Earnix, and custom engines |
| What failure costs | A lost quote | Premium charged at a rate that was never filed |
The rest of this guide is for the carrier or MGA that has to produce the price, where the stakes are regulatory as well as commercial.
How do state rate filings shape a rating engine?
In the United States, rates are regulated state by state, and the filing law decides how fast a rating change can reach production. The NAIC's 2024 Product Filing Review Handbook describes the main types. Under prior approval, "rates must be filed with and approved by the state insurance department before they can be used." Under file and use, rates can enter the market at the same time they are filed. Under use and file, they can be used first and filed by a later deadline. Under flex rating, prior approval applies only when a change exceeds a set band. Across all of them, the handbook gives the same standard: rates "shall not be excessive, inadequate or unfairly discriminatory." Filings move through SERFF, the NAIC's electronic system for rate and form filings.
That framework puts four demands on rating software. Rates and rules have to live as data, versioned by state, line, program, and effective date, so a filed change is loaded and tested instead of recoded. New business and renewal effective dates often differ, so the engine needs both. The engine has to reproduce the filed manual exactly, which means a regression test suite built from the filed rate pages and run before every release. And the actuaries who write the filing should be able to read what the engine runs, because the filing and the engine describe the same algorithm and a mismatch between them is a compliance finding.
Bureau content and the circular problem
Many commercial lines start from bureau content. Verisk's ISO publishes loss costs, rules, and forms that carriers adopt and then adjust with their own multipliers and deviations, and NCCI plays a similar role in workers' compensation in the states it serves. Verisk describes ISO Electronic Rating Content (ERC) as the exact digital form of the ISO Commercial Lines Manual, licensed to technology vendors for use in their rating engines, and says it issues "hundreds of rating-related circulars a year." A vendor that consumes ERC receives each rule update automatically. A vendor that does not must analyze and interpret each change, then update and test its engine by hand.
For a carrier writing ISO-based commercial lines, bureau content support is the first filter in a rating decision: how quickly circulars reach production, who tests them, and how the carrier's own deviations are kept separate from the bureau base so the next circular does not overwrite them. For specialty or non-bureau products the question flips. The engine has to make the carrier's own rating model easy to change, test, and file without a vendor change request in the middle.
What happens to the engine when a rate change is filed?
A rate change follows the same path every time, and the rating software should make each step routine. The actuary prepares the change and the filing, the filing goes to each state through SERFF, and the state approves or acknowledges it under its filing law. The new rate version then loads into the engine with its effective dates for new business and renewals. Two tests follow before anything reaches production. The first compares the engine's output with the filed rate pages, factor by factor. The second rerates a copy of the in-force book on the new version and checks that the overall premium change matches the change the carrier filed; a filed increase of 6 percent that rerates to 8 percent means a table or rule loaded wrong. Only then does the version deploy, ahead of its effective date, and renewals pick it up on their own dates. An engine that needs a developer for any of these steps turns each filing into a small software project.
What should you require from insurance rating software?
These are the requirements we score first when a carrier or MGA evaluates rating software or decides to build an engine:
- Rates, factors, and rules held as versioned data with effective dates by state, line, program, and new or renewal business.
- A rating worksheet with every premium that shows each step of the algorithm and each factor applied.
- A regression test harness that compares engine output with the filed rate pages before each release.
- Bureau content support for ISO ERC and NCCI, with a stated lead time from circular to production, if you write bureau lines.
- An API that the policy system, portals, and comparative raters can call, with response times measured at quote volume.
- A way for actuaries to read and test the rating logic without writing code or waiting for a developer.
Speed belongs on the list once these are met. A personal auto quote requested through a comparative rater has to return while the agent waits on the screen, and a commercial auto policy with hundreds of vehicles needs a full rerate on every endorsement. Measure both with your own rating manual, because vendor benchmarks run on their own content.
Use the suite's engine, buy a standalone engine, or build one?
Carriers on a core suite usually rate inside it, because the policy system and the rating engine share a product model and a release cycle. A standalone engine makes sense when several policy systems or channels have to share one price; our policy administration system guide describes that pattern, with rating kept outside the policy system so several systems can call it. Building an engine makes sense when the pricing itself is the product: a specialty line with no bureau content, usage-based or parametric pricing, or a model from the data science team that has to run in production exactly as filed. Pricing analytics tools answer a different question, which rate to file and which risks to target, and the rating engine still has to execute whatever the regulator accepted.
The build case is stronger than it was a decade ago. A rating engine is a well-understood piece of software: a store for tables and rules, an algorithm runner, a versioning model, and a test harness. The hard part is the content, and the content belongs to the carrier whichever path it takes. Before you commit to either path, cost both on the same five-year horizon; our build vs buy software advisory uses a model built for that comparison. We build rating engines as part of a custom core or as a standalone service, and we offer a working prototype that rates one of the client's products before the client commits.
To scope a rating engine build or replacement, see our insurance core platform page, where rating sits on one data model with policy, billing, and product configuration.



