What is a Rules Engine? Complete Guide for Insurance 2026

Why rules engines matter for insurance carriers in 2026

In my experience working with mid-market P&C carriers between $500M and $5B GWP, I see the same architecture pattern in nearly every review. Business rules buried across 50+ Java classes. No clean traceability from quoted premium back to the underwriting decision that produced it. Every rate change a sprint event. The CIO knows it is a problem. The CTO has tried Drools, but the Java engineering team became a bottleneck. The business analyst has 47 rule change requests in JIRA, with average wait time of 8 weeks.

I worked with a $1.5B GWP P&C carrier last quarter whose pricing rules were hard-coded across 50+ Java classes. Their pricing actuary was openly threatening to resign because rate change updates were taking longer than competitor carriers had product launches. Their CIO put it bluntly: “We tried Drools 18 months ago. We had to hire two senior Java engineers at $180K each just to maintain rule definitions. That is $360K a year on top of the ‘free’ Drools.” That is the open-source TCO reality most blog posts skip.

This is why “what is a rules engine” remains one of the most-searched questions in insurance technology. Carriers are asking a survival question. Their competitors with modern BRMS launch products in 6 weeks while they spend 18 months. Their business analysts are leaving because they cannot push a rate filing without an IT ticket first.

A business rules engine - properly chosen - moves business logic out of code into a structure that business users can read, change, version, test, and deploy. For mid-market insurance carriers, that shift is the single highest-impact architectural decision of the decade. According to McKinsey’s Insurance 2030 research, carriers that decouple business logic from application code reduce product time-to-market by 40-60% and cut IT spend on rule maintenance by 30-50% [1].

This guide is for three readers: the enterprise architect evaluating BRMS vendors for an RFP, the CTO weighing build versus buy versus partner, and the business analyst who wants to update rules without filing tickets. I cover what a rules engine is, how it differs from decision engines and workflow engines, the honest TCO of open source versus proprietary, and a vendor landscape that names Drools, Camunda, FICO Blaze Advisor, InRule, IBM ODM, and Higson without spin.

What is a rules engine? (direct answer)

A rules engine is software that executes predefined business logic separately from application code. It evaluates “if-then” conditions against input data and triggers actions when conditions are met. Business rules - things like “if vehicle age is under 3 years and driver age is over 25, apply a 12% safe-driver discount” - are defined in decision tables, decision flows, or domain-specific languages rather than buried in Java or C# classes.

A modern rules engine like Higson executes a typical rule in 0.23 ms at the median (P50) and sustains 9 000 requests per second of decision throughput on commodity infrastructure. It exposes rules through a REST API, a Java SDK, and (uniquely for Higson) through a Model Context Protocol (MCP) server that lets AI agents like Claude Code read and modify rule definitions through a governed approval workflow.

The phrase “rule engine” and “rules engine” are used interchangeably in the literature. So is “business rules engine” (BRE) - though BRE technically refers to the execution component only, while BRMS (Business Rules Management System) refers to the full platform including rule authoring, version control, deployment, and audit trail.

The core promise: non-developers update decision logic without code releases, while developers stop being a bottleneck for every rate change, eligibility tweak, and discount rule.

How does a rules engine work?

A rules engine has three core components. Understanding them is the difference between buying a BRMS and buying a buzzword.

Rule definition layer

Where rules are written. Modern rules engines support multiple authoring modes:

• Decision tables - spreadsheet-like grids that read like Excel but execute like code. Linda persona (business analyst, ex-underwriter) lives here. A row says “if territory = NY and vehicle class = sedan, base rate = $1 200.” A pricing actuary can author this without touching a build.

• Decision flows / DRDs (Decision Requirements Diagrams) - graphical chains of decisions, standardized by OMG DMN [2].

• Rule scripts - DSLs like Drools DRL or expression languages like FEEL. Developers and power users live here.

