Insurance Rating Engine

Skip key takeaways

Updated September 24, 2026

• A rate change applied outside its own effective date breaks the filed rate manual Under prior approval a rate cannot be used before approval; under file-and-use no approval is required before use, but the department retains the right to disapprove afterward. Either way, a rate version that applies before its own effective date, or continues to apply to a new-business or renewal term the filing has moved to a later version, is a compliance failure, not just a data bug.
• A rating engine's core components each need their own versioning rule Rate tables, factors and the algorithm's order, caps and minimum premium all drift independently unless each ships as part of a dated version and none is edited in place.
• The CAS reference test for actuarially sound The CAS Statement of Principles, reinstated for reference rather than as a current binding standard, defines soundness as an estimate built on Principles 1 through 3, and Principle 4 ties that soundness test back to the same excessive, inadequate and unfairly discriminatory standard state rating laws already set.
• Change management exists to protect parity with the filed rate manual A second approver's sign-off is not enough on its own; the activating version still has to pass a parity run against the filed manual, or a factor table that quietly drifted from what was filed can reach production unnoticed.
• A rating trace per premium is what makes a referral or a regulator's question answerable Without a per-decision record of which factor, table version and third-party data value produced a premium, an underwriting referral or a regulatory inquiry has nothing concrete to point to.

Copy takeaways

In short: the core-components table below names the seven pieces a rating engine is built from. Effective-dated versioning has to select a rate table by the current policy term's effective date, new business or renewal, and the filing's stated date rule, never by the date the calculation runs, or a filed rate change reaches policies that were never supposed to see it. And a rating trace per premium has to exist before the first underwriting referral or regulatory inquiry asks which rule produced a specific number.

An insurance rating engine takes a rating plan and a set of applicant facts and returns a premium. Most of the actual difficulty sits downstream of that description, in the gap between what a state rating law regulates and what the codebase executes at 2 a.m. when a renewal batch runs. The regulatory frame here is US state rate filing. Outside the US the filing regime differs, though the seven components below apply wherever a rate has to be versioned, filed and made auditable. This guide treats a rate manual as a layered composite rather than a single document, an inference drawn from the NAIC's own 2024 Product Filing Review Handbook rather than a claim the handbook makes itself: "For example, minimum premiums are not established by the advisory organization, and, thus, the company should create rate manual pages that list the minimum premiums that will be charged." A rating engine has to make that whole stack, bureau-supplied figures plus the carrier's own pages layered on top, queryable at run time rather than read off a page.

Core Components of a Rating Engine

The filing regime and the actuarial standard covered later describe what a rate has to be. They say nothing about how a piece of software should be built to produce one, and no source here claims otherwise. The table below is Pharos Production's own account of the components a rating engine needs to satisfy those constraints, the baseline our insurance software development services practice builds against rather than a requirement stated by NAIC or CAS.

Component	What it stores or does	Versioning rule	Failure mode seen in practice
Rate table	Base rates and loss costs per coverage, territory and class, filed with or accepted by the regulator	Effective-dated, selected by policy effective date, never edited in place	A table is edited in place to fix an error, silently repricing every open quote and endorsement that reads it
Rating factor	A multiplier or additive adjustment tied to one classification variable, such as territory, vehicle type or building construction type	Ships as part of an effective-dated release. A factor-only filing revising a single variable still needs its own dated version	A factor is corrected outside any dated release, and engine output stops matching the filed manual for every policy that used it
Rating algorithm	The ordered sequence that applies base rate, factors, discounts, caps and a minimum-premium floor, then rounds, to produce a premium	The calculation order, caps and minimum premium are versioned together. Changing any of them can need a filed rule-page change, not just a code change	A rounding-order or minimum-premium change ships as a routine deploy with no matching rule filing, and premiums stop matching what was filed
Effective-dated version selector	The logic that picks which rate table, factor set and algorithm version apply to a given transaction	Selects by the current policy term's effective date, new business or renewal, and the filing's stated date rule. An endorsement, cancellation or reinstatement reuses that term's version rather than selecting its own, and selection is never by the date the calculation runs	A rate change effective next month is applied to a policy already in force, repricing coverage the policyholder never agreed to
Rating trace	A stored per-premium record of every factor value, table version, third-party data value and intermediate amount used	Written once at calculation time, never recalculated after the fact	An underwriting referral or a regulatory inquiry has nothing concrete to point to for how a specific premium was produced
Parity and regression test suite	A comparison of engine output against the filed rate manual across a fixed set of test policies	Re-run against every new effective-dated version before it goes live, not only at initial build	The engine and the filed manual drift apart silently across several releases until a routine audit surfaces the gap
Change management record	The approval trail from an actuarial model change to a production release	A new version cannot activate without a recorded approval distinct from the person who prepared it	One person edits and activates a factor table with no second reviewer, and an error reaches production unchecked

