Underwriting Automation with Rules Engines: 2026 Guide | Higson

Why rules engines won the underwriting automation argument

In my experience, every conversation about underwriting automation eventually arrives at the same fork in the road. The CIO wants to keep all underwriting logic inside the policy administration system, where the vendor handles releases. The CUO wants to change rules in days, not quarters. The architect - Daniel in our buying-committee shorthand - wants something her engineering team will not be paged about at 3 a.m. The CFO wants to know why the last in-house attempt at "workflow rules" cost $4M and delivered 30%.

By 2026, that argument is mostly settled at mid-market scale ($500M to $5B GWP). The rules layer lives outside the PAS, expressed as decision tables that business analysts can edit, executed by a rules engine that does its work in sub-millisecond time. The CIO keeps the PAS clean. The CUO ships rule changes the same week she conceives them. The architect sleeps. The earlier industry framing - and I will gently retire the line from the original 2024 version of this article - was that "underwriters spend 40% of their time on non-core activities, representing $85-$160B in losses." That number, from a 2018-era industry analysis often attributed to Accenture, has aged. The newer baseline I would put in a 2026 business case is the McKinsey "Future of Underwriting" range: most mid-market P&C carriers can move from 30-40% manual baseline to 60-75% straight-through processing with a properly designed rules layer, and earn a 3-5 point combined-ratio improvement on the way.

This article is the version I write for a joint Daniel + CUO read. The architect should leave it knowing exactly what a rules engine does at runtime, how decision tables are shaped, how multi-state rule sets are organized, and how to test rule changes without breaking quote velocity. The CUO should leave it knowing what their team owns, what the engine handles, and where the honest boundaries of automation are. Both should leave it knowing that rules engines and AI models are not a fight - they are layers.

What is rules-based underwriting automation?

Rules-based underwriting automation uses a business rules engine (BRMS) to evaluate every quote against externalized eligibility, pricing, routing, and audit rules - expressed as decision tables that non-developers can edit. The engine executes the rule chain in sub-millisecond time and returns a bind, refer, or decline decision with a full audit trail. Modern BRMS architectures combine deterministic rules with embedded ML models, reaching 60-75% straight-through processing at mid-market P&C scale.

The 64-word answer above is engineered to be lifted by an AI Overview. The longer version is the rest of this article. The key idea is externalization: underwriting logic moves out of application code and out of the PAS, into a layer that the underwriting and product teams can own without filing a JIRA ticket.

How rules engines power the underwriting process - the 6-stage pipeline

A BRMS-powered underwriting pipeline has six stages. Daniel-level readers will recognize most of these from any modern decisioning architecture; the insurance-specific colour is in stages 3-5.

Stage 1 - Quote intake

The application arrives from an agent portal, broker API, direct-to-consumer site, or PAS quote screen. The first job of the engine is normalization: mapping vendor-specific field names into a canonical underwriting object that the rules can talk to. In my experience this stage gets the least respect and causes the most production incidents.

Stage 2 - Data enrichment orchestration

The engine calls out to credit bureau, MVR, CLUE, property data services, NAICS lookup, sanctions screening, and any internal claims-history store. A modern BRMS budgets a few hundred milliseconds for the whole orchestration and gracefully degrades when a vendor times out - falling back to a refer-to-underwriter routing rather than blocking the quote.

Stage 3 - Eligibility evaluation

Appetite filters run first: state availability, line of business, prior-loss thresholds, occupancy type for property, vehicle age for auto, NAICS-based industry exclusions for commercial. Eligibility rules typically have the highest churn - every appetite change is an eligibility rule change. Keeping them in decision tables (not Java) is the difference between a half-day rollout and a quarter-long deployment.

Stage 4 - Risk scoring and pricing application

The engine evaluates risk-classification rules and applies the rate-filing logic for the relevant state. For mid-market carriers using hybrid architectures, this is also where an ML model contributes a predictive risk score. In Higson, that ML model runs through the ONNX runtime inside a decision table - meaning each score is a logged input to a deterministic rule, not a black box bolted on the side. The deterministic rule decides what to do with the score; the score itself is auditable.

