Key takeaways
- A rules engine applies explicit policy: if these conditions are true, do this. A machine learning model estimates a probability or value from patterns in historical data.
- In P&C insurance, most decisions need both: a model to estimate risk, fraud likelihood or claim severity, and rules to apply underwriting guidelines, filed rates, coverage terms and authority limits.
- The working pattern: the model scores, the rules decide, and both are logged with their versions.
- Regulators are moving in the same direction. The NAIC Model Bulletin sets expectations for AI governance across the insurance life cycle, and Colorado's amended regulation has covered private passenger auto insurers since October 2025.
- Rules do not replace underwriters or claims adjusters, and neither do models. They make decisions consistent and explainable, and send the hard cases to people.
What is the difference between a rules engine and machine learning?
A business rules engine executes logic that people write down: underwriting guidelines, rating tables, eligibility criteria, authority limits, routing rules. Given the same inputs, it always returns the same result, and the rule itself explains why.
A machine learning model learns patterns from historical data and returns an estimate: the probability that a claim is fraudulent, the expected loss for a risk, the likelihood that a customer renews. It can find signals no one would think to write as a rule, but its logic is not written down, so it needs documentation, validation and monitoring.
The question is not which one is better. It is which part of a decision each should handle. For the fundamentals of rules engines, see What Is a Rules Engine?.
How do rules engines and machine learning compare?
Which P&C decisions fit rules, which fit models, and which need both?
A useful test: if a regulator, an agent or a policyholder asks "why?", can you answer with a rule? If yes, the decision step belongs in rules. If the step is an estimate, it belongs in a model, and the action taken on that estimate belongs in rules.
How do rules and machine learning work together?
Three integration patterns cover most P&C use cases:
- The model scores, the rules decide. The model returns a score; rules map score bands to actions, taking into account coverage, limits and authority. This is the most common pattern and the easiest to explain.
- Rules as guardrails. Rules apply hard limits that no model output can override: no automatic decline without human review, no straight-through payment above an amount, no use of a prohibited variable in a state.
- Rules filter, then the model ranks. Rules first remove options the carrier cannot offer or cases it cannot automate; the model ranks or scores what is left.
Two practices make any pattern safer. Log the model version and the rule version with every decision, so you can reconstruct it later. And define a fallback path in rules for when the model is unavailable or its inputs are missing, so the business keeps running.
What does a combined decision look like? An FNOL example
A personal auto claim arrives through first notice of loss. The flow, simplified:
Thresholds are illustrative. Claims leadership owns steps 4 and 5 and can change them in hours, without retraining the models. Data science owns step 2 and can improve the models without changing claims policy.
What do regulators expect from AI and rules in insurance decisions?
NAIC Model Bulletin. The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted in December 2023, sets regulatory expectations for a written AI program, governance, risk management and third-party oversight across the insurance life cycle. It is not a law; states adopt it through their own bulletins. As of NAIC's April 2026 implementation map, 24 states and the District of Columbia had adopted it, and California, Colorado, New York and Texas had their own insurance-specific AI rules or guidance (NAIC, April 2026).
Colorado. Colorado goes further with binding rules. Its Regulation 10-1-1, based on SB21-169, was extended to private passenger auto and health benefit plan insurers effective October 15, 2025. It requires a governance framework with board oversight, a current inventory of external consumer data sources, algorithms and predictive models with version control, documented testing for unfair discrimination, ongoing monitoring including model drift, and a compliance report due July 1, 2026, then annually (Faegre Drinker, September 2025). Because the regulation covers algorithms as well as models, check with compliance whether rules that use external consumer data fall in scope.
What both have in common is a demand for evidence: which model and which rules made a decision, what version they were, how they were tested and who approved them. Separating models from rules, and logging both, makes that evidence much easier to produce.
How do you explain a decision that uses both?
Explain each part with the right tool. For the model part, feature attribution methods such as SHAP show which inputs pushed a specific prediction up or down. SHAP applies to model outputs; it does not explain deterministic rules, because a rule's logic is already explicit.
For the rules part, the explanation is the rule itself: "Referred to SIU because the fraud score was above 0.70 and the claim involved a vehicle added to the policy within 30 days." Combined, the explanation reads as a short chain: what the model estimated and why, and what policy the carrier applied to that estimate.
When is each one the wrong tool?
Machine learning is the wrong tool when the decision must follow written policy exactly (filed rates, coverage terms, regulatory deadlines), when there is not enough representative data, or when you cannot monitor the model after deployment.
Rules are the wrong tool when the signal is a complex pattern across many variables (fraud rings, image-based damage estimates), when rules would need constant manual tuning to keep up with behavior, or when you are trying to write hundreds of rules to imitate a prediction.
Neither replaces people. Underwriters, adjusters and SIU investigators handle the cases that rules and models send to them: unusual risks, borderline scores and anything a guardrail stops.
How does Higson combine rules and machine learning?
Higson is a business rules engine built by Decerto for P&C insurers and financial services companies. In a combined setup, it is the decision layer around your models.
- Bring your own model. Higson's ONNX runtime (since version 4.2) runs machine learning models inside rule execution. Your data science team keeps ownership of its models; Higson does not supply or train them. The score and the rules around it are evaluated in one decision and logged together.
- Decision tables that business teams own. Underwriting guidelines, score thresholds, authority limits and routing rules live in decision tables that underwriting and claims teams edit and test in Higson Studio. Rating tables prepared in Excel are imported through CSV.
- Testing before production. The tester and mass tester run a threshold or rule change against historical cases, so teams see how many decisions change before publishing.
- Versioning, audit trail and granular permissions. Every change is versioned with rollback. Higson 4.3 LTS adds role-based permissions at the level of business domains, sessions and operations, with a full audit trail, so claims leadership can change thresholds while data science and compliance keep their own areas.
- Visibility. The Diagnostic Panel shows flamegraphs of rule calls, heatmaps of decision table rows and P50/P95/P99 percentiles, so you see which rules and score bands actually drive outcomes.
- Real-time performance. Rule execution takes 0.23 ms per decision, with throughput of 9,000 requests/second.
- AI agents and authoring. An official MCP server with 50+ tools lets AI agents work with rules, and the AI Assistant in Higson Studio (beta) drafts functions in Groovy or Python and decision tables from natural-language descriptions.
This setup removes backlog from the IT queue: underwriting and claims own the rules, data science owns the models, and IT gets more time for architecture.
Carriers already use Higson for the rule side of these decisions. At TUW, actuaries publish a new motor rate in 2 hours instead of 2 weeks. BNP Paribas Cardif consolidated claims rules from 5 product lines into one Higson engine in 3 months, with one audit trail.
How do you start?
- Pick one decision where a model already exists or is planned: FNOL triage, underwriting referral or fraud referral are common choices.
- Separate the parts. Write down which steps are estimates (models) and which are policy (rules).
- Move the policy into decision tables with named owners, and keep the model as a separate, versioned artifact.
- Test on historical cases and compare outcomes with current decisions.
- Log both versions with every decision from day one.
- Plan the timeline realistically. Platform go-live with Higson typically takes 3–6 months. After that, adding a new decision area takes weeks, and a single rule or threshold change takes hours.
See how your models and rules would work together in Higson
Bring one decision and one model, such as FNOL triage with a fraud score, and we will show you how the thresholds and guardrails would look in Higson, tested on your own sample cases.
Download the Business Rules Engine Comparison Guide 2026

Take Full Control of Your Product Logic
We provide fee Proof Of Concept, so you can see how Higson can work with your individual business logic.


.png)
.png)
.png)