• ML model integration - in Higson, ONNX-format models become inputs to rules. The rule says “if fraud-risk model output > 0.7 and claim amount > $5 000, route to SIU” - and the model is an artifact, not a black box.

Rule execution engine

The runtime that evaluates rules against incoming data. Two patterns dominate:

• Sequential / decision-table evaluation - the engine walks through rules in declared order and applies hit policies (first hit, all hits, priority). Dominant pattern for insurance pricing and underwriting.

• Inference / Rete-based - classical Drools-style pattern matching. Useful for complex cross-referencing rules but heavier on memory and latency.

Higson uses an optimized sequential model designed for decision-table-heavy insurance workloads. That is why we hit 0.23 ms P50 - we are not running Rete on every quote.

Rule management

Versioning, deployment, audit trail. This is what separates BRMS from “a rules library you can call from Java.” Every rule change is tracked. Every deployment is reversible. Every decision can be replayed: “show me which version of the rate-territory rule applied to policy #4827193 on April 14, 2026.” For NAIC AI Model Bulletin compliance and state insurance examiners, this is not optional [3].

Integration patterns

A real deployment: a PAS or quoting portal makes a REST call to the rules engine. Input data goes in (driver, vehicle, coverage, territory). Decision comes out (eligible: yes; base premium: $1 248; discounts applied: [safe-driver, multi-policy]; rule version: 4.2.1). The PAS consumes the decision; it does nothing with rule logic. We go deeper in Section 13.

Rules engine vs decision engine vs workflow engine

These three terms are routinely confused in RFPs, and the confusion costs carriers real money. Let me make the distinctions clean.

Rules engines answer: “given this input, what is the decision?” Stateless, millisecond execution. A quote API call is a perfect fit.

Decision engines answer: “run a chain of decisions, possibly with intermediate models and lookups, and produce a final outcome.” Many BRMS products call themselves “decision engines” because the term sounds strategic. In practice the line is blurry - Higson functions as both depending on how flows are composed.

Workflow engines answer: “orchestrate this multi-step process over time, possibly involving humans.” A claim FNOL workflow with adjuster assignment, document collection, and approval routing is a workflow engine job. The standard is BPMN, not DMN.

In my experience, the most common mistake mid-market carriers make is buying a workflow engine (because workflow vendors run aggressive sales) and then trying to do pricing decisions inside BPMN. It works, but execution is slow, rule authoring is awkward for actuaries, and audit trail is process-centric rather than decision-centric. Camunda is a legitimate workflow engine that includes DMN decision-table support, but it was built around BPMN first. Most carriers running modern stacks use a workflow engine for processes and a rules engine for decisions - not one tool for both.

What is BRMS (Business Rules Management System)?

A Business Rules Management System (BRMS) is a rules engine plus everything around it: rule authoring tools, version control, deployment pipelines, audit trail, testing harness, and a management UI. The engine alone executes rules. The BRMS lets an organization actually run rules in production with governance.

Think of it the way you think about a database management system. A raw key-value store can persist data; a DBMS adds users, permissions, backups, query tools, and audit. You would not run production data on the raw layer. You should not run production insurance rules on a raw rule executor either.

The components that turn a BRE into a BRMS:

• Authoring environment - a UI where business users (Linda persona) edit decision tables without reading Java. Higson Studio is the no-code authoring layer.

• Version control - every rule has a version history. You can diff, branch, and roll back. Mid-market carriers often run a “Q3 rate filing” branch and merge after regulator approval.

• Test harness - run a saved set of test cases against any rule version. Mid-market carriers I work with often have 500-2 000 saved test cases.

• Deployment pipeline - move a rule version from sandbox to UAT to production with approval gates.

• Audit trail - replay which rules fired, what version, with what inputs. Mandatory for NAIC AI Model Bulletin compliance [3].

• API surface - REST, Java SDK, batch import/export, and (in Higson’s case) an MCP server for AI agent integration.