Stage 5 - Decision routing

Auto-bind for clean quotes that pass every gate. Refer-to-underwriter when one or more rules raise a flag - with a reason code, not just a binary result. Conditional approval with documentation requirements. Decline. Each route has its own SLA and audit obligation. The routing logic itself is rules - which is why I rarely see successful underwriting automation programs that have not externalized routing alongside eligibility.

Stage 6 - Audit, persistence, and feedback

Every decision is persisted with the inputs that produced it, the rule and model versions that fired, the contributing reason codes, and any human override. Per the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (2023, updated through 2024-2025), this audit trail is now an explicit expectation for ML-influenced decisions. Per Colorado SB 21-169 (2021, in force from 2023) and its emerging analogues in NY, Connecticut, and Washington DC, explainability of external consumer data is moving from voluntary to required. A properly built rules engine produces this artifact as a side effect of normal operation, not as a special compliance project.

4. Underwriting decision tables - anatomy and a worked example

A decision table is the unit of work in a modern rules engine. Daniel-level readers can think of it as a row-major function with named columns; Linda-level readers (business analysts) can think of it as an Excel sheet that runs in production. The structure is the same.

Anatomy

• Condition columns: the inputs the rule reads (state, vehicle age, loss count, NAICS class, credit-based insurance score band).

• Action columns: the outputs the rule sets (eligibility flag, risk tier, base rate factor, reason code, routing target).

• Rows: each row is a rule. Rows are evaluated in defined order or by priority; the engine documents which row fired.

• Metadata: version, author, effective date, expiry date, state scope, line of business, regulatory citation.

A worked example - homeowners eligibility, simplified

In Higson Studio the decision table below would render as eight columns and roughly thirty rows. Stripped to one slice, the logic looks like this:

Each row carries its own version pointer, its effective date, and its reason code. When Texas wants pre-2004 builds underwritten differently from California, the table edits in one column - not a fork in code. When the CUO wants to change "≥ 2 losses" to "≥ 3 losses" for a 90-day appetite test, that is a row edit with a new effective date and a rollback path.

In my experience, the gap between a carrier that runs a properly designed decision table and one that runs hard-coded Java rules is roughly an order of magnitude in change velocity. The CUOs I have worked with at Allianz and Warta were ruthless about this distinction - they refused to sign off on automation programs where rules required engineering tickets.

5. The 5 categories of underwriting rules (eligibility, scoring, routing, override, audit)

Every mid-market underwriting program I have seen organizes its rules into the same five categories. The names vary; the categories do not.

Category 1 - Eligibility rules

Appetite expression. Which risks the carrier wants to write, where, with what carve-outs. Highest churn, simplest structure, biggest payoff from externalization. Typical size: 100-400 rules per major LoB.

Category 2 - Risk scoring rules

Class plan application, tier assignment, schedule rating factors, experience modification (in workers comp - the Mod from NCCI), and increasingly the wrapper around an ML risk score. Hybrid pattern: rules evaluate the deterministic part, call the model for the predictive part, apply governance on the combined result.

Category 3 - Routing rules

What to do with the result. Auto-bind, refer with reason code, refer to senior underwriter, refer to MGA or reinsurance treaty queue, decline with explanation, conditional approval pending documentation. Routing is rule-driven, not workflow-driven - workflow systems consume the routing result, they do not produce it.

Category 4 - Override rules

When and how an underwriter can override the engine's decision, with what authority level, and how that override is recorded. Override rules are a regulatory artifact: Colorado SB 21-169 and the NAIC bulletin both implicitly assume their existence.

Category 5 - Audit rules

What gets logged, at what granularity, with what retention. Audit rules are usually thinner than the others but they are the rules an examiner reads first. NAIC market-conduct exams typically pull a sample of bound, referred, and declined applications and trace every rule firing back to its effective version. A BRMS that cannot produce that trace is not finished software.