Not every row has to be custom-built. A policy administration or rating platform can supply rate-table storage, the version selector, the trace log and even the algorithm's calculation order as configuration, and some platforms ship bureau content as a starting point. What stays carrier work on any platform is the carrier-specific configuration itself, the exact factors, caps and rules a particular carrier has filed, plus the independent parity check against that carrier's own filed manual, because no vendor's pre-built configuration can be assumed correct for one carrier's filings without checking it.

Rate Filing Vocabulary: Prior Approval, File-and-Use and What SERFF Does

Two regulatory regimes cover much of what a rating engine has to support, and the Product Filing Review Handbook defines the stricter one first: "Prior approval rating laws are when rates must be filed with and approved by the state insurance department before they can be used." Nothing built against a prior-approval line goes live until a regulator has approved or deemed approved the exact rate table it is about to compute against. The looser regime moves faster but keeps a hook: "File and use rating laws are those when the rates can be introduced into the market at the same time as they are being filed with the insurance regulator." That speed is not unconditional: "Specific approval is not required, but the department retains the right of subsequent disapproval." What follows a disapproval varies by state: a state may order the carrier to stop using the rate, revert to the prior filed rates or issue refunds. Rolling a rate table back to its prior version is the engine's own mechanism for carrying out whichever of those a state orders, restoring the prior version and re-rating affected policies against it when a refund is ordered. Other regimes exist too, including use-and-file, flex rating and no-file or open-competition filing, and a carrier operating across several of them at once needs the engine to carry that distinction per state and per line.

Both regimes run through the same filing transport. NAIC's own SERFF program page describes the system as the most cost-effective and efficient way for insurers to submit rate and form filings to state regulators and other jurisdictions. The same page states that SERFF Filing Access gives consumers and other stakeholders convenient online access to whichever rate and form filings, plus health plan binder information, a given state makes publicly available. Public availability through that access varies by state, and parts of a filing can be confidential. A rating engine's parity test should therefore not assume the filed manual is pullable from SERFF at will. The authoritative reference stays the carrier's own filed copy, kept alongside the effective-dated version it corresponds to.

Filings are not one-time events either, per the same handbook: "Rate filings are generally made by insurers on a regular basis in response to updated loss experience, as discussed in later chapters." A rating engine that assumes one current rate table per line, rather than a queryable sequence of effective-dated tables, is built for a filing cadence that does not exist anywhere in this regulatory system. Advisory organizations, the rating bureaus this vocabulary refers to, file loss costs rather than full base rates, and the bureau layer only enters an engine's data model when a carrier adopts those loss costs into its own filed rates. A carrier filing its own base rates independently has no bureau loss-cost layer to model, though it may still adopt bureau rules or classifications. A bureau's loss-cost revision reaches the engine two ways. Where a carrier has an independently filed loss-cost multiplier and the state allows adoption by reference, a bureau revision takes effect on its own, without a new carrier filing: the engine loads the revised loss costs multiplied by the carrier's own filed multiplier, dated by the adoption rule the reference filing set. Otherwise the carrier reviews the revision, adopts it wholesale or with a deviation and files the result under its own regime, and the engine loads that carrier filing as the new effective-dated version.

What Counts as Excessive, Inadequate or Unfairly Discriminatory

The standard a rate has to meet comes from state rating laws, and the Product Filing Review Handbook states it plainly: "Typical rate standards included in the state rating laws require that rates shall not be excessive, inadequate or unfairly discriminatory." The first two terms are financial. "Excessive means the rates are too high, or that the rates would exceed the amount that is needed for a company to achieve an acceptable level of profit." Its opposite carries a solvency concern rather than a fairness one: "Inadequate means the rates are too low or that a company could not sustain the rates for a long period of time without threatening solvency." Both are judgments made in the filing itself, against the insurer's own projected loss ratio and expenses. A rating engine does not re-derive them. It charges exactly what its filed rates, or in a no-file state its documented rates, produce, within any filed discretion range. Meeting all three standards at once is the harder problem, and the handbook admits it directly: "Rates that are adequate but not excessive or unfairly discriminatory are often difficult to determine and subject to contention."