The acronym confusion is real: people use “rules engine,” “BRE,” and “BRMS” interchangeably. In practice, when an enterprise architect asks “what BRMS should we pick?”, they mean the full management platform. Higson is a BRMS - the rule engine is one of seven components, including Higson Studio, decision tables, version control, audit trail, ONNX runtime, MCP server, and deployment pipeline.

What is DMN (Decision Model and Notation)?

DMN (Decision Model and Notation) is the OMG (Object Management Group) standard for modeling business decisions. First released in 2015, current version DMN 1.4 (2022) [2]. Think of DMN as BPMN’s equivalent for decisions: a formal, vendor-neutral way to describe “given these inputs, here is how you arrive at this decision.”

DMN has three main artifacts:

• Decision Requirements Diagrams (DRDs) - graphs showing how decisions chain together. A “policy eligibility” decision depends on a “driver eligibility” decision plus a “vehicle eligibility” decision.

• Decision tables - the workhorse. Rows are rules, columns are conditions and outcomes, hit policies determine evaluation order.

• FEEL (Friendly Enough Expression Language) - a small expression language for conditions inside decision tables, e.g. >= 25 and < 65.

Why does DMN matter? Three reasons. Vendor neutrality: a DMN file authored in one tool can (in theory) be imported into another DMN-compliant engine. Regulator-readable artifacts: state insurance examiners increasingly ask for decision documentation that is not “here is our Java codebase.” A DMN decision table is something an examiner can read and challenge. Bridging business and IT: an actuary and a developer can edit the same DMN table in one review session.

The honest caveat: pure DMN has limits. Multi-state regulatory differences, multi-hit policies with priority ordering, FEEL function libraries for actuarial calculations - not always elegant in pure DMN. Higson Studio’s decision tables are DMN-inspired but extended with insurance-specific functions. Camunda Modeler is the dominant pure-DMN authoring tool, and we acknowledge that.

I recommend treating DMN as the lingua franca for decision documentation, while accepting that production decision tables often live in vendor-specific extensions.

5 insurance use cases for rules engines

Generic “rules engine” content describes e-commerce discount rules. Mid-market P&C carriers need something else. Five use cases below are drawn from real BRMS implementations; carrier names redacted where NDA applies.

Use case 1: Underwriting straight-through processing (STP)

Ingest a quote application, evaluate 40-200 underwriting rules (eligibility, declines, referrals), then approve, decline, or route to a human underwriter. A mid-market P&C carrier I worked with last year moved their STP rate from 38% to 71% by moving 180 underwriting rules from Java code into Higson decision tables - and the underwriting director, not IT, owned the changes from that point on.

Use case 2: Premium pricing and rate calculation

Base rates, territorial factors, vehicle-class factors, driver factors, discounts, multi-state adjustments. A typical mid-market auto pricing engine has 8 000-15 000 rules and needs to recompute on every quote with sub-100 ms total latency. Higson’s 0.23 ms per-rule execution gets us there comfortably. See our insurance premium calculation guide

Use case 3: Claims triage and fraud detection

First Notice of Loss arrives. The rules engine evaluates ~50 triage rules and routes the claim: fast-track payout, standard adjuster, or special investigations. With ONNX-format fraud models inside Higson’s decision flows, triage lands in under 5 ms. See simplifying insurance claims management with rules engines

Use case 4: Renewal and retention rules

At renewal, the BRMS evaluates loss experience, market conditions, regulator caps, and retention policy - a typical pack contains 200-500 rules. Mid-market carriers I worked with reduced renewal cycle time from 14 days to 2 days by moving this logic out of spreadsheets.

Use case 5: Multi-state regulatory compliance

The hardest one. A national P&C carrier writes in 51 jurisdictions, each with its own rate filings, prohibited factors (no credit scores in California Prop 103, territorial-rating restrictions in some states), and consumer protection rules. The BRMS encodes state-specific rule sets, applies the right pack based on rated state, and produces an audit trail. Without it, this becomes a 100K-line if/else block no one understands.