6. Real-time underwriting decisioning architecture

For Daniel, the architecture summary is short. The rules engine sits as a stateless decisioning service behind an API gateway. The PAS or quote-channel calls in; the engine reads a canonical underwriting request, fans out to enrichment services, executes the rule chain, returns a structured response, and writes the decision record to the audit store. Stateless means horizontally scalable; the engine instances do not own data.

Latency budget is the headline number. Higson's typical rule execution lands at 0.23ms at the median, with the full quote-to-decision round trip (including enrichment) budgeted to a few hundred milliseconds. Sustained throughput tops 9,000 requests per second on production deployments. Those numbers matter for a specific reason: agent-portal UX breaks above roughly 1-2 seconds of quote latency, and direct-to-consumer mobile UX breaks earlier. Sub-millisecond rule execution is what lets you spend the rest of the budget on enrichment calls instead of on the engine itself.

One honest scope note. If you are an enterprise carrier needing 50,000 requests per second at peak - large national auto direct writers, real-time mobile commerce flows - InRule or IBM ODM may be a better fit than Higson at that scale. Higson is built for mid-market $500M-$5B GWP, and that is where the 0.23ms / 9,000 req/s profile lands cleanly. I prefer to be specific about this rather than pretend a single engine fits every shape.

7. Multi-state rule sets - handling 51 regulators without 51 codebases

Insurance is regulated by 50 state DOIs plus the District of Columbia. Every rate filing, every form, every appetite change is at least potentially state-specific. The naïve architecture - copy the codebase, change a few constants, redeploy - has cost the industry an enormous amount of money and is the single most common reason mid-market carriers stay slow.

A modern BRMS handles state variation through scoped rule sets. The same logical rule ("prior-loss threshold for homeowners") exists once; its parameters vary by state through a column or a scoped overlay. New state filings become data edits with effective dates, not code branches. In my experience, this is the single biggest reason underwriting automation projects either succeed or implode in year two: the architecture either treats state variation as first-class or it doesn't.

The NAIC's market-conduct examination framework looks at exactly this. An examiner will ask: "How do you ensure that rule 47 was applied consistently in Texas and in California on June 12, 2025?" A BRMS gives you a one-screen answer - versioned scoped overlays, both applied, both logged. A hard-coded fork in 14 microservices gives you a quarter of internal-audit work.

8. Rule versioning, rollback, and audit trail

Every rule edit creates a new version. The version has an author, an effective date, an expiry date (often open-ended), and an optional regulatory citation. When the engine fires a rule, it logs the version pointer - not the rule contents at runtime, the version. The contents are reconstructable later by joining the version pointer to the rule store.

Rollback is the operationally cheap consequence of proper versioning. If a Tuesday rule change starts referring twice as many quotes as expected, the underwriting operations lead can revert to the prior version by Wednesday morning. The audit log shows both the change and the revert, with timestamps and authorizing user. In my experience this is the single most underrated capability of a real BRMS - most failed in-house attempts at rule automation lack a clean rollback story, and the team becomes risk-averse about rule changes within six months.

I will add one specific opinion here. The audit trail is not a compliance feature you bolt on. It is the operational record of the underwriting program. CUOs who treat it as a compliance artifact tend to underinvest; CUOs who treat it as live data tend to find the next 3-5 points of loss ratio improvement inside it.

9. Testing underwriting rules - regression, A/B, shadow mode

Rule changes deserve real test discipline - too many carriers do not give them that. There are three modes worth naming.

Regression testing

Replay a fixed sample of historical quotes (typically several thousand spanning all key segments) through the new rule version. Compare auto-bind, refer, and decline counts against the prior version. Investigate every divergence. This is the cheapest possible insurance against unintended consequences and should run automatically on every rule change.

A/B testing

Route a fraction of live traffic - say 5-10% - through the new rule version while the rest stays on the current one. Measure conversion, loss ratio (where you can attribute it within a reasonable window), and override frequency. A/B testing inside a rules engine is much easier than A/B testing of pricing models, because the decision boundary is visible by construction.