These three terms are not decorative. They are the operative test a regulator applies to every filing, per the same handbook: "Rate standards are included in the state rating laws and are the foundation for the acceptance, denial, or adjustment to rate filings." The handbook draws a sharper line around the third term: charging different people different prices is not, by itself, unfair discrimination under state rating laws. "A rule of thumb is that prices are not unfairly discriminatory when consumers are charged different amounts that are actuarially justified (or justified based on risk/cost)." Actuarial justification is necessary for a rating factor to be defensible, but it is not sufficient by itself. State law bars some rating variables outright, such as race or religion, and restricts others, such as gender, credit-based insurance scores, education or occupation. Which variables are permitted varies by state and line of business. The rule of thumb above describes the actuarial test a permitted factor still has to pass, not a license to use any factor that happens to correlate with loss.

A classification rating factor earns its place through the classification plan the CAS Statement of Principles describes: "A properly defined classification plan enables the development of actuarially sound rates." A classification variable without a place in that plan is harder for the standard above to call actuarially justified, whatever its predictive value turns out to be. Individual risk rating, the umbrella term for experience, schedule and retrospective rating, adjusts one insured's own premium rather than assigning it to a class. It is a separate mechanism with its own actuarial basis and is not judged against the classification plan the same way.

"Actuarially sound" is not a vague phrase either. The Casualty Actuarial Society's Statement of Principles Regarding Property and Casualty Insurance Ratemaking was adopted by the CAS Board in 1988, rescinded in December 2020 and reinstated in May 2021 for reference for U.S.-regulated ratemaking. It states three principles that define a sound estimate: "Principle 1: A rate is an estimate of the expected value of future costs." "Principle 2: A rate provides for all costs associated with the transfer of risk." "Principle 3: A rate provides for the costs associated with an individual risk transfer." The Statement is direct about what soundness itself means: "Ratemaking produces cost estimates that are actuarially sound if the estimation is based on Principles 1, 2, and 3." A fourth principle ties that soundness test back to the regulatory standard above rather than adding a requirement of its own: "Principle 4: A rate is reasonable and not excessive, inadequate, or unfairly discriminatory if it is an actuarially sound estimate of the expected value of all future costs associated with an individual risk transfer." The handbook is not making an independent claim when it uses that same language: it names the 1988 Statement and quotes this principle's wording as the actuarial profession's own reading of the state-law standard above, not as a second, independent test. Actuarial soundness is necessary but not sufficient on its own, since state law separately bars some rating variables outright, whatever their actuarial justification.

Effective-Dated Rate Versions: New Business Against Renewal

Ratemaking is not a snapshot exercise, and the CAS's own Statement of Principles is explicit about why: "Ratemaking is prospective because the property and casualty insurance rate must be developed prior to the transfer of risk." A rate has to exist before the risk it prices is bound, which means a rating engine is always applying a rate version built for a future effective date, not the date on which the calculation happens to run. New business, renewal and mid-term endorsement are the transaction types that make this concrete, and a filed rate change states its own date rule for each: an effective-on-or-after date for new business and, separately, an effective-on-or-after date for renewals that can be later than the new-business date, so the same rate change can carry two different effective dates depending on transaction type. Some filings instead state a written-on-or-after rule for one or both transaction types. Where that applies, the engine keys on the date the transaction was written, recorded at the time it happened, never the date a batch job happens to run. A new-business policy gets whatever rate version is in force on its own new-business effective date. A renewal gets whatever version is in force on the renewal's own effective date, which can be a different, later version than the one the policy was originally priced under. A mid-term endorsement applies the version the current term was rated under, not whatever version is current on the date the endorsement is processed, because the endorsement amends a term that was already priced. An engine that selects a version by the calendar date of the calculation run, rather than by the current term's effective date and the filing's stated date rule, gets all three cases wrong in the same underlying way. A renewal batch that runs three weeks before a rate change's own effective date has to price some policies under the old version and some under the new one in the same run, depending on where each policy's renewal date falls against the filed date rule.

A quote issued under one rate version and bound after a later version has taken effect is the same problem from the sales side. How long a quote itself stays valid is usually a company underwriting rule rather than something the filing states. Absent a filing provision that says otherwise, the filed effective-date rule governs by default, so a quote whose intended effective date crosses a rate change gets re-rated at bind to the version its intended effective date selects under the filing's date rule (the written date only under a written-on-or-after rule). The exception is a filing that carries its own quote- or application-date protection clause, which the version selector has to look up and honor rather than default to the newest table. Cancellation and reinstatement follow the same logic as an endorsement: a cancellation reprices back to the version the current term was rated under, earning premium to the cancellation date under the filing's pro rata or short-rate rule, and a reinstatement after a lapse restores the policy under that same original version rather than whatever is current on the reinstatement date, unless a specific filing says otherwise for that line.