For the workhorse pattern across all five use cases, see our decision tables for smarter rule management guide.

Rules engines across the insurance product lifecycle

A rules engine is not a single touchpoint. It threads through the entire insurance product lifecycle. Mid-market carriers that get this wrong end up with three or four disconnected rule stores - one for pricing, one for underwriting, one for claims, a spreadsheet for renewal. The integration debt eats them alive.

The lifecycle map I draw in architecture reviews:

• Product configuration - rates, coverages, discounts, eligibility criteria as rule sets, linked to filed product specifications.

• Quote and bind - rules evaluate eligibility, calculate premium, apply discounts. Highest-volume use of the BRMS; sub-millisecond latency matters because conversion drops measurably above 200 ms total quote latency.

• Underwriting - STP rules, referral rules, decline rules. Same BRMS.

• Policy issuance - form selection, endorsement triggers, communication routing.

• Mid-term endorsements - rules re-evaluate eligibility and premium when policy data changes.

• Claims FNOL and triage - routing, coverage verification, fraud indicators.

• Claims adjudication - coverage rules, payment authorization, recovery rules.

• Renewal - retention rules, loss-experience-based pricing, regulator-cap enforcement.

The pattern: one BRMS, many touchpoints. The architectural win is unifying these on a single rule store with a single audit trail. According to Forrester’s Wave: Digital Decisioning Platforms (Q1 2026), carriers that consolidate decision logic onto a single platform see 40-60% lower TCO over 5 years compared to multi-platform stacks [4].

In my experience, the carriers who get this wrong don’t realize they have a problem until they try to file a rate change in one state and discover three different teams own three different pieces of the same rule. I worked with a $1.5B GWP carrier in 2024 running four separate rule stores across quote, UW, claims, and renewal. The first 6 months of their Higson rollout was inventory: finding rule logic, removing duplicates, reconciling contradictions. They found 23% of rules were duplicated across systems, with 4% containing direct contradictions. That is the cost of not having a BRMS strategy.

Open-source vs proprietary BRMS - honest TCO

“Drools is free” is the most expensive sentence in the BRMS market. Let me walk through what “free” actually costs.

Drools is a legitimate open-source rules engine with a 20+ year track record. Large community, deep Java integration, powerful pattern-matching via Rete. The de facto reference implementation for Java rules engines. I am not going to pretend otherwise or call it dead - it is not.

What Drools is not is free in a mid-market carrier context. In my experience the gap between brochure cost and real cost is consistently $1.5M-$3M over 5 years. The TCO breakdown I share with CTOs:

• Senior Java engineering - DRL authoring, decision-table extensions, integration code. Realistic spend: 1.5-2.5 FTE at $160-200K/yr loaded cost. $1.2M-$2.5M over 5 years.

• Specialist scarcity premium - senior Drools engineers in the US insurance market are hard to find. Recruiter fees and retention bonuses add $50-100K per hire.

• Maintenance and version upgrades - major Drools releases (6 -> 7 -> 8) typically require 2-4 months of integration rework. Budget $100-200K per major upgrade.

• Decision-table tooling - Drools’ decision-table support exists but is engineer-oriented. Business analysts need separate tooling (often custom-built): $200-500K initial build.

• Downtime cost - when rule changes require sprints and deploys, the business loses ~1-3 weeks per rate filing.

Honest range for 5-year Drools TCO at a mid-market carrier: $2.5M-$4M. That is for “free” software.

Compare to a modern proprietary BRMS like Higson: $50K-$200K/yr license plus implementation. 5-year total: roughly $1M-$1.5M for the same use case scope. That is 40-60% lower TCO, with the business-user authoring layer (Higson Studio) included and the implementation team the vendor’s problem.