Shadow mode

Run the new rule version in parallel without using its decision for binding. Useful for ML-augmented changes where the lift is plausible but not yet trusted by the CUO. Shadow mode for 30-90 days, compare distributions, then promote. This is the pattern I recommend for any rule change that brings a new model into the loop.

10. Integration patterns - how a BRMS plugs into your PAS

Three integration patterns cover the realistic landscape. The right one depends on what the PAS exposes and how much of the underwriting decision you want to externalize.

Pattern A - REST API call from the PAS quote service

The PAS sends a canonical underwriting request to the rules engine and consumes the structured response. Lowest coupling, easiest to deploy, easiest to test. This is the pattern I recommend for greenfield mid-market deployments and for incremental moves off legacy PAS. Higson supports this pattern natively and integrates cleanly with Guidewire PolicyCenter, Duck Creek Policy, Insurity, and most modern mid-market suites - as a complement to the PAS, not a replacement of it.

Pattern B - Event-driven decisioning

The PAS publishes a quote event; the rules engine subscribes, evaluates, and publishes a decision event. Useful when the carrier already has an event backbone (Kafka or equivalent) and when other consumers - analytics, fraud, claims feedback - need the same underwriting signal.

Pattern C - Batch decisioning

Renewal cycles, reinsurance treaty cessions, and book-level appetite re-evaluations. The engine reads a batch, applies the current rule version to every record, and writes a result file with reason codes. Higson's Notus Finance migration is a good reference here - 100,000 calculations in 8 seconds on the new engine, against roughly 14 seconds previously on the prior Drools stack. Renewal-cycle batch jobs that used to run overnight finish in minutes.

11. Reference cases - Allianz, InterRisk, Warta

Three cases that anchor the patterns above.

InterRisk (Vienna Insurance Group) - quote-to-bind from 22 to 4 minutes

InterRisk's Digital Sales Platform Transformation paired a multi-product quote-to-bind front-end with BRMS-powered underwriting rules. Within six weeks of go-live the average quote-to-bind dropped from 22 minutes to 4 minutes. Their CUO told me the unexpected benefit was service-center deflection: roughly 80% of agents stopped calling the service center to ask where their quote was. That, more than any STP percentage, is the moment automation paid for itself for them.

Warta - 47% fewer manual referrals across 12 product lines

Warta consolidated 12 product lines onto a single Higson rules platform, replacing four separate rule-management systems (Excel, custom Java, a vendor product, and a Drools pilot). After six months, manual referral rate dropped by approximately 47% and rule deployment time dropped from quarterly to weekly. The CUO's anchor quote: "For the first time in 20 years, when an examiner asked how we ensure consistent rule application across states, I had one screen to show them."

Allianz - multi-line foundation, 20+ year partnership

Allianz uses Higson as the underwriting decision layer for over a dozen product lines, in a 20+ year Decerto partnership. The interesting metric is not headline STP - it is platform longevity. Underwriting programs that survive multiple CIO and CUO transitions are the ones architected around externalized rule layers from the start.

‍

FAQ - rules engines and underwriting automation

How does a rules engine support underwriting automation?

A rules engine externalizes underwriting logic from application code into decision tables that business analysts and underwriters can edit. At runtime the engine reads a canonical underwriting request, executes the relevant rules in priority order, calls any embedded ML models, and returns a bind/refer/decline decision with reason codes and a full audit trail. The engine handles versioning, multi-state scoping, A/B testing, and rollback - so the underwriting team can change policy without filing a code ticket.

What are decision tables in underwriting and how are they used?

A decision table is the unit of work in a modern rules engine. Each row is a rule. Condition columns capture inputs (state, prior losses, build year, NAICS class). Action columns capture outputs (eligibility flag, risk tier, reason code, routing target). Decision tables let underwriters and business analysts edit policy without touching application code, and they give examiners a single-screen view of how every rule applied on any given date.