Pharos Production's own work on the Nexora Insurance Platform, a European MGA platform outside US state rate filing and operating under the EU Insurance Distribution Directive, illustrates the same principle in a narrower version. Nexora centralizes its product configuration, eligibility rules, underwriting questions, coverage terms, rating tables, taxes, commissions and policy wording alike, behind an effective-dated model: once a policy is issued, it keeps running on the configuration version that was live on its own effective date, no matter how many later versions have since shipped. The case study names that guarantee, keeping a configuration change from ever reaching back into an already-issued policy, as one of the hardest parts of the build, a fair measure of how much engineering effort the version-selector row in the table above actually costs to get right. Our Nexora Insurance Platform case study covers the full build.

The Rating Algorithm and the Rating Trace

An algorithm that applies the right factors in the wrong order is not obviously wrong. It runs cleanly and returns a plausible-looking premium, because rounding at each step compounds differently depending on where in the sequence it happens. Order is not the only thing that shifts a result: flat per-item charges, discounts applied against a subtotal rather than the base rate, premium or discount caps and a minimum-premium floor all interact with sequence, and all four commonly sit in a filed rate manual's own rule pages rather than in a rate table. Changing any of them, including a reordering that looks like a pure refactor, can be a change to what was filed, not just to how the engine computes it, and may need its own rule filing. That is why the calculation order itself has to be a versioned artifact rather than an implementation detail free to change during a refactor.

Auditability follows the same "should" the handbook itself uses, applied specifically to rating tiers, the placement logic that assigns a risk to a pricing band before the rest of the algorithm runs: "There should be a distinction between the expected losses or expenses for each tier, and the placement process should be auditable." A rating trace is one way that requirement gets satisfied in software: a stored record, written at calculation time, of every factor value, every table version and every intermediate amount that fed a specific premium, including any third-party value read at rating time, such as a credit-based score or a catastrophe-model output. Pinning the exact value used, and the model version that produced it, rather than a pointer to the service that returned it, is what keeps the trace reproducible. A filed scoring or catastrophe model carries its own version, and that version ships as part of the same dated release as the rate tables and factors it feeds. A live lookup can return a different answer tomorrow, and replaying the same policy through the same engine version months later should hit the pinned value, not a fresh call. Storing a credit-based value inside that trace is not unconstrained either: FCRA and state law govern how that specific data can be retained and disclosed, and a trace design has to account for that alongside reproducibility.

Nexora's underwriting workflow applies a related idea at a narrower scope, referral routing rather than full premium calculation. A risk that clears eligibility checks and scoring moves straight through when it falls inside the carrier's delegated authority. Anything else lands in front of an underwriter with the specific rule that flagged it shown alongside that risk's own policy and claims record. What a rating trace generalizes from this pattern, not the referral-only scope itself, is the underlying habit: a system that can point to the rule and the version behind a decision instead of only returning a result.

Parity and Regression Testing, and Change Management

None of the three sources behind this article describe software testing practice. The handbook's closest approach is its discussion of predictive modeling, raised as a regulatory concern: "The ability of computers to process massive amounts of data (referred to as “big data”) has led to the expansion of the use of predictive modeling in insurance ratemaking." A predictive model that feeds a rating factor is still a rate table with more inputs, and it still needs an effective-dated version and the same parity test as everything else in the manual.

Parity testing is what we call the practice this scale creates a need for: running a fixed set of test policies through the live engine and comparing the output, field for field, against what the filed rate manual would produce for the same inputs. Regression testing does two things against the engine's own history: it replays every existing effective-dated version through the new build and expects identical output, confirming the new build has not silently changed how an already-shipped version behaves, and it then diffs the new version's own output against its immediate predecessor's, confirming that only the changes the filing itself made actually moved between the two versions. Neither is optional at the point a new version is about to activate, because the two failure modes they catch, drift from the filed manual and drift from the engine's own prior behavior, are silent by construction. Nothing in a rating engine raises an error when its output stops matching what was filed. It returns a premium that is wrong in a way nobody has checked for yet, and the gap surfaces only when a regulator asks or an audit stumbles onto it months later.

The expected premiums a parity run checks against are not read off the engine's own history. They are computed independently from the filed rate and rule pages themselves, against a fixed set of test policies chosen to cover each rating variable and its boundary values, such as the edge of a territory band or the exact age where a factor changes. A match is exact after the rounding the filing itself documents. There is no tolerance band to invent, because a filed rate manual does not have one either.