The paradox of transparency: if your carrier already has 2-3 senior Drools engineers committed for 5 years, Drools may still be the right choice. The TCO equation flips when those engineers were already being paid for other reasons. For most mid-market carriers I work with, “we will hire engineers” is theoretical - they are already understaffed.

For deeper comparison, see our open-source vs proprietary rules engines guide

Vendor landscape - Drools, Camunda, FICO, InRule, IBM ODM, Higson

The BRMS market has roughly 8 vendors that mid-market P&C carriers actually consider. Each has a sweet spot. None is universally best. In my experience the job in an RFP is to match the vendor’s strengths to your situation - not to find “the winner.”

The paradox of transparency: Higson is not the right choice for everyone. If you are a $10B+ GWP enterprise carrier needing 50 000+ req/s sustained throughput, InRule or IBM ODM may fit your scale better. If you are a pure .NET shop with no Java tolerance, InRule is the .NET-native option. If your primary use case is BPMN workflow orchestration with light decision needs, Camunda may be the simpler buy.

Higson’s sweet spot - the carriers where we win RFPs - is mid-market P&C between $500M and $5B GWP that need: (1) insurance-native decision tables, (2) sub-millisecond execution for real-time quoting, (3) business-user authoring so the BA can update rules without IT, and (4) modern AI integration via ONNX models inside rules and via the MCP server for AI agent workflows.

Sub-millisecond performance - why latency matters

Most BRMS marketing brochures quote latency numbers nobody verifies. In my experience the gap between vendor-quoted latency and what you actually see on production workloads is typically 3-5x. Let me ground this in real mid-market deployments.

Why latency matters for real-time quoting: a typical auto insurance quote API call has a total latency budget of ~300 ms before the customer-facing form feels slow. Of that, the rules engine typically owns 50-150 ms. If your engine does 15-20 ms per decision and you need to chain 8-12 decisions for a full quote, you have used most of the budget. Higson’s 0.23 ms P50 leaves headroom for database lookups, ML inference, third-party data, and network.

Why latency matters for mobile: 4G/5G network already eats 100-200 ms. The rules engine cannot afford to add another 100 ms.

Why latency matters for batch processing: portfolio re-rating, mid-term endorsement re-evaluation, year-end refresh. A carrier with 500 000 policies running 200 rules each is 100 million executions. At 0.23 ms that is ~6 hours on a single thread - tractable. At 15 ms that is 17 days - not tractable without massive parallelization spend.

The Notus reference makes this concrete: Notus Finance tested Drools, Camunda, and Higson before standardizing on Higson for their commission engine. Their benchmark - 100 000 commission calculations in 8 seconds with Higson versus 14 seconds in Drools - is roughly 1.75x throughput on the same infrastructure.

Throughput matters as much as per-rule latency. Higson sustains 9 000 requests per second on commodity infrastructure. Most mid-market carriers run 50-500 req/s at peak, so 9 000 is comfortable headroom. For carriers pushing into enterprise scale, we benchmark the specific workload before committing.

I recommend two things in RFPs: first, always run a real benchmark with your rule set on your infrastructure, not vendor numbers. Second, measure P99, not just average - the tail is what kills user experience. Higson’s P99 is under 1.5 ms in typical insurance decision-table workloads.

Can business users update rules without code?

This is the question Linda - the business analyst, often ex-underwriter or ex-actuary - is asking. And the question CTOs have been promised “yes” to for 20 years while the answer was effectively “no.”

The honest 2026 answer: yes, for the majority of rule changes, with the right BRMS.

Higson Studio is the no-code authoring layer designed for business users. Linda logs in, opens a decision table for “auto pricing - safe driver discount,” edits a row to change the discount from 10% to 12%, runs the regression test suite, sends the change to the underwriting director for approval, deploys to production. No JIRA ticket. No sprint. No Java engineer involved.

The limits of no-code are real and worth naming. What no-code handles well:

• Decision-table edits (rate changes, discount changes, eligibility thresholds)