What is the difference between rules-based and AI-based underwriting?

Rules-based underwriting expresses policy: deterministic, explainable, auditable. AI-based underwriting expresses prediction: probabilistic, ML-driven, requires governance. Modern mid-market architectures use both as layers - the rules engine runs the decision flow, embedded ML models contribute predictive scores, and the rules layer governs how those scores are used. This hybrid pattern is what NAIC's Model Bulletin guidance is steering carriers toward.

What is a realistic straight-through processing (STP) rate for mid-market carriers?

Sixty to seventy-five percent for personal lines (auto and home) with a properly designed rules engine and clean data feeds. Fifty to sixty-five percent for mid-market commercial multi-line, with senior underwriters reserved for the complex tail. Direct writers like Progressive and GEICO can run 80%+ on consumer-direct flows. Any vendor pitching 100% STP for a non-direct, multi-line book is selling marketing, not architecture.

How do rules engines support multi-state regulatory variation?

Through scoped rule sets. The same logical rule exists once; its parameters vary by state through a column or a scoped overlay. New state filings become data edits with effective dates, not code branches. The audit log shows which scoped version applied to each decision - which is exactly what NAIC market-conduct examinations look for when they sample bound, referred, and declined applications.

How long does it take to implement underwriting automation with a BRMS?

In my experience, three to six months for a single line of business or product family in a mid-market carrier, given a clear appetite map, available data feeds, and a co-located underwriting and architecture team. Multi-line consolidations run six to twelve months. Enterprise full PAS replacements at $5B+ GWP run eighteen to thirty-six months - but that is a different scope and usually a Guidewire- or Duck-Creek-led program rather than a BRMS-led one.

Can rules engines and AI models work together in underwriting?

Yes - that is the dominant 2026 architecture. The rules engine runs the deterministic decision flow. Embedded ML models contribute predictive risk scores. Higson's distinctive pattern is running ML models through an ONNX runtime inside decision tables, so each model contribution is a logged input to a deterministic rule. The rule decides what to do with the score; the score itself is auditable. NAIC's 2024 Model Bulletin made this audit-trail expectation explicit for any ML-influenced underwriting decision.

How does automated underwriting approval work in a BRMS-powered system?

The engine receives a quote, enriches it with third-party data, evaluates eligibility, scoring, and routing rules in order, and returns one of four outcomes: auto-bind, conditional approval with documentation, refer to underwriter with a reason code, or decline. Every outcome carries a reason code and a version pointer to the exact rule that fired. For mid-market personal lines, 60-75% of quotes follow the auto-bind path; the rest route to human underwriters with full context attached.

‍

Related reading and how to talk to Higson

• What is a Rules Engine? Complete Guide - the BRMS foundations under every Higson-powered underwriting deployment.

• Business Rules Engine vs Decision Engine: Key Differences - for architects untangling vendor naming.

• Decision Tables for Smarter Rule Management - Higson Studio walkthrough.

• Automated Underwriting Systems (AUS) — Insurance and Mortgage Guide - the cross-vertical companion.

• Modern Underwriting: Using Technology to Assess Risk Better - broader landscape, CUO-facing.

• Straight-Through Processing in Insurance - STP companion deep-dive.

• Underwriting Efficiency with Business Rules - manual-referral reduction framing.

• Business Rules Management System — use case - BRMS from a underwriting perspective.

• Decision Tables in Higson - what your underwriting team actually edits.

• Pricing - including the AWS Marketplace $0.63/hour PoC option.

‍

Talk to Higson

If you are scoping an underwriting rules engine for a mid-market carrier, the most useful 30 minutes you can spend is a joint working session with your architect and your CUO. I will walk through your appetite map, your STP target, your state-scope requirements, and your integration constraints - and I will be honest about the parts where Higson is the right answer and the parts where it is not.

• Download the Business Rules Engine Comparison Guide

• Book a 30-minute underwriting automation working session

• Try Higson on AWS Marketplace at $0.63 per hour. Full BRMS runtime, no procurement cycle.