Who it is for
Know what everyone writing on your paper is actually rating
A carrier owns the filed position and carries the consequence of it. Most of the people applying that position day to day are not its own staff. SelectRate gives you one place to configure and test a version, one date on which it takes effect for everybody, and one record of every rate that can be re-rated years after the quote.
The exposure is not speed, it is drift
Ask a carrier what it fears about delegated rating and the answer is rarely turnaround time. It is not knowing.
Drift is slow and it is quiet. A deviation approved in March is still being applied in a form that was superseded in June. A state override lives correctly in one program and incorrectly in another. A spreadsheet at the edge of the channel has quietly become the real rating system for one class.
None of that announces itself. It surfaces at the worst moment, which is usually not the quote. It is the letter two years later from a regulator, a reinsurer or an auditor asking why this policy was rated this way, and the discovery that the answer would have to be reconstructed rather than retrieved.
The governance question is simple to ask and hard to answer: for any policy on your paper, which version of your position produced the number, and can you run it again?
One version, published once, effective everywhere at the same moment
Configuration is authored in Program Studio and versioned from the beginning. Creating a change never disturbs what is live, so work in progress cannot leak into production while it is still being argued about.
A version is published with an effective date. On that date it is live in Underwriter Workbench and on the Rating API at once. There is no second release for the API, no notice asking delegated writers to update their copy, and no window in which two versions of your position are both in force because one channel moved faster than another.
A filed position that takes effect in one place at one moment is worth more than a fast one.
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.
Effective dates that fail closed
The effective date is the only temporal input the Rating API accepts. There is no way to pin a version, and there are no version identifiers anywhere in the public contract.
That is a control decision rather than an omission. The version is a consequence of the policy date, resolved by the engine, not a parameter a downstream caller can choose. Nobody at the edge of the channel can shop for a version that produces a better number.
The failure mode is closed rather than open. A program that is not effective for the quote date returns no number and says why, and the result carries no premium rather than a guess. A rating system that will not answer is safe. A rating system that answers confidently from the wrong version is the one that creates the letter two years later.
A rating system that produces a number it cannot support is worse than one that says it cannot produce one.
One default, and the state that differs
Countrywide and state-specific rules are resolved per risk rather than hand-coded. Set one multiplier for the whole program and override the single state that differs.
The alternative is what most carriers actually live with: a copy of the program for every state, each one a candidate for its own quiet error, and a change that has to be applied correctly in forty places to be applied at all. One default and a named exception is not a convenience feature. It is how you keep a single filed position from becoming fifty versions of itself.
Your deviations also sit in their own layer. The ISO rating base is maintained by SelectRate against circulars as they issue. Carrier configuration, your approved deviations and company multipliers by state, sits above it. Program configuration sits above that. When a circular issues, the base layer moves underneath you and your configuration stays intact, so content maintenance does not become a re-approval exercise. The mechanics of versions, overrides and testing are set out on the rating configuration page.
Provenance back to the governing filed source
Every rating step is captured as the engine executes it, with the governing value and where that value came from. Each derived value records which filed mapping was selected, why it governed, and the document and page it came from.
On general liability, territory is derived from the filed mapping and reported in the worksheet provenance. The caller does not send a territory, which removes the possibility of a downstream user choosing one that suits the risk.
Every intermediate value is shown at the precision the engine used. Nothing is rounded into a summary that hides the step that actually moved the number.
Underwriting judgment stays visible as judgment. The indicated premium is the engine's number, 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. You can see where your filed position ended and where discretion began, which is exactly the boundary a file review is interested in.
The whole premium is explainable because every value traces to the layer and the version that produced it, not because every value came from a filed page.
The quote from three years ago
Rate a risk as of any date. Prior versions stay callable for audit. A quote from three years ago re-rates on the version and edition it was written under, not on today's content.
The record underneath is structured for that. A quote holds revisions, a revision holds rating runs, a run produces a result, and the execution is immutable. Amending a quote increments the revision; rating does not. Old runs are retrievable and byte identical forever, and every call carries a correlation id.
So the answer to a regulator, a reinsurer or an internal auditor is not an explanation. It is a rerun plus a worksheet showing the governing values and the filed source for each step, printable for the file. Worksheets are JSON and fetched by link, with no PDF endpoint in the API, which is worth knowing before you design a filing pack around them.
Access, and the evidence behind it
Access is role-based across Program Studio, Underwriter Workbench and the Rating API. 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. Entitlement is enforced where the rate is produced: grants decide which programs a client can rate, and a program it is not entitled to returns 403 without disclosing that it exists.
SelectRate is built and operated by Selectsys Tech LLC, which maintains SOC 2 Type II; the report is available under NDA. Encryption is applied in transit and at rest, and security issues can be reported to security@selectrate.ai. The full detail, including how rating integrity and audit are handled, is on the security page, which is the right document to put in front of your own risk and vendor management teams.
What SelectRate records, and what it does not do
SelectRate rates and records policy transactions. It holds the bound policy term, its current rated state and a ledger of every transaction, each with its calculation and worksheet. It is not a policy administration or accounting system: billing, invoicing, commissions and accounting stay in the systems you already run.
Endorsement, cancellation, reinstatement and renewal are rated in SelectRate from the policy's current accepted state, on the rating versions locked at the term's effective date. Every accepted transaction is kept, unchangeable, in the policy's transaction ledger.
If you are evaluating it as a policy administration system, it is not one: it is the rating record behind the policies your writers bind.
Questions carriers actually ask
Can a delegated writer choose which version of our position to rate on?
No. The effective date is the only temporal input the API accepts, there is no way to pin a version, and there are no version identifiers in the public contract.
What do we hand a regulator or a reinsurer?
The quote re-rated on the version and edition it was written under, plus the worksheet for that run, which carries the governing values and the filed source reference for each step, including which mapping governed and why.
If a circular changes the content underneath, do our approved deviations have to be reapplied?
No. The base layer moves underneath you and your configuration stays intact. Your deviations live in their own layer above the bureau base.
Can we limit which programs an MGA can rate?
Yes. 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. The distribution view of that is covered on the wholesaler and program administrator page, and the panel view on the MGA page.
Can we see every transaction on a policy written on our paper?
Yes. Each policy term has a transaction ledger, from the bind through every endorsement, cancellation, reinstatement and renewal, each with its calculation and worksheet.
Test it against a rate you have already had to defend
Take a policy you were once asked to explain, and ask to see it rated on the version that was in force when it was written. Book a call, bring the program, and we will configure it with you on the call.