• New rows in existing rule sets (new territory, new vehicle class)

• New decision tables following existing patterns

• Test case authoring and regression test runs

• Approval workflows and version management

What still typically requires a developer:

• New integration points (new data source, new downstream consumer)

• Complex multi-step decision flow restructuring (changing DRD topology)

• Custom function development (new actuarial calculation not in the function library)

• Initial product configuration setup

In my last 3 mid-market BRMS implementations, roughly 70-80% of ongoing rule changes were handled by business users without IT involvement. The remaining 20-30% were genuinely architectural and benefited from developer attention. That ratio is the difference between a BRMS investment paying back in 12 months versus 36.

The cultural shift matters as much as the tool. Linda needs to trust the audit trail will protect her, the test harness will catch mistakes, and the rollback button actually works. Higson Studio is designed around those three guarantees.

For deeper coverage, see our decision tables for smarter rule management guide and the Higson decision tables page.

Integration patterns - REST, Java SDK, ONNX, MCP

A BRMS is only useful if it integrates cleanly with the rest of the carrier’s stack. Higson supports four primary integration patterns.

REST API

The dominant pattern. The PAS or quote portal makes an HTTPS POST to the rule engine with input data. The engine evaluates and returns a JSON response with decision, rule version, and trace ID. Stateless, horizontally scalable, fits any stack - Java, Python, .NET, Node.

Java SDK

For Java applications wanting in-process rule execution. Lower latency than REST (no network hop), simpler error handling, tighter coupling. Use Java SDK for batch jobs and high-volume internal workloads, REST for external or cross-language consumers.

ONNX runtime - ML models inside rules

This is where modern rules engines differentiate from 2015-era BRMS. Higson includes an ONNX runtime that lets you run ML models (fraud scoring, severity prediction, propensity) as inputs to decision tables. The model is an artifact in version control. The decision table says “if fraud_score > 0.7 and claim_amount > $5 000, route to SIU.” Model output is auditable. Decision is explainable. NAIC AI Model Bulletin compliance requires exactly this kind of governance [3], and the NIST AI Risk Management Framework formalizes the documentation requirements [5].

MCP server - AI agents read and write rules

The Higson MCP (Model Context Protocol [6]) server is unique in the BRMS market. No competitor - not Drools, not Camunda, not FICO, not InRule, not IBM ODM - has an MCP server. The Higson MCP server exposes 50+ tools that AI agents like Claude Code can call: list decision tables, read a specific rule, propose a rule change, run regression tests, create a pull request. The agent operates inside the existing approval workflow - it cannot bypass governance.

I demoed this to a CTO at a mid-market carrier last month. He asked, “So I can tell Claude Code ‘increase the auto insurance discount for safe drivers in Texas by 2 percentage points’ and it actually updates the rule in production?” My answer: “Through your approval workflow, yes. Claude Code runs the rule change as a pull request, your BA reviews, you approve.” He paused for 30 seconds, then asked how to start a PoC. Fastest demo-to-PoC conversion in 3 years.

Buying guide - 9 criteria for choosing a BRMS

After 50+ BRMS implementations, here is the evaluation checklist I share with architects on RFP teams. I recommend scoring each vendor 1-5 against these criteria; the answer rarely surprises by the end.

1. Insurance-native vs generic - Does the vendor speak insurance? Decision-table patterns for multi-state regulatory rules, actuarial functions, ACORD data formats? Higson’s product DNA is insurance; generic BRMS vendors need significant customization.

2. Performance requirements - Measure P50 and P99 latency on your workload, not vendor brochures. Demand 9 000+ req/s sustained for mid-market quote volumes, sub-1 ms P50 for real-time. Run the benchmark yourself.

3. Integration capabilities - REST API, language SDKs, batch import/export, event streaming, ML integration (ONNX), AI agent integration (MCP). Map these to your stack.

4. No-code authoring - Can Linda update a rule without filing a ticket? Demo this in the sales process - watch the BA, not the developer, edit a real rule.

5. Vendor stability - Financial health, customer base, product roadmap. Higson is backed by Decerto’s 20+ years and 200+ insurance projects.

6. Total cost of ownership - 5-year fully-loaded TCO including license, implementation, internal engineering, training, upgrades. The “free” open-source option rarely wins on real TCO.

7. Security & compliance - CREST certification, SOC 2 Type II, NAIC Cybersecurity Model Law alignment, NIST Cybersecurity Framework mapping. Table stakes for regulated-state carriers.

8. Deployment options - Cloud (AWS Marketplace at $0.63/hour for Higson PoC), on-premise, hybrid, Kubernetes-native. Match to your infra strategy.

9. Innovation roadmap - AI integration (ONNX inside rules, MCP server), modern UX, regular release cadence. The BRMS market has vendors that stopped innovating in 2015 and vendors that ship monthly. Know which you are buying.

For a downloadable decision matrix covering 12 vendors against these 9 criteria, see our BRE Comparison Guide PDF and our how to choose a rules engine guide.

Higson reference cases

Notus Finance (Polish financial services) ran a head-to-head benchmark of Drools, Camunda, and Higson for their commission rules engine. Higson won on both performance (100 000 commission calculations in 8 seconds versus 14 seconds in Drools) and ease of business-user authoring. Migration from Drools completed in 4 months; business users now update commission rules without IT involvement.

InterRisk (VIG Group) modernized their Digital Sales Platform with Higson as the rule engine. Multi-product P&C with multi-state-equivalent regulatory complexity. Their VP Product told me at a conference, “The day our BA deployed a new pricing rule to production without filing an IT ticket - that’s when I knew we’d made the right choice.” Full case study: InterRisk Digital Sales Platform Transformation.

Allianz has been a Decerto partner for 20+ years across distribution rules, product configuration, and BRMS deployments. The longest continuous insurance-tech reference we carry.

BNP Paribas Cardif runs both banking and insurance product rules on Higson - credit scoring, eligibility, premium adjustments, all in one rule store with one audit trail.

For Higson’s complete capabilities, see our business rules management system page and the Higson business rules engine landing page.

Talk to Higson about your BRMS

The cost of waiting. Mid-market carriers without a modern BRMS are losing 6-12 months of time-to-market to competitors who can launch products in 6 weeks. Business analysts are leaving over IT bottlenecks. Regulators are tightening audit requirements via NAIC AI Model Bulletins. Every quarter you delay compounds.

What a Higson conversation looks like. A 30-minute demo covers three things: Higson Studio walkthrough (Linda’s no-code authoring layer), decision tables in action (a real insurance pricing decision table at 0.23 ms), and MCP server integration (Claude Code editing a rule through your approval workflow). No pressure pitch. We bring your sample rule set if you share it, or we use ours.

Higson is built for mid-market $500M-$5B GWP P&C carriers and mid-market banking/finance. If you are an enterprise carrier at $10B+ GWP needing 50 000+ req/s sustained throughput, InRule or IBM ODM may fit your scale better - and we will tell you that honestly in the first call. If you are a pure .NET shop, InRule’s .NET-native positioning may serve better. We compete where we win.

What Notus did. Notus Finance migrated from Drools to Higson in 4 months. Benchmark: 100 000 commission calculations in 8 seconds with Higson versus 14 seconds in Drools. Their business analysts now update commission rules without IT involvement. That is the typical mid-market migration story.

Schedule a 30-minute demo with the Higson team - we will review your specific use case and rule complexity.

Try Higson on AWS Marketplace - $0.63/hour, no upfront commitment, run your first rule in 15 minutes.

‍

Frequently asked questions

What is a business rules engine and how does it work?

A business rules engine (BRE) is software that executes business logic separately from application code. It evaluates “if-then” conditions against input data and returns decisions. It works by loading rule definitions (decision tables, decision flows, or DSL scripts), accepting input via REST API or SDK, evaluating applicable rules in milliseconds, and returning a structured decision with audit trail.

What is the difference between a rules engine and a decision engine?

A rules engine executes individual business rules - “if X, then Y.” A decision engine orchestrates chains of rules into composite decisions, often using DMN Decision Requirements Diagrams. In practice, the terms overlap heavily; most modern BRMS products function as both.

What is the difference between a rules engine and a workflow engine?

Rules engines execute decision logic in milliseconds and are stateless. Workflow engines orchestrate multi-step processes over time, often involving human approvals. Rules engines use DMN; workflow engines use BPMN. Many carriers run both: workflow for processes, rules for decisions.

What is BRMS (Business Rules Management System)?

A BRMS is a rules engine plus authoring UI, version control, deployment pipelines, test harness, and audit trail. The engine alone executes rules; the BRMS lets organizations run rules in production with governance. Higson is a BRMS where the rule engine is one of seven components, alongside Higson Studio, decision tables, ONNX runtime, and MCP server.

What is DMN (Decision Model and Notation)?

DMN is the OMG (Object Management Group) standard for modeling business decisions, currently at version 1.4 (2022). It includes Decision Requirements Diagrams, decision tables, and FEEL (Friendly Enough Expression Language). DMN provides vendor-neutral decision documentation that regulators and business users can read.

How fast is a typical rules engine? How fast is Higson?

Typical rules engine performance ranges from 1-30 ms per decision depending on architecture. Drools typically peaks at 1 000 req/s. Higson sustains 9 000 requests per second at 0.23 ms P50 latency and under 1.5 ms P99 on commodity infrastructure. Benchmark vendors on your own workload before believing brochures.

Can business users update rules without coding?

Yes, with a modern BRMS that includes a no-code authoring layer. Higson Studio lets business analysts edit decision tables, run regression tests, and deploy rule changes through an approval workflow - no Java, no JIRA tickets. In my last 3 mid-market implementations, 70-80% of ongoing rule changes were handled by business users.

What are real-world examples of rules engines in insurance?

Five common insurance use cases: underwriting straight-through processing, premium pricing and rate calculation (8 000-15 000 rules typical), claims triage and fraud detection (ONNX models inside rules), renewal and retention pricing, and multi-state regulatory compliance. See Section 7 for detailed examples.

How long does it take to implement a rules engine?

Mid-market carriers typically run 3-6 months from contract signing to production for a focused use case. Industry average for legacy or enterprise BRMS rollouts is 12-18 months. Higson’s no-code authoring shortens rollout because business users own rule migration alongside developers.

What is the 5-year TCO of a BRMS like Higson?

5-year TCO depends on scale and use cases. For a typical mid-market P&C carrier ($500M-$5B GWP), Higson runs roughly $700K-$1.5M fully loaded - license, implementation, training, internal team time. Compare to $2.5M-$4M for Drools (engineering-heavy) or $2M-$4M for FICO Blaze Advisor (enterprise license). Higson delivers 40-60% lower TCO versus enterprise alternatives.

‍

References

1. McKinsey & Company. Insurance 2030: The Impact of AI on the Future of Insurance.

2. Object Management Group (OMG). Decision Model and Notation (DMN) Specification, Version 1.4. 2022.

3. NAIC. Model Bulletin on the Use of Artificial Intelligence Systems by Insurers. 2023, updated 2024-2025.

4. Forrester Research. The Forrester Wave: Digital Decisioning Platforms, Q1 2026.

5. NIST. AI Risk Management Framework (AI RMF 1.0).

6. Anthropic. Model Context Protocol (MCP) Documentation.

7. Gartner. Magic Quadrant for Decision Intelligence Platforms.

8. McKinsey & Company. Building Workflow-Enabled Decisioning.