v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch

Quoting in insurance that
moves when your rates do.

Rate tables, factors, eligibility, and bind rules live in visual decision tables your pricing and underwriting teams edit directly, with every version approved and traceable to the revision behind it. A rate change goes live on its effective date instead of waiting for the next release train.

From decline to priced quote,
start to finish.

Watch a Monday in a homeowners quoting team: a well-kept 17-year roof auto-declined, a one-cell change to the rating policy, a replay over 780 declined submissions, a signed release - and declines that come back with a premium on them.

scroll to play
Monday, 08:56

A clean risk comes in.

QT-8241: homeowners HO-3 in Austin, TX. Coverage A $420,000, no claims in eight years, roof inspected two weeks ago. The roof is 17 years old.

The case file

Sound roof. Wrong number.

The inspector scored it 8.6 out of 10: shingles intact, no soft decking, full tear-off in 2009. The appetite rule reads roof age and nothing else, and 17 is past the 15-year line.

One cell

Decline becomes a surcharged quote.

The failing rule opens the live rating policy. The 1.25 factor for 16 to 20 year roofs was already filed and sitting in the table. On a branch, the action stops declining and starts using it.

Proof before production

780 declines replay.

Sixty days of declined submissions re-run against the draft while you watch: 520 come back as priced quotes, expected loss ratio inside the filed range, roofs over 20 years still decline.

Sign-off

Actuarial approves. v3.1.0 ships.

Priya Shah signs the release and it promotes through staging into production, with the diff, the approval, and the filing reference attached to the version.

Same day

Declines come back priced.

QT-8241 rates at $1,642 a year on the filed 1.25 factor. Across the board roof-age declines convert, except the 24-year roof that is still outside appetite. Quote rate: 71 to 88 percent.

The rates are approved.
The release is in six weeks.

Quoting in insurance looks like one number to the applicant and a chain of decisions to you. Is this risk inside appetite, which filed rate table applies in this state on this effective date, which factors and credits stack and in what order, and can the producer bind it or does it refer to an underwriter. In most carriers and MGAs that chain is spread across a rating module inside the policy administration system, a workbook of rate tables the actuarial team maintains, and eligibility logic hard-coded into the quote portal. No single artifact holds the answer, so nobody can change one part of it with confidence.

The gap that hurts is between approval and production. A rate revision clears state review with an effective date attached, and then it waits: on a product analyst to reconfigure the tables, on IT to schedule the change, on a regression cycle. Legacy stacks are routinely described in cycles measured in quarters from analysis to implementation, while direct writers requote in seconds. The appetite the market moved on three weeks ago is still quoting today, and the result shows up in the loss ratio long before the fix ships.

Exceptions make it worse rather than better. In commercial lines the exceptions are the work, not the edge case, and when referral logic sits in portal code every non-standard submission comes back as the same generic hold with no reason attached. The underwriter re-derives the risk from scratch, and straight-through processing stalls exactly where the rules could have said which condition tripped and what would clear it.

Then a market conduct examiner asks which rating version priced a policy bound last March, who changed the territory factor, who approved it, and which filing that version maps to. When the answer lives in a spreadsheet revision history, a vendor config export, and a chain of change-request emails, assembling it takes weeks and defending it takes longer.

Appetite, rating, and bind
in one governed flow.

One evaluation takes a submission from in-appetite check to priced, bindable quote, and returns the rules behind every number in it.

01

Rate tables that read like rate tables

Base rates by state and territory, class and construction factors, deductible and protective-device credits, minimum premium: all of it is naturally tabular, and in GoRules it stays tabular. Rate tables are decision tables your actuarial and product teams read and edit directly, ZEN expressions carry the rating algorithm over the exposure base, and typed TypeScript function nodes cover the awkward parts such as pro-rata terms, package rounding, and premium caps. Every channel rates against the same published version, so the number on the agent's screen matches the number on the bind request, in milliseconds, on every channel.

02

Appetite, referral, and bind rules in the same evaluation

Knockouts run first as Policies, ordered blocks evaluated in sequence, so a class you do not write or a protection class outside appetite stops before anything is priced. Rating follows, then referral and bind rules decide whether the producer can bind directly, whether the program limits apply, or whether an underwriter has to look. Referrals carry the triggering rule and its reason with them, so the case arrives with the condition that tripped instead of a generic hold.

03

A version per revision, with an approver on it

Branch the live rating project, apply the approved revision, and route it through a change request with named approvers before it becomes a release. Git-like version control records who changed which factor and when, environments keep dev, staging, and production separate, and rollback is one click. Months later the same trail answers the harder question: the release that priced a given bound policy is still retrievable and still readable.