Change management is the process wrapped around all of this. Nexora's own configuration changes go through maker-checker approval: one person prepares a version, and a second authorized person approves it before it activates. A change management process for a rating engine, as a general matter, also has to check the activating version against the filed manual itself, not only against a second reviewer's sign-off, because a person can approve a factor table that has already quietly drifted from what was filed. The parity run is what makes that check concrete, the evidence a reviewer points to before signing off.

How Pharos Production Helps

A rating engine is one component of a larger insurance software development effort, and it is usually the component with the least room for a shortcut: a mispriced policy or an unauditable premium is a filing problem, not just a bug. Our software for the insurance industry team builds effective-dated rate tables and factors, an ordered and versioned rating algorithm, a rating trace stored per premium and a parity and regression suite run against every new version, as one connected system. Our Nexora Insurance Platform case study covers the effective-dated configuration and maker-checker change control described above, and our bordereaux reporting guide covers how the premiums this engine produces get aggregated and reported to the carrier or syndicate providing capacity when an MGA or coverholder runs the engine.

Sources: National Association of Insurance Commissioners (NAIC), Product Filing Review Handbook 2024; NAIC, SERFF industry page; Casualty Actuarial Society (CAS), Statement of Principles Regarding Property and Casualty Insurance Ratemaking (adopted 1988, rescinded 2020, reinstated 2021). Read 23 September 2026. Engineering guidance, not actuarial, legal or filing advice.

FAQ

Last updated: September 24, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Does this apply outside the US?

  Copy link Copies a direct link to this answer to your clipboard.

  The regulatory vocabulary here, prior approval, file-and-use, SERFF and the excessive, inadequate or unfairly discriminatory standard, is specific to US state insurance rate regulation. Outside the US the filing regime is different and this guide does not describe it.

  The engineering components, effective-dated versioning, a rating factor tied to a classification variable, a rating trace and a parity test against whatever the filed or approved rate document actually is, generalize to most rate-regulated insurance markets, only the filing vocabulary changes.

• Which rate version governs a quote issued before a rate change and bound after it?

  Copy link Copies a direct link to this answer to your clipboard.

  By default the filed effective-date rule governs: a quote whose intended effective date crosses a rate change gets re-rated at bind to the version its intended effective date selects under the filing's date rule (the written date only under a written-on-or-after rule). How long the quote itself stays valid is usually a company underwriting rule rather than something the filing states.

  The exception is a filing that carries its own quote- or application-date protection clause; where one exists, the engine has to look it up rather than default to the newest available table.

• What happens at a mid-term endorsement, cancellation, reinstatement or renewal?

  Copy link Copies a direct link to this answer to your clipboard.

  An endorsement, cancellation and reinstatement all key on the current policy term's own version, not whatever version is current when the transaction is processed. An endorsement prices under the version the current term was rated under.

  A cancellation reprices back to that same version, earning premium to the cancellation date under the filing's pro rata or short-rate rule. A reinstatement after a lapse restores the policy under that original version too, unless the specific filing states otherwise for that line. A renewal instead keys on the new term's own version under the filing's renewal date rule. In-force premium is also recalculated at a final premium audit on auditable commercial lines and at an experience-modification or retrospective adjustment, never silently just because a new version has shipped.

• Where do the expected premiums in a parity test come from?

  Copy link Copies a direct link to this answer to your clipboard.

  They are computed independently from the filed rate and rule pages, not read off the engine's own prior output, against a fixed set of test policies chosen to sit on the boundary of each rating variable, such as the edge of a territory band. A parity run expects an exact match after the rounding the filing itself documents, with no tolerance band invented to make a near-miss pass.

• How does third-party data get handled in a rating trace?

  Copy link Copies a direct link to this answer to your clipboard.

  The trace has to store the exact value a third-party source returned at the moment of calculation, and the model version that produced it, such as a credit-based score or a catastrophe-model output, rather than a reference to the service alone. A filed scoring or catastrophe model version ships as part of the same dated release as the rate tables it feeds.

  A live lookup can return a different value tomorrow, so a trace that stores only the pointer cannot be replayed later to reproduce the original premium. Storing a credit-based value this way is also constrained by FCRA and state law, which govern how that specific data can be retained and disclosed.

• How does an advisory organization's loss-cost revision reach a rating engine?

  Copy link Copies a direct link to this answer to your clipboard.

  Two ways. Where a carrier has a filed loss-cost multiplier and the state allows adoption by reference, a bureau's revised loss costs take effect without a new carrier filing, and the engine loads the revised loss costs times the carrier's own multiplier, dated by the adoption rule.

  Otherwise the revision is a proposal the carrier reviews and may adopt, in whole or with its own deviation, and the carrier's own resulting filing, once on file under its state's regime, is what the engine loads as the new effective-dated version.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.