Lines of business
ISO businessowners rating, where eligibility decides first
Businessowners is one product carrying both property and liability components, and a gate in front of both. If the risk does not qualify, there is no premium to calculate, and the only useful answer a system can give is that it is ineligible and why. SelectRate treats that answer as a first-class result rather than an error, and keeps the pricing and rules for the package in one configured program rather than scattered across coverages.
The unit of rating is the eligible package
Monoline lines rate a thing. General liability rates a business activity. Commercial property rates a location. Commercial auto rates a vehicle. Businessowners rates a package, and the package only exists if the risk fits inside it.
That inverts the order of operations. On a monoline risk the system reaches for the rate and the rules shape it. On a BOP the system has to settle eligibility before a rate is worth calculating at all, because an ineligible risk with a beautifully derived premium is a wrong answer delivered confidently.
So the question to ask a BOP rating platform is not only "can it produce the number". It is "what does it do when there is no number".
Eligibility governs everything upstream
Eligibility on a BOP is not one field. It is a set of conditions about what the business does, how big it is, what the building is like and what the program will accept, and those conditions are the part that carriers and program managers change most often. A class that was open last quarter is closed this quarter. A square footage ceiling moves. A state comes off.
Two consequences follow, and they are the whole design problem.
First, eligibility has to be configuration, not code. If tightening a class list needs a release, the program is being run by the release calendar rather than by underwriting. In SelectRate, program rules, fees and policy writing minimums are configured in Program Studio rather than raised as a support ticket, and a change is created as a new version without disturbing what is live.
Second, eligibility has to run before pricing and has to report itself. A rule that silently suppresses a quote is worse than no rule, because nobody downstream can tell the difference between "we will not write this" and "something broke".
Ineligible is an answer, and it has to be usable
The Rating API separates two things that most integrations confuse.
HTTP status describes the API call. Result status describes the insurance outcome.
A rating request that returns nothing but declines is still a 200. The call worked. The insurance answer was no. Each program result carries its own status, including:
| Status | Meaning |
|---|---|
Rated | A premium was produced. |
Referred | Rated, but the program requires underwriter referral. |
Declined | The risk is ineligible for this program. |
The distinction between Declined and Referred is the one that matters on small commercial. A decline is an underwriting outcome about the risk. A referral is a rated result that needs an underwriter. They belong in different places in your workflow, and a platform that returns a generic failure for both forces your team to guess.
Correction and referral text is the rating engine's own wording, passed through unchanged, and it is written to be shown to an underwriter. That is deliberate. On a monoline risk an unexplained no is an annoyance. On small commercial, where an agent may be waiting on a screen and will simply go elsewhere, an unexplained no is a lost submission.
One thing to settle before you build the agent-facing message: a result carries its referrals and corrections in the engine's own words. If your portal needs to name the governing eligibility rule on a decline, put that requirement on the table in the technical session, because it shapes what the portal can display.
Pricing a package, not a coverage
A BOP is property and liability sold as one thing. That has an unglamorous but expensive consequence: a carrier that changes its pricing has to change it for the package, not for a coverage in isolation.
A package priced in pieces is a package that can be released in pieces, and the combination that reaches a bound policy may be one nobody tested together. The version boundary is where you control that. ISO rating content sits underneath as the base layer. Carrier-approved deviations sit above it, by state. Program pricing and rules sit above that. A change is authored as a version, published with an effective date, and live in Workbench and the Rating API at once.
Set one multiplier for the whole program and override the single state that differs. Author it once, test it in Program Studio before it goes anywhere, and let it take effect on its date.
Small commercial means volume, and volume changes the API
BOP is where the integration stops being a convenience and becomes the product. High submission counts, thin margins per policy, and most of the traffic arriving from systems rather than from people.
Four things in the Rating API are built for that shape.
Synchronous. One request, one answer. No callback to wait for and no queue to poll, which is what an agent-facing screen needs.
One request, every program. Leave the program code out and a single request rates every program you are entitled to for that product, state and date, each returned as an independent result. For small commercial market shopping, that is one call instead of a fan-out you have to write and maintain yourself.
Small responses. Worksheets are not inlined, because a real worksheet runs to seventy-plus steps. You get a link and fetch it when a human actually wants to read it.
Safe retries. An Idempotency-Key header is supported, and every rating run stays retrievable and byte-identical forever, so a retried submission does not become a second quote.
Products are discovered rather than hard-coded. GET /products/{productCode}/schema returns the field metadata for a product's risk payload: names, types, options, which fields are required and conditional visibility. New lines of business appear through discovery without a contract change, which matters more on BOP than anywhere else, because the eligibility fields a package needs are exactly the fields most likely to be extended.
Test the rules, not just the rates
Rate testing on a BOP is the easy half. The half that catches people is rule testing: the risks that should be declined and are not, and the risks that should be written and are being blocked.
Every change is tested in Program Studio before it can go forward: rate complete test risks against the draft version and against what is published, and read the worksheet behind each result. A version cannot be submitted for release until at least one test has rated, and the review step shows exactly what it changes against the published configuration, state by state. A published version takes effect on its effective date and never changes afterwards. Run your known-ineligible risks through the test too, and read what comes back.
Distribution to the people who actually write small commercial
One endpoint serves every rating channel you authorize, all on the version you released. Each API client has its own credential and is granted the specific programs it may rate. Scopes decide which operations a credential can call. Grants decide which programs. There is no wildcard at request time, and a client never sees another client's quotes or policies. A program a client is not entitled to returns a 403 without disclosing that it exists.
For a BOP program running through dozens of sub-producers, that last detail is the difference between a controlled appetite and an appetite everyone can read.
When a risk outgrows the package
Eligibility has an edge, and accounts cross it. A risk that no longer fits a package has to be written monoline, on commercial property where rating resolves by location, and general liability where it resolves from class, territory and increased limit factors. Vehicles go to commercial auto.
All four ISO lines run on the same configuration model, with governed bureau content underneath and your carrier and program configuration on top, so a risk that moves from a package to monoline does not move to a different system. Every organization starts each line from a governed Standard Program rather than an empty configuration screen.
Questions buyers actually ask
Can we change a class list without a release?
Program rules, fees and policy writing minimums are configured in Program Studio rather than raised as a support ticket, and a change is created as a version that does not disturb what is live until its effective date. Ask on a demo to see a program rule changed and tested in one sitting.
What does an agent see when a risk does not qualify?
A result status rather than an error, on a successful call. Correction and referral text is the engine's own wording, passed through unchanged and written to be read by an underwriter. Confirm with the team exactly which text accompanies a decline as opposed to a referral.
Can we shop one submission across several carrier programs?
Yes. Leave the program code out and one request rates every entitled program for that product, state and date, each as an independent result.
Can we quote a BOP mid-term change?
In SelectRate a mid-term change is an endorsement. It is rated from the policy’s current accepted state on the rating versions locked at the term’s effective date, so a version published later never changes an in force term, and every accepted transaction is kept, unchangeable, in the policy’s transaction ledger. Ask us to walk through it for the program you are planning. See policy lifecycle rating.
Put a program in front of it
Bring a businessowners program you write today and we will work through it with you on the call. Bring your declines as well as your bound business, because on a package product the declines are the part that tells you whether the configuration model is real.