Keep the PAS.
Own the rating rules.

Your policy administration system keeps issuance, endorsements, and billing. GoRules owns the decisions that turn a submission into a bindable quote.

01

Connect the quote path you already have

Your quote portal, agent portal, comparative-rater feed, or PAS calls GoRules over REST wherever a premium or eligibility answer is needed, or embeds the MIT-licensed open-source ZEN engine with SDKs for Node.js, Python, Java, Go, C#, and Rust. Submission data from ACORD forms, prefill and third-party data, and loss-run summaries all arrive as plain inputs.

02

Model the rating rules

Rebuild the product as a decision graph: appetite and eligibility Policies, base-rate tables per state and territory, factor and credit tables, the rating algorithm in ZEN expressions, then referral and bind rules at the end. Start from the insurance templates rather than a blank canvas, and let natural-language rendering give the actuary, the underwriter, and the compliance reviewer the same artifact to read.

03

Simulate before anyone quotes on it

Run last quarter's submissions through the simulator against the current release and the proposed one, and compare premium by premium the way a mass rate comparison against a legacy engine works. Keep the interesting risks as test cases so they run on every future change, and trace execution node by node when a number looks wrong.

04

Release on the effective date, then operate

Promote the revision through environments with an approval recorded at each step, timed to the effective date rather than a release train. In production every quote returns the premium plus the rules that produced it, ready for the quote document, the referral queue, and the audit record. When appetite shifts, the underwriting team edits the table and ships the same week.

Built for production,
not proof of concept.

  • Sub-millisecond evaluation with the open-source ZEN engine (Rust core), embedded or over REST, so a full appetite-plus-rating pass fits inside a quote page load
  • Git-like version control on the rating project: a branch per revision, change requests with named approvers, full diff history on every factor, one-click rollback
  • Self-host with Docker or Kubernetes so submission data, loss runs, and bordereaux never leave your infrastructure, or run on GoRules Cloud
  • Full traceability: every quote links to the rules that fired, every rule change records who changed what and when, with SSO, role-based access control, and SOC 2 behind it
  • No lock-in: the core engine is MIT-licensed open source with a Rust core, and 70+ industry templates, including insurance underwriting and pricing, give you a working starting point

Questions, answered.

What is quoting in insurance?

Quoting in insurance is the process of turning a risk's details into a price and a coverage offer. The insurer checks the risk against its appetite and eligibility rules, retrieves the filed base rates for the state, territory, and class, applies factors, credits, and debits, and returns a premium with limits and deductibles. A quote is an estimate rather than a commitment: it becomes a premium once underwriting is complete and the policy is bound. GoRules holds the rules behind that process, from eligibility through rating to bind, in decision tables your teams own.

What is the difference between a rating engine and a policy administration system?

A policy administration system owns the policy lifecycle: issuance, endorsements, renewals, billing, and documents. A rating engine answers a narrower question, whether the risk is eligible and what it costs, and gets called at new business, endorsement, and renewal. When rating is embedded inside the PAS, every rate change becomes an IT project on the vendor's cadence. GoRules is the standalone decision layer for that question, so the PAS keeps everything else and the rules stay yours.

Can our actuarial and underwriting teams change rate tables without an engineering release?

Yes. Rate tables, factor tables, and eligibility rules are visual decision tables, and natural-language rendering keeps each rule readable for reviewers who do not write code. GoRules AI can draft a rule change, run your test cases, and explain why a submission rated the way it did, but it never deploys or releases anything. Changes go through a change request with approvals and are promoted through environments as versioned releases, and any release rolls back in one click.

How does GoRules help with rate filings and market conduct exams?

Each rating revision is a versioned release with a full diff, an author, and a recorded approval, so you can show which version was live on any date and reproduce the exact rules that priced a specific bound policy. Test cases and simulation runs document that the revision was validated before it went live, which is the evidence internal audit and examiners ask for alongside the filing itself. GoRules supplies the traceability; the filing, the actuarial justification, and the compliance obligations remain yours.

How do eligibility, referral, and bind rules fit into one decision?

They run as stages of a single evaluation. Appetite and eligibility Policies knock out risks you do not write before anything is priced, rating produces the premium and its components, and referral and bind rules then decide whether the producer can bind directly, whether binding-authority limits apply, or whether an underwriter has to review. Because each stage returns the rules that fired, a referral arrives with its reason attached and clean risks go straight through without a queue.

The same engine,
next door.

One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail.

Approved on Friday.
Quoting on Monday.

Load one state's rate table into a decision table, replay last quarter's submissions through the simulator, and compare the premiums against your current engine before anything ships.