Buyer's guide
How to choose an ISO rating platform
Rating demos look alike. Everyone shows a submission going in and a premium coming out, and everyone's premium is correct on the day. The differences that decide whether you regret the purchase show up two years later, in seven places. This is the question set for those seven, written to be useful even if you buy elsewhere.
Before the shortlist: decide what you are buying
Agree internally where rating stops. A policy administration system owns the customer record, billing and documents. Decide whether you also want the rater to price and record mid-term transactions, because some vendors stop at the quote. A shortlist that mixes the two produces demos you cannot compare.
This page assumes you understand what happens inside a rate. It is about the product and the vendor, not the arithmetic.
1. Authority: who can change a rate, and what stands between the decision and it being live
The best predictor of how a platform feels to own is who may change a number, and how long that takes.
Ask: When we approve a new multiplier for one state, who makes the change, us or you? Can we set one default for a program then override the single state that differs? What happens to what is live while we build the change, and which roles author, approve and publish?
A good answer: your own staff author the change, it exists as a draft that cannot affect production, and publication is an explicit act tied to a date. Be wary of anything where a state multiplier is a support ticket: the vendor's engineering calendar becomes part of your filing response time.
SelectRate: configuration is authored by the customer in Program Studio. You configure it. Not a support ticket. Set one multiplier for the whole program and override the single state that differs, and creating a change never disturbs what is live.
2. Dates: what the system does when the date is inconvenient
Date handling is the cheapest thing to test and the most expensive to get wrong.
Ask: Quote a risk on a date for which the program is not effective, and show me what comes back. Can we rate as of any date, back-dated and future? Is the effective date the only temporal input, or can a caller request a version?
A good answer: an ineffective date returns no number and a reason, and the date drives the version.
Be wary of: a system that silently rates on the nearest available version. It will never appear in a demo and it will appear in an audit. Be equally wary of letting an integrator pin a version: that sounds like control and is a license to rate on content that was not in force.
SelectRate: a program not effective for the quote date returns no premium. The effective date is the only temporal input the API accepts, there are no version identifiers in the public contract, and a publication goes live in Workbench and on the Rating API at once.
4. Visibility: what the system does that you cannot see
A premium you cannot decompose is a premium you cannot defend, and the gap hides in rounding and resolved values.
Ask: Show me every intermediate value at the precision the engine used, not rounded for display. Which inputs did the system resolve rather than receive from us, and does the record say which filed content governed and why? Can I see the indicated premium separately from any underwriter adjustment, with the person attached?
Be wary of a rating detail screen showing inputs and the final premium with nothing between: a receipt, not a worksheet.
SelectRate: every rating step is captured as the engine executes it, with governing values and source references, and every intermediate value is shown at the precision the engine used. Provenance records which filed mapping was selected, why it governed, and the document and page. Indicated and adjusted premium are both retained, with the underwriter who adjusted.
5. Testing: how a change is proved before release
Ask how a change is tested and you learn how confident the vendor is in their release process.
Ask: Can our underwriters rate real submissions against a pending change before it goes live, and compare that version with the live one on the same risks? Is the same engine used for testing and production traffic? Who signs a change off, you or us?
The test to run: take your own recently bound policies, re-rate them on the candidate system, and read the differences one by one. Every difference is a bug, a misconfiguration, or something your current system has been doing wrong, and all three are worth knowing before you sign. The same applies if you are switching from an existing rater rather than buying your first.
SelectRate: changes are tested in Program Studio before release, rating test risks against the draft and against what is published. Underwriter Workbench is where your underwriters work: start a quote, rate it against every carrier program it qualifies for, read the worksheet, apply a debit or credit, bind, and then endorse, cancel, reinstate or renew the policy. It rates on published configuration, on the same engine as the Rating API. Identical inputs, program and date produce an identical premium and worksheet. On a migration, a sample of your bound book is re-rated on both systems and you get the variance report before committing.
6. Distribution: how rating reaches people who are not your staff
Most rating programs fail at the edge, where MGAs, agents and portals consume the rate.
Ask: How does rating reach a downstream partner: one endpoint, a copy of the system, or a file? Can we control which programs, states and classes each can rate, with credentials per partner? What does an unentitled request return, and does it reveal that the thing exists?
Be wary of entitlement enforced by what the caller asks for. If a partner can widen their own access by changing a request, you do not have entitlement, you have a convention.
SelectRate: one endpoint serves every rating channel the customer authorizes, all on the version 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. An unentitled program returns 403 without disclosing it exists.
7. Scope: what the product deliberately does not do, in writing
This is the area buyers skip and the one that predicts the most pain. Ask every vendor for a written list of what the product does not do in the version you are buying. Not the roadmap. The exclusions. Then ask whether that list is published, or told to you privately.
A vendor that publishes its own limits is giving you a buying signal, and it is one of the few reliable ones. Publishing exclusions is expensive: it loses deals and it cannot be quietly revised later. A vendor does it when they would rather lose on the boundary than win and fail the implementation. The opposite answer, that the product can do whatever you need, is not confidence. It is the gap between the demo and the contract, and you pay for it in change requests.
We apply this to ourselves. SelectRate publishes a "Not in this release" list in its own API documentation. Not in this release: short-rate or minimum-earned cancellation (cancellation is pro rata, with an audited factor override), reinstatement after a lapse, rewrite or extension transactions, TRIA, webhooks, asynchronous or batch rating, and a PDF worksheet endpoint (worksheets are JSON). SelectRate is not a policy administration system.
If your architecture needs asynchronous rating, short-rate cancellation or rewrites today, that list should take us off your shortlist now rather than in month four.
Ask: which transactions after the bind does the rater price, and does each one leave a record you can retrieve?
How to run the evaluation in a day
Do not run a feature comparison. Feature grids are won by whoever writes the longest list.
Pick one real program, the awkward one with the state that behaves differently and the classes nobody likes, and give it to every vendor on the shortlist. Ask each to configure it in front of you, rate a few of your own bound risks, show the full rating record, break the effective date on purpose, and hand over their exclusion list.
You will learn more in a day of that than in six weeks of RFP responses, because none of it is a slide.
Questions buyers ask at this stage
Should we build this ourselves instead?
The build is not the hard part. The maintenance is: staying current with bureau content as circulars issue, keeping every prior version reproducible, and proving a rate from three years ago came from content in force at the time. Teams that build underestimate the last two, because neither is visible in year one.
How long should it take to stand up a program?
Ask for a number and hold the vendor to it in the demo, not in a proposal. With SelectRate the program is configured and tested by your own team in Program Studio, so the configuration work is in your hands. It does not include your carrier's approvals or your own sign-off, and a vendor implying otherwise is quoting the easy part.
What belongs in the contract rather than the demo?
Who may change rating configuration and how quickly; what the reproducibility artifact is and how long it is kept; what entitlement guarantees about downstream partners; and the exclusion list, attached as it stands the day you sign.
Bring the awkward program
Run this evaluation on us too. Bring a program you already write, ideally the one with the state that always breaks, and we will configure it live on the call.