Why an underwriting rules engine matters in 2026
An underwriting rules engine is the layer of insurance software that turns written guidelines - eligibility criteria, pricing factors, declination triggers, referral thresholds - into executable, versioned, auditable code that runs on every submission. For a Chief Underwriting Officer at a U.S. P&C carrier in 2026, it is the single piece of the underwriting workbench that determines whether your loss ratio is the result of disciplined risk selection or 47 different interpretations of the same manual.
In my experience working with CUOs across specialty and commercial lines, three forces have made the rules engine a 2026 priority. First, the NAIC Model Bulletin on AI is now adopted in 24 states plus the District of Columbia as of March 2025, and the NAIC’s AI Systems Evaluation Tool pilot launched in January 2026 - examiners will start asking how decisions were made, not just which decisions. Second, Accenture’s Underwriting Rewritten survey of 430 senior underwriting executives shows that more than a third of underwriter time is still spent on non-core activities, most of which trace back to fragmented rules and manual lookups. Third, soft-market conditions in commercial lines mean adverse selection compounds quickly - and the carriers I see protecting combined ratio in 2026 are the ones whose rules engine prevents bad risks from quoting in the first place.
This is a CUO-grade walkthrough: what the engine does, how it differs from hard-coded IT logic, what features actually matter for P&C, how to test rules on historical data before deployment, and how to produce an audit trail a state DOI can read in two clicks. It is the rules-engine companion to our broader underwriting workbench guide.
The guidelines fragmentation problem - anatomy of 47 interpretations
I worked with a Northeast specialty carrier whose CUO had a 312-page underwriting manual, a 47-tab Excel “exception sheet,” and 23 underwriters across three offices. When his actuarial team pulled six months of bound policies for a single class - restaurants with liquor exposure - they found something close to 47 distinct interpretations of the same three-paragraph guideline. Some underwriters had declined risks his philosophy would have written; others had written risks at base rates that should have triggered a 25-point surcharge. The combined ratio for that class was 11 points above plan.
This is the guidelines fragmentation problem, and it is the unglamorous reason most P&C carriers under-perform plan in specialty and complex commercial lines.
Why PDFs and Word documents drift in production
In my experience, written guidelines drift because they are read, not executed. A senior underwriter with 25 years of judgment reads “decline accounts with prior cancellation for non-payment within 36 months” and remembers the carve-out for accounts that subsequently rehabilitated. A new underwriter onboarded six months ago reads the same sentence and applies it literally. The book reflects two different appetites - and neither matches what the CUO intended.
The cost of fragmentation in combined ratio terms
Guidelines fragmentation shows up in three places on the combined ratio. Pricing inadequacy on misclassified risks pushes loss ratio up. Inconsistent declination produces adverse selection - competitors decline risks you write, you decline risks they write, and the residuals concentrate on whichever side is less disciplined. Audit-trail gaps mean reinsurance treaty negotiations and rate filings have to assume the worst about actual practice.
Across the carriers I’ve worked with, the gap between guidelines as written and guidelines as applied tends to be worth three to five points of loss ratio over a 12 to 18 month book. That is the rough order of magnitude I see when carriers move from PDF-and-judgment to a business rules engine for insurance and re-measure the same class.
Why this is a 2026 problem, not a 2019 problem
Three things changed. NAIC AI Bulletin adoption means insurers in adopting states must maintain a written AI Systems Program covering governance, transparency, and accountability - “judgment in 23 underwriters’ heads” does not satisfy that standard. Submission volumes are rising while underwriter headcount is not. Reinsurers are demanding cleaner data on bound risks, with treaty terms increasingly contingent on documented underwriting discipline.
The fix is the underwriting rules engine.
What an underwriting rules engine actually does
An underwriting rules engine evaluates structured submission data against a versioned library of executable rules and returns a decision: bind, decline, refer to underwriter, or refer with conditions. It sits between submission intake (ACORD form, broker portal, or quote-and-bind API) and the policy administration system, and it produces the per-submission decision record that is the basis of your audit trail.
Functionally, every rules engine for insurance does five things. It ingests structured data from the submission and from external sources (ISO, CLUE, D&B, telematics, MVR). It evaluates each rule against that data in defined order. It produces a decision and the chain of rules that fired. It logs every input, every rule version, every outcome. And it exposes a configuration interface - ideally no-code or low-code - so business users can change rules without an IT release cycle.
The five building blocks of an underwriting rule library
A mature P&C rule library is not a flat list. The five categories I recommend CUOs organize underwriting decision rules under are eligibility, pricing, declination, referral, and underwriting authority.
- Eligibility rules answer “does this submission qualify for any product I write?” They are the fastest to evaluate and the cheapest to maintain - class code, state, premium band, prior carrier, prior cancellation reason. They fire before any pricing logic runs.
- Pricing rules turn eligibility into a number. They cover base rate selection, schedule modifications, debit and credit factors, minimum premium floors, and package discounts. In a pricing rules engine for a P&C carrier, this is where actuarial work lands - and where the Excel-to-rules migration usually pays for itself.
- Declination rules are the hard-stop conditions: prior cancellation for fraud, location in a moratorium county, exposure to a class outside your appetite, OFAC or sanctions hits. Declination rules need the cleanest audit trail because they are the rules a state DOI examiner will scrutinize first for unfair discrimination patterns.
- Referral rules route submissions that need human judgment - premium above a band, exposure to a class on the watch list, missing third-party data, or borderline scores. Referral logic is where the engine and human-in-the-loop architecture meet.
- Underwriting authority rules govern who can override what. A junior underwriter can approve a 10-point credit; a senior underwriter can approve up to 25 points; the CUO can approve anything. Authority rules belong in the engine, not in HR memos.
What a rules engine is not
A rules engine is not an AI risk model. It executes deterministic, explainable, versioned logic - not statistical inference over training data. The two complement each other: ML risk models produce a score, and rules decide what to do with it.
A rules engine is also not a policy administration system. The PAS records the bound policy. The engine decides whether to bind it and at what price. Confusing the two is the most common architectural mistake I see in carriers replacing legacy systems - a topic covered in our policy administration vs underwriting workbench guide.
Rules engine vs hard-coded IT logic - when each fits
Most carriers I meet still run some underwriting logic as hard-coded rules inside their PAS or quoting application - Java conditions, COBOL paragraphs, stored procedures. The honest question is not “is hard-coded logic always wrong?” - it is “for which rules is hard-coded the right answer, and for which is the engine?” In my experience, the answer comes down to change frequency, business ownership, and audit demands.
The 4-month IT backlog problem
The carriers that come to me about rules engines almost always describe the same trigger event. The CUO needed to change a single eligibility rule - usually a state-level moratorium response or a class-code reaction to emerging loss experience - and IT quoted four months of release cycle. By the time the change reached production, the opportunity was over.
I’ve worked with a carrier whose IT roadmap had 19 underwriting rule changes queued behind two PAS migration projects. Total elapsed time from “the CUO decides” to “the rule runs in production” averaged 17 weeks. With no-code underwriting rules, the same change happens in 24 hours: a business analyst configures the rule, runs tester mode against six months of historical submissions, and a senior underwriter approves the deployment.
Where hard-coded still wins
Hard-coded logic still has a place for genuinely structural rules - data validation, integration contracts, security boundaries, anything that touches the data model itself. If you change the definition of “premium” in your rating algorithm, that is a code change.
Rules engine vs rules-based vs ML - three terms that get confused
Three terms get used interchangeably in vendor decks.
Rules-based underwriting is the broader category - any deterministic logic that executes against structured inputs.
Rules engine is the software component that hosts and executes those rules.
ML underwriting is statistical inference where a model produces a score or probability from training data.
The right architecture for a 2026 P&C carrier is rules-plus-ML, with the underwriting rules engine as the orchestration layer. The ML model produces a score; the engine decides whether to bind, decline, or refer, and handles the guardrails - confidence-interval thresholds, override patterns, audit-trail recording. I cover this hybrid in our AI risk scoring article.
Building your first rule - eligibility, pricing, declination, referral, authority
The first 30 days after a deployment are when most carriers either build momentum or stall. In my experience, the pattern that produces momentum is to start with one class of business, build one rule of each type - eligibility, pricing, declination, referral, authority - and run them in tester mode against six months of historical submissions before flipping a single rule live. The pattern that stalls is trying to migrate the entire 312-page manual at once.
Eligibility - start with the simplest filter
Pick one product, one state, and write the eligibility rule that gates everything else. For commercial property in Florida, the eligibility rules engine for insurance might evaluate: class code in {appetite list}, TIV below {limit}, location not in moratorium ZIPs, prior carrier not on watch list. Three or four conditions, all structured data, all available at intake. This rule proves the engine works on real submissions, and delivers the first measurable lift - typically a 20% to 35% reduction in time spent on submissions that should never have reached the underwriter.
Pricing - migrate Excel before manuscripting from scratch
Most carriers’ pricing logic lives in Excel - actuarial workbooks with rate tables, schedule modification matrices, debit/credit grids. The fastest path to pricing rules in production is to migrate those workbooks rather than rewrite them. A modern engine should support direct Excel import, with actuaries owning the spreadsheets and the engine consuming them as configuration. Higson treats Excel as a first-class input format because asking actuaries to re-author pricing logic in a new tool is the surest way to lose actuarial buy-in.
Industry experience consistently shows the majority of P&C actuaries still rely on Excel as their primary pricing surface - with version control and audit trail their largest unsolved problem. Excel migration solves both without forcing actuaries to abandon the format they trust.
Declination - the rules with the highest audit stakes
Declination rules are what a state DOI examiner reviews first because they are most exposed to unfair-discrimination claims. I’d require three things of any declination rule before it goes live: a documented business reason that does not depend on a protected class, a tester-mode run on at least 12 months of historical submissions to identify any disparate-impact pattern, and a review log signed by both underwriting and compliance.
Referral - design the human-in-the-loop boundary
Referral rules define what the engine decides versus what a senior underwriter decides. The mistake I see most often is referring too much. A workbench that refers 70% of submissions to a senior underwriter has not solved the productivity problem; it has just moved the queue. The target I recommend for a mature commercial lines book is referral rates between 15% and 30%.
Authority - codify what currently lives in HR memos
Authority rules govern who can override what. They should mirror your existing authority matrix - but in the engine, not in a binder. When authority is in the engine, the audit trail captures every override automatically.
Tester mode - simulating rules on historical data before deployment
The single feature that separates a CUO-grade underwriting rules engine from a marketing-grade one is tester mode - the ability to run a new or modified rule against historical submission data before it touches a live production submission. In my experience, I will not deploy a carrier’s engine without it, and I’d require it as a non-negotiable in any vendor evaluation.
What tester mode actually does
Tester mode takes a configured rule (or a bundle), points it at a frozen snapshot of historical submissions - typically 12 to 24 months - and produces a side-by-side comparison: what the engine would have done versus what the underwriting team actually did. The output should show every submission where the rule would have produced a different outcome, broken down by line, class, geography, and underwriter.
The carriers I work with run tester mode for two purposes. First, regression: does this rule break any decision I want to keep? Second, calibration: does this rule produce the lift I expected on the metric I care about - loss ratio, decline rate, average premium, hit ratio?
A real tester-mode example
I worked with a carrier whose CUO wanted to tighten declination on commercial property accounts with prior cancellation for non-payment. The historic rule was “decline if cancellation within 24 months.” The proposed rule was “decline if cancellation within 36 months.” On paper, a modest tightening. In tester mode, against 18 months of bound submissions, the proposed rule would have declined 4.2% more accounts - but the loss-ratio impact on the declined accounts (using actual paid plus IBNR development) was 14 points worse than the retained book. The CUO deployed the rule the next morning. Without tester mode, that rule would have been an opinion. With tester mode, it was a decision.
What tester mode requires from your data foundation
Tester mode is only as good as the historical submission data you feed it. The carriers that get the most value are the ones whose underwriting workbench captured every submission - including declines, withdrawals, and quote-no-bind - with full structured data. Carriers whose only historical record is bound policies have a survivorship-biased view of their own underwriting. This is one reason I recommend deploying the workbench’s submission intake module before, or alongside, the underwriting rules engine.
<p style="padding-left: 24px;"><strong>Video embed (Higson product demo):</strong> A 4-minute walkthrough of building, testing, and deploying an underwriting eligibility rule in Higson, including tester mode against 12 months of historical submissions. [Embed: higson.io/demo or Decerto Underwriting Workbench demo]</p>
Audit trail - answering the regulator in two clicks
The two-click test is the standard I recommend every CUO use to evaluate a rules engine’s audit trail: from a per-policy view, can a state DOI examiner see - in two clicks or fewer - the exact rules that fired, the data inputs evaluated, the rule version in effect, and the underwriter who approved any override? If yes, you are ready for an NAIC-aligned market conduct exam. If not, you have open regulatory exposure regardless of how good your underwriting is.
What the NAIC AI Bulletin actually requires
The 2023 NAIC Model Bulletin on the Use of AI Systems by Insurers - adopted by 24 states plus the District of Columbia, with several others enacting related guidance and operationalized through the AI Systems Evaluation Tool pilot launched in January 2026 - sets three pillars: governance, transparency, and accountability. For underwriting rules engine purposes, the practical implications are documentation of decision logic, validation and testing records, and the ability to produce decision-level evidence on regulator request.
The bulletin notes that insurers may be asked, including via document production, about development and use of AI, with focus on governance, risk management, and internal controls. A rules engine with native audit trail turns that document production from a six-week scramble into a query.
The state-by-state layer above NAIC
Three states have moved beyond the NAIC framework. New York’s DFS Circular Letter 2024-7 requires insurers to demonstrate that AI and external data systems do not proxy for protected classes and to maintain explanatory documentation. Colorado Revised Statutes §10-3-1104.9 imposes quantitative testing requirements for disparate impact, with private passenger auto and health benefit plans added effective October 15, 2025. California restricts purely automated decisions in health-care contexts.
Carriers writing in any of those three states, plus the NAIC adopting states, should plan governance against the highest applicable standard - not the lowest. I cover the regulatory architecture in our regulatory compliance article.
What a per-policy audit record should contain
For each bound, declined, or referred submission, the audit record should capture the inputs (with source - broker, ACORD, third-party API), every rule that evaluated with its version identifier, the outcome each rule produced, the final decision, the underwriter who approved any override with reason, and the timestamp of every step. That bundle of evidence is what a market-conduct examiner can request - and what your reinsurance treaty negotiation team uses to demonstrate underwriting discipline.
The same audit infrastructure supports adjacent governance work - model risk management, fraud-pattern analysis, and the decision-trail evidence a claims AI system needs to defend its outputs.
Vendor evaluation - what to require beyond marketing claims
I’ve sat in maybe 30 vendor evaluations for underwriting workbench features and rules engines. Most go off track because the carrier evaluates marketing claims rather than operational fit. The questions below are ones I’d require any vendor to answer in writing - and a serious vendor will welcome them rather than deflect.
Required capabilities for a P&C-grade engine
The vendor has to demonstrate, on a real submission, that business users can configure a rule without code; that the rule executes deterministically with sub-100-millisecond latency; that tester mode runs against historical data and produces a side-by-side report; that the audit trail captures inputs, rule versions, and outcomes per submission; and that the engine integrates with at least three external data providers your portfolio depends on (ISO, CLUE, D&B, MVR, telematics, or specialty data).
Every vendor deck describes these capabilities. Not every product delivers at production scale. The Datos Insights Top Trends in P&C 2026 report identifies composable rating environments and modular underwriting workbenches as a 2026 competitive differentiator - exactly the layer where vendor claims and reality diverge most.
Specialty lines expertise - non-negotiable for non-standard risk
A rules engine that ships pre-loaded with personal lines logic will be the wrong fit for a specialty carrier writing E&S property, professional liability, or marine. I’d ask any vendor: how many of your current customers write the line I write? What does your reference customer’s rule library look like for that line? If the answer is silence or generalities, that is a signal.
Data sovereignty and security
Underwriting rules and the bound-policy data they execute against are some of the most sensitive data a carrier holds. I’d require the vendor to specify where data is stored geographically, what encryption applies in transit and at rest, who at the vendor has access to production data, and the breach notification protocol.
Total cost of ownership over five years
Vendor pricing comes in three flavors: per-seat licensing, per-decision pricing, and platform-fee with implementation. I’d model TCO over five years against your projected submission volume, with a sensitivity analysis on growth. The cheapest year-one license is rarely the cheapest five-year TCO.
Reference customer interviews - the single best signal
Ask for three reference customers - and insist on at least one who left the vendor. Current customers tell you what the product does well. A former customer tells you where it breaks. If the vendor refuses to provide a former-customer reference, that is information.
A vendor evaluation matrix
FAQ - underwriting rules engine
What is a rules engine in underwriting and how does it work?
A rules engine in underwriting evaluates structured submission data against a versioned library of executable rules and returns a decision: bind, decline, refer, or refer with conditions. It ingests inputs and external data (ISO, CLUE, D&B), evaluates eligibility, pricing, declination, referral, and authority rules in defined order, and produces a per-submission decision record that forms the audit trail.
What features should a rules engine have for P&C carriers?
A P&C-grade engine needs no-code configuration so underwriters and actuaries can change rules without an IT release, tester mode against historical submissions, native per-submission audit trail aligned to NAIC AI Bulletin requirements, Excel rate-table import, integrations with at least three external data providers, and version control with rollback.
How does it reduce IT backlog and time-to-market?
The engine moves rule changes out of the developer queue and into a configurable interface owned by underwriting and actuarial. The carriers I work with go from 4-month IT release cycles to 24-hour business-user deployment with tester-mode validation. This is the pattern Datos Insights identifies as composable rating in their 2026 P&C trends report.
What is the difference between rules-based and ML underwriting in 2026?
Rules-based underwriting executes deterministic logic that you wrote - eligibility tests, pricing factors, declination conditions - with explainable, auditable outcomes. ML underwriting produces statistical scores from historical data. The 2026 P&C architecture is rules-plus-ML hybrid: ML produces a score, the rules layer decides what it means and handles guardrails.
How does an underwriting rules engine support NAIC AI Bulletin compliance?
The NAIC Model Bulletin requires a written AI Systems Program covering governance, transparency, and accountability - including decision-logic documentation, validation records, and decision-level evidence on regulator request. An engine with native audit trail produces this documentation as a byproduct: every rule version logged, every decision chain captured, every override recorded.
Can underwriters configure rules without IT involvement?
In a properly designed no-code engine, yes - business users (underwriters, actuaries, product managers) configure rules through a visual interface without writing code. IT remains responsible for the engine itself, data contracts, and structural changes affecting the data model. The boundary I recommend: if a senior underwriter can describe the change in one sentence and an actuary can validate the math in a half-day, it belongs to the business.
What does an audit trail look like in an underwriting rules engine?
A per-submission audit trail captures inputs and their sources, every rule that evaluated with its version identifier, the outcome each rule produced, the final decision, any underwriter override with reason, and timestamps. An examiner should reach the full decision chain in two clicks or fewer - the standard the NAIC AI Systems Evaluation Tool, piloted in January 2026, will operationalize.
Talk to Decerto and Higson
Each month a P&C carrier delays modernizing its rules engine is a month of guideline fragmentation compounding into the loss ratio, NAIC AI Bulletin examination exposure widening, and senior underwriter judgment leaking out of the building. The CUOs I work with who waited until 2026 to address the rules-engine gap are running 18-month catch-up programs against competitors who started in 2023.
A 30-minute portfolio assessment with me is how the work I do with carrier boards usually starts. Vendor-neutral. If Higson is not the right answer for your carrier, I will tell you that. The first call is a technical Q&A with me and a senior architect, NDA-protected, no sales pitch and no demo loop.
What you get out of the assessment: a documented inventory of where your current rule logic lives (PAS, Excel, PDFs, underwriter judgment), a gap analysis against NAIC AI Bulletin requirements specific to your states of admission, a sketch architecture for a phased deployment, and a loss-ratio and TCO impact estimate grounded in the carriers I’ve worked with in adjacent classes. Plus a free Higson sandbox: define one of your current rules, watch tester mode run it against sample historical data, and decide for yourself whether the workflow matches how your underwriting team actually thinks.
Two reference customers I would point you to before any conversation. A Northeast specialty carrier with about $400M in premium codified 800+ rules from a 312-page manual over 14 months - combined ratio improvement across migrated classes was 4.2 points, named under NDA on request. A regional commercial lines carrier whose rule deployment cycle went from 17 weeks to under 36 hours.
Sources
- Quarles & Brady LLP - Nearly Half of States Have Now Adopted NAIC Model Bulletin on Insurers’ Use of AI (March 2025).
- NAIC - Insurance Topics: Artificial Intelligence (updated 2026).
- Holland & Knight - The Implications and Scope of the NAIC Model Bulletin on the Use of AI by Insurers (May 2025).
- Buchanan Ingersoll & Rooney - When Algorithms Underwrite: Insurance Regulators Demanding Explainable AI Systems (October 2025).
- Crowell & Moring - NAIC Intensifies AI Regulatory Focus: What Insurers Need to Know (March 2026).
- Accenture - Underwriting Rewritten survey of 430 senior underwriting executives (2024, referenced 2026).
- Datos Insights - Top Trends in Property and Casualty 2026: Building the Intelligence-Ready P/C Carrier.
- Datos Insights - P/C Commercial Underwriting Workbench (2025).
Subscribe to receive the latest blog posts to your inbox every week.
