How it works
How ISO commercial insurance rating works
A commercial submission is a description of a business. A premium is a number that has to survive an audit, a broker asking why it moved, and a re-rate three years later. This page explains the path between the two: where licensed bureau content sits, what the carrier adds on top, the order the calculation runs in, and why the effective date governs all of it.
Three layers: what is licensed, what is the carrier's, what is the program's
Bureau content is licensed, not owned. A rating platform holds rules, rates and loss costs under license and maintains them against circulars as they issue. The platform's job with it is narrow: keep it current, make it resolvable for a particular risk, and record which piece of it governed.
What varies between companies sits above it. SelectRate describes the shape as three layers.
| Layer | What it holds | Whose it is |
|---|---|---|
| ISO rating base | The licensed rules, rates and loss costs, maintained against circulars as they issue | SelectRate maintains it |
| Carrier configuration | Carrier-approved deviations from that base, including company multipliers, by state | The carrier's |
| Program configuration | Pricing and rules specific to a single program | The program's |
The separation is not cosmetic. It lets the bottom layer move without disturbing the two above it: when a circular issues, the base layer moves underneath and the configuration stays intact. Collapse the three into one set of tables and every bureau update becomes a re-implementation of the carrier's own position, which is where most rating maintenance cost comes from.
It also makes a rate explainable: when two carriers produce different premiums from identical bureau content, the difference lives in layers two and three and can be pointed at. SelectRate is a licensed user of ISO content, not the bureau.
The shape of the calculation
There is no single formula. There is an ordered sequence of steps, each with its own inputs and its own source, and the order matters as much as the arithmetic. A factor applied at the wrong point produces a number that looks plausible and is wrong.
| Step | What happens | Where it comes from |
|---|---|---|
| Exposure base | The measure being charged for is identified: a sales figure, a payroll figure, a count of units, a schedule of values. Which applies to which class is set by filed content | Bureau content, applied to the submission |
| Loss cost | A cost per unit of exposure is resolved for that class, in that place, on that date | Bureau content |
| Company multiplier | The carrier's approved multiplier converts a bureau loss cost into that company's rate | Carrier configuration |
| Limit factors | Factors reflecting the limits chosen adjust the rate, because a higher limit is not the same product as a basic limit | Bureau content, driven by the limits requested |
| Applied to exposure | The adjusted rate meets the exposure, producing a premium for that rating unit | The engine |
| Aggregation | Rating units are summed: several locations, classes or coverage parts mean several units | The engine |
| Minimums | The calculated premium is tested against the minimums that apply, including a policy writing minimum | Bureau content and program configuration |
| Program rules | Fees, eligibility outcomes and program rules resolve last | Program configuration |
Two things worth pulling out. Minimums are a test, not a multiplier: the calculated premium is produced first, then compared against what the risk is allowed to be written for, which is why a record can show a calculated premium and a different final premium. And limit factors are not a carrier load: they come from the same filed content as the loss cost and change when the insured changes what they are buying.
A worksheet is that sequence written down as executed. On general liability, SelectRate's own worksheet shows the rating units as rows, such as Premises/Operations and Products/Completed Operations, with loss cost, company multiplier, increased limit factor, adjusted rate and premium as columns, then the premium determination steps beneath: calculated premium, minimum determination and policy writing minimum, each carrying the rule reference that governed it.
We publish the shape of that worksheet, never the values in it. Those are licensed filed content and belong to the bureau.
Supplied inputs and derived inputs
Not everything a rate depends on comes from the submission. Some values are supplied by whoever sends the risk. Others are resolved by the system from filed content, and those cause arguments when they are not recorded.
Territory is the example. On general liability a caller supplies a zip code, or a city and county. Territory is derived from the filed mapping and reported in the worksheet provenance. You do not send a territory.
That is deliberate. If callers supply territory, the rate depends on an assumption made outside the rating system by whoever keyed the submission, possibly from a mapping a year out of date, and nobody can prove later what it was. When the system derives it, the derivation is part of the record: which filed mapping was selected, why it governed, and the document and page it came from.
The principle: anything the system resolves rather than receives should say so, and say what it resolved from.
Effective dates are the spine
Everything above changes over time. Bureau editions change, carrier positions change, program rules change. A policy does not care, because it has to be rated on what was in force on its own date. That single requirement shapes the architecture of every serious rating system.
It means configuration is versioned rather than edited. Creating a change never disturbs what is live. A change is published on an effective date and is live from that date in Underwriter Workbench and on the Rating API at once, not at the moment somebody saved it.
It means prior versions stay callable. A quote written three years ago re-rates on the version and edition it was written under, not on today's content. Rating runs are immutable executions and old runs stay retrievable and byte-identical, so the artifact in the file is the original rather than a reconstruction.
And it means the date is the input, not the version. In SelectRate's Rating API the effective date is the only temporal input accepted, there are no version identifiers in the public contract, and a caller cannot pin a version. That looks like a restriction and is the opposite. A date is a fact about the policy. A version is an implementation detail. Let callers pin versions and sooner or later something is rated on content that was not in force, with nothing in the record to show it.
A rating run resolves the version in force for the policy’s effective date. There is no version to pin and no way to rate on one that was not in force.
When rating cannot produce a number
Sometimes the honest output is no premium. The program is not effective for the quote date. The risk needs referral. The class is not eligible. Configuration for that state is unfinished. Each is a different answer and none is a rate.
A rating system should fail closed. A program that is not effective for the quote date returns no number and says why. Quietly rating on the nearest available version is worse in every way that matters: a plausible premium from the wrong content gets bound, sits on the book, and surfaces in an audit rather than in a quote.
This is why outcomes get their own vocabulary. SelectRate's results distinguish a rated premium, a referral, a decline and a result with no premium, and each carries the engine's own reason, because insurance outcomes are not a fixed list. It is also why transport and outcome are kept apart: HTTP status describes the API call, result status describes the insurance outcome, so a decline is a successful call rather than an error.
"No premium and a reason" is not a degraded answer. It is the correct one, and usually more useful to the underwriter than a number would have been.
A rating system that produces a number it cannot support is worse than one that says it cannot produce one.
Where the result goes next
Rating is a step in a chain, not the chain. Once a premium exists, judgment can be applied on top of it. The indicated premium is the engine's number. Debit and credit sit above it, and the engine's indicated premium and the final premium are reported separately on every result, so judgment applied on top of the rate is always distinguishable from the rate, so the file shows where the rate ended and discretion began. An underwriter changing a price is normal. Changing it invisibly is not.
Then the result moves on. A rating platform rates and records; a policy administration system owns the customer record, billing and documents. SelectRate publishes where it sits: it records the bind and rates every later transaction on the term, and leaves billing, invoicing, commissions, documents and accounting to your systems.
The two have different jobs. Rating has to be reproducible, versioned and explainable. Policy administration has to be current and authoritative about who is insured today. Settle that boundary before designing an integration across it.
Questions people ask once they have read this far
Is a loss cost the same as a rate?
No, and the distinction is why the carrier layer exists. A loss cost is the expected loss component per unit of exposure and comes from bureau content. A rate is what a company charges after its own approved multiplier and deviations. Two carriers starting from identical bureau content will not charge the same price, and both can be right.
Does the rating platform decide whether to write the risk?
No. It resolves the rules that were configured and reports the outcome, including referral or decline. Appetite and authority are decisions the carrier and the program make, expressed as configuration. The platform applies them consistently and shows its working.
See it on a real line
The clearest way to understand this sequence is to watch it run on one class in one state. Bring a program you already write and we will configure it live with you on the call.