Rules-Based Fraud Prevention: Why Carriers Still Choose It in 2026

The conversation every fraud platform pitch ends up having

Last quarter I sat with a VP SIU at a $1.8B mid-market P&C carrier evaluating fraud detection platforms. Three vendors had pitched her pure AI. The fourth pitched rules-only. None of them survived the first conversation with her General Counsel.

He kept asking the same question: “When a NAIC examiner asks why this $80K claim was denied, what do you show them?”

The pure AI vendors showed feature importance rankings. The rules-only vendor showed a 12-page rule book that hadn’t been updated since 2019. Neither was an answer.

That’s the conversation every fraud detection pitch ends up having in 2026 - and the answer reveals why rules-based fraud prevention isn’t a legacy approach to retire. It’s the governance foundation that makes everything else defensible.

In my experience, the carriers asking “rules or AI?” are asking the wrong question. The right question is: what’s your governance layer for AI? Rules-based fraud prevention is that governance layer.

The Coalition Against Insurance Fraud estimates US insurance fraud at $308 billion annually. Most carriers still run fraud detection systems with 80%+ false positive rates, designed for an era when investigators reviewed every flag manually. Modern hybrid rules + ML systems reduce that FP rate to 25-40% while maintaining 30-50% investigation hit rates - but only on architectures that NAIC examiners will accept under audit.

This article is for the VP SIU, General Counsel, or Daniel-the-Architect who needs to defend an architecture decision to a board. Here’s why rules-based stays at the foundation in 2026 - and how to build the hybrid layer on top of it correctly.

What rules-based fraud prevention actually is in 2026

Rules-based fraud prevention uses deterministic logic - explicit rules, thresholds, and decision tables - to flag suspicious claims before settlement. In 2026, most NAIC-compliant fraud detection systems combine rules with AI/ML scoring (hybrid architecture). Pure AI alone struggles to pass NAIC explainability audits; pure rules alone miss novel patterns. Rules-based is the foundation, not the limit.

That definition fits in a snippet, but it skips the part that matters: rules are where regulatory defensibility lives. When you can point at a single decision-table row and say “this rule flagged this claim, this is who authored it, this is when it was deployed, this is the evidence” - you’ve made a fraud decision a NAIC examiner can audit. ML scores alone don’t carry that defensibility, no matter how good the model is.

The “rules vs AI” debate is a 2018 conversation

Walk into any fraud vendor pitch in 2018 and you’d hear “rules-based detection is obsolete, AI is the future.” That pitch died. Here’s what killed it.

In 2024, the NAIC issued the Model Bulletin on Use of AI Systems by Insurers, explicitly requiring insurers to govern AI systems with documented controls, testable validation, and explainability. Colorado’s SB 21-169 raised the bar further with algorithmic discrimination testing requirements. By 2026, 48+ US states have either anti-fraud reporting mandates under the NAIC Anti-Fraud Model Act or state-specific AI governance requirements that intersect with fraud detection.

The result: pure AI fraud detection lost its differentiation pitch. Aite-Novarica’s vendor research has tracked the consolidation - by 2025-2026, 90%+ of enterprise and upper mid-market fraud platforms ship as hybrid (rules + ML), not pure AI. Shift Technology, Friss, FICO Falcon, SAS Fraud Framework - all of them now include rules-based components, often described as “guardrails” or “policy layers.”

I’ve worked with carriers who tried to deploy pure AI fraud detection in 2022-2023. By 2024, they were retrofitting rules layers underneath the ML scores. The General Counsel demanded it.

The honest 2026 framing: rules-based fraud detection didn’t lose. It became the foundation everyone else now bolts ML on top of.

When rules-based wins on its own

Five scenarios where rules outperform pure AI - and where I recommend rules-led architecture even when ML is on the table.

1. Deterministic fraud patterns

Known fraud schemas don’t need ML to detect. Staged accident pattern, ISO ClaimSearch hits, prior fraud association, geographic clustering with prior conviction data, NICB watchlist hits - these are deterministic. A decision-table row catches them in 0.23 milliseconds. An ML model would catch them too, but with a feature importance ranking nobody wants to defend in court.

2. Regulatory clarity for NAIC examiners

When a state fraud bureau or NAIC market conduct examiner asks “show me the rule”, you want a single decision-table entry, an author name, a deployment date, and a version history. That’s a 30-second answer. With pure ML, the answer is “the model assigned a risk score of 0.87 because of these 14 weighted features…” - and now you’re explaining SHAP values to a regulator who wanted a yes/no.

3. Explainability mandatory (Pain F3)

Some claims decisions can’t be defended without line-by-line explainability. Subrogation pursuit, denial decisions, SIU referral to law enforcement - all need a clear deterministic justification. I recommend rules carry these decisions, with ML as supporting context, not primary decision logic.

4. Speed-critical inline STP path

Claims STP requires sub-100ms total fraud decisioning latency. ML inference typically runs 50-500ms. Rules engines optimized for execution - Higson runs at 0.23ms per rule set, sustaining 9 000 requests per second - fit inside an STP path without breaking it. ML scoring can run in parallel or asynchronously, but the gating decision needs to be deterministic and fast.

5. Rule velocity for SIU teams (Pain F2)

When your SIU team spots a new fraud pattern on Monday - say, a staged-injury ring targeting workers’ comp claims in three specific ZIP codes - the question is how fast that pattern becomes a production rule. With no-code rule authoring built for SIU managers (Higson Studio is one of the few in the BRMS category), it’s Monday afternoon. With an ML retraining pipeline, it’s a 90-day cycle. The fraudsters earn the difference.

When AI-based wins on its own

Honest counter-section. Rules-based has real limits, and I won’t pretend otherwise.

Novel fraud patterns that haven’t been written into rules yet - synthetic identity rings, deepfake auto damage photos, voice-cloning FNOL fraud - these are where ML earns its keep. A rule can only catch what someone has thought to write down. ML can catch anomalies in patterns nobody has named yet.

Unstructured data analysis is the other clear ML win. NLP on adjuster notes and claim narratives, computer vision on damage photos, image forensics for tampered evidence - these need ML. No rule book extracts intent from a free-text statement.

Scale anomaly detection across millions of records also belongs to ML. When you’re looking for a subtle behavioral baseline drift across 12 million claims, you’re not writing rules - you’re training an autoencoder or a graph neural network.

This is where AI-native fraud platforms like Shift Technology and Friss have real strength. I’ll be honest: Higson doesn’t compete frontally with Shift Technology or Friss. Different category. They’re AI-native fraud platforms. We’re the BRMS - the rules execution and governance foundation. The right architecture in 2026 uses both layers, with rules below and AI above.

The hybrid answer - rules + ML combined

The architecture that wins in 2026 isn’t rules-or-AI. It’s rules + ML inside the same execution path, with rules as the governance and audit layer and ML as the pattern-discovery layer.

Here’s how it works in practice:

The critical design choice: the ML score is an input to the rules engine, not a replacement for it. Rules decide what to do with the score - and rules carry the audit trail. That’s what makes the architecture NAIC-defensible.

The performance math under this architecture, based on the deployments I’ve seen:

• False positive rate: 80%+ legacy rules-only → 25-40% hybrid (60-70% FP reduction)

• Investigation hit rate: 15-25% rules-only → 30-50% hybrid

• SIU cost-to-savings ratio: 4-8× legacy → 8-15× automated hybrid

Anti-pattern to avoid: I want to flag this directly because I see it in vendor pitches. Anyone promising “zero false positives” is selling marketing fiction. The math doesn’t work - every fraud detection system trades FP rate against FN rate, and pushing FP to zero crushes hit rate. The realistic 2026 range mid-market carriers should expect is 25-40% FP with 30-50% hit rate. Anyone quoting better numbers without showing you their FN rate is hiding something.

Why pure AI fails NAIC regulatory audit

I want to walk through a specific failure pattern, because this is where the rules-based foundation question becomes concrete.

A regional health insurer I worked with in 2024 deployed a vendor’s AI fraud model. Beautiful 91% precision in training. Production reality: 87% false positive rate. The investigator team revolted within three months. Audit revealed the AI model had been trained on a biased dataset - geographic skew toward urban claims, underrepresentation of rural provider patterns. The model was confidently wrong in systematic ways.

When the state insurance department auditor asked the carrier to explain the model’s decisioning, the vendor’s answer was “the model said so.” That answer is not survivable. We replaced their black-box model with a hybrid: deterministic rules for known fraud patterns (CPT code mismatch, phantom provider checks, NHCAA watchlist hits), plus an ONNX-deployed XGBoost model for novel patterns, plus SHAP factor attribution for every flag generated. Six months later: FP rate 31%, SIU hit rate doubled to 44%.

Their VP SIU told me afterwards: “AI is only as good as the audit trail you can defend in front of a regulator.”

That’s the failure pattern in a sentence. Pure AI fraud detection in 2026 doesn’t fail because AI is bad - it fails because the NAIC audit format requires line-by-line explainability that ML feature importance rankings don’t satisfy. The fix isn’t to abandon AI. The fix is to put rules underneath it, carrying the audit trail.

The NAIC Model Bulletin on AI made this requirement explicit in 2024. Colorado SB 21-169 raised the bar even higher with algorithmic discrimination testing. By 2026, NAIC examiners ask for the rule, the rule author, and the rule deployment date as standard procedure.

What a NAIC-defensible rules-based architecture actually looks like

Daniel-the-Architect section. This is the technical map I draw on a whiteboard when CCO and General Counsel sit down with the architecture team.

Layer 1 - Rule authoring. A no-code Studio designed for SIU managers, not developers. SIU spots a pattern on Monday, drafts a rule by Tuesday, runs it in test mode against historical claims by Wednesday, deploys to production by Thursday. The IT ticket cycle is gone.

Layer 2 - Rules execution engine. Sub-millisecond execution (Higson runs at 0.23ms per evaluation), sustained throughput of 9 000 requests per second - which translates to 32 million requests per hour during CAT events. Inline-compatible with claims STP path. (Higson product spec)

Layer 3 - ML scoring inline. ONNX runtime deployment inside the rules engine. ONNX matters because it’s the vendor-neutral standard - you can deploy XGBoost, scikit-learn, PyTorch, or TensorFlow models in the same runtime, swap models without re-architecting, and avoid lock-in to any single ML vendor.

Layer 4 - XAI explainability. SHAP factor attribution for every ML-influenced flag. LIME for local explanations on high-stakes denials. The audit log captures which features drove the score, with weights, so the General Counsel has a defensible answer for the NAIC examiner.

Layer 5 - Audit log. Per-flag: rule version, rule author, ML model version, input features, output score, SHAP factor attribution, decision routing path. Every line of that log is what gets shown when a fraud bureau asks “why this claim?”

Layer 6 - External data integration. ISO ClaimSearch, NICB, NHCAA for health, state fraud bureau APIs. The rules engine calls these as enrichment inputs, not as standalone decisions.

Layer 7 - MCP server (unique to Higson). AI agents assist SIU managers in rule authoring via Model Context Protocol. The SIU manager describes a pattern in natural language, the MCP agent drafts the corresponding decision table entry, the SIU manager edits and approves. The agent doesn’t deploy rules - humans do.

Layer 8 - Cross-vertical capability. Same BRMS handles banking transaction fraud rules and insurance claims fraud rules. For multi-line carriers (insurance + banking products), this is what makes the BNP Paribas Cardif pattern work.

Real customer example - BNP Paribas Cardif

Working with BNP Paribas Cardif’s claims team taught me the cross-vertical lesson most carriers learn the hard way.

They had separate claims processing systems for banking products (mortgage life insurance, credit protection) and traditional insurance. Centralizing on Higson took 8 months. The unexpected outcome: their SIU team caught a fraud ring that had been claiming on both banking and insurance products separately for 18 months. The cross-vertical view detected what siloed systems had missed.

The SIU lead told me afterwards: “We were always going to centralize for efficiency. We didn’t expect fraud detection would be the bigger win.”

The architecture that caught the ring was rules-based at its core. The deterministic rules cross-referenced claimant entities across banking claims and insurance claims, flagged identity reuse with different policy contexts, and triggered SIU review. ML scoring layered on top added novel-pattern detection. But the rule that caught the ring was a deterministic cross-vertical entity match - the kind of rule no carrier writes when their systems are siloed, because the data to write it doesn’t exist in one place.

This is the case I anchor every cross-vertical conversation on. It’s public. The pattern is replicable. And the architecture lesson is concrete: rules-based fraud prevention extends naturally across product lines when the BRMS is the shared layer.

Eight criteria for evaluating a rules-based fraud platform

Buying-stage framework for the VP SIU sitting in a procurement decision. These are the criteria I tell carriers to score every vendor on - including Higson.

1. NAIC + state fraud bureau audit trail. Can the platform produce per-flag attribution: rule version, rule author, ML model version, SHAP feature attribution, deployment timestamp? If not, your General Counsel has a problem before procurement closes.

2. Execution latency. Sub-100ms total fraud decisioning required for STP-compatible claims path. Verify with a synthetic-load PoC - not vendor marketing slides. Latency claims at scale are where most platforms underperform their datasheet.

3. Rule velocity. Can a non-developer SIU manager author, test, and deploy a rule in days, not months? This determines whether your platform keeps pace with fraud pattern evolution (Pain F2).

4. ML integration standard. ONNX support means you can deploy any ML framework’s model. Proprietary ML formats lock you into the vendor’s model catalog.

5. False positive rate baseline and tuning. Verify achievable FP rate on your historical claims data, not vendor benchmarks. Honest target: 25-40% FP at 30-50% hit rate. Anyone quoting better wants you to skip the FN rate question.

6. External data integration. ISO ClaimSearch, NICB, NHCAA, state fraud bureau APIs - native integration or roll-your-own? Roll-your-own is a 6-month project per integration.

7. Cross-vertical scalability. If you’re a multi-line carrier with banking products, can the same BRMS handle banking fraud rules and insurance fraud rules? The BNP Paribas Cardif pattern.

8. Mid-market TCO and procurement model. $500M-$5B GWP carriers need procurement options that don’t require enterprise PAS budgets. AWS Marketplace listing with hourly pricing ($0.63/hour PoC tier in Higson’s case) lets you de-risk before committing.

Honest vendor positioning

In my experience, the worst fraud detection conversations start with “we replace X.” The best start with “we integrate with X for this, and we replace Y only when Y is broken.” Here’s the honest map.

Higson is a BRMS - the rules execution and governance layer. We’re the foundation. Where we integrate, where we complement, where we don’t compete:

• Shift Technology, Friss - AI-native fraud platforms. Different category. Carriers integrate Higson as the rules governance layer underneath AI-native pattern discovery. We don’t replace either.

• FICO Falcon, SAS Fraud Framework, NICE Actimize - banking-heritage fraud platforms with insurance modules. Often a fit for large carriers with banking ties. For mid-market cross-vertical carriers, the same Higson BRMS handles both rule sets (the BNP Paribas Cardif pattern).

• Guidewire ClaimCenter, Duck Creek Claims - enterprise PAS suites with embedded claims engines. Higson sits inside the STP path as the production rule engine when the embedded engine isn’t flexible enough or fast enough. We don’t replace the PAS.

I’ll be direct about Higson’s boundaries: we don’t eliminate fraud. With $308 billion in annual US insurance fraud, no platform does. What we do is reduce false positive rates from 80% to 25-40%, push SIU cost-to-savings ratios from 4-8× to 8-15×, and give General Counsel an audit trail that survives NAIC review. That’s the realistic ROI math.

We also don’t fit every carrier. For large enterprise carriers running 50 000+ req/sec at peak, InRule or IBM ODM may fit your scale better. For carriers that have already deployed an AI-native fraud platform and just need the audit trail retrofitted, we’re a foundation layer, not a replacement.

Three myths worth busting

Myth 1: “Rules-based fraud detection is obsolete.” False. By 2026, 90%+ of enterprise and upper mid-market fraud platforms ship hybrid (rules + ML), per Aite-Novarica vendor research. Rules became the foundation, not the relic.

Myth 2: “AI achieves 100% fraud detection accuracy.” False, and a forbidden statement in my book. The FP/FN tradeoff is real math. Realistic mid-market range is 25-40% FP with 30-50% hit rate. Anyone quoting better is hiding their FN rate.

Myth 3: “No-code rule authoring means anyone can write production fraud rules.” False. No-code lowers the technical barrier - SIU managers, not developers, can author rules. But governance is non-negotiable: rules go through test mode against historical claims, peer review, version control, and UAT before production. The platform makes authoring fast. Discipline makes deployment safe.

FAQ

What is rules-based fraud prevention?

Rules-based fraud prevention uses deterministic logic - explicit decision tables, threshold rules, and known-pattern matching - to flag suspicious claims before settlement. Rules execute fast (sub-millisecond on production BRMS), produce explicit audit trails NAIC examiners can review, and let SIU managers author new patterns without IT involvement.

Is rules-based fraud detection obsolete in 2026?

No. By 2026, 90%+ of mid-market and enterprise fraud platforms ship as hybrid rules + ML systems, with rules as the foundation layer. Pure AI fraud detection lost its differentiation pitch after the 2024 NAIC Model Bulletin on AI Systems required documented explainability. Rules-based is now the governance layer most AI fraud platforms bolt on top of.

What’s the difference between rules-based and AI-based fraud detection?

Rules-based fraud detection applies explicit deterministic logic - “if claim amount > $25K AND prior claims in 12 months > 3 AND geographic mismatch, then flag.” AI-based fraud detection uses ML models to score claims based on learned patterns. Rules excel at explainability and known patterns. AI excels at novel patterns and unstructured data. Hybrid architectures combine both, with rules as the audit-trail foundation.

Can rules-based fraud detection pass NAIC compliance audits?

Yes - and it’s the most direct way to pass NAIC audits. The NAIC Anti-Fraud Model Act (48+ US states) and the 2024 NAIC Model Bulletin on AI Systems both require documented decisioning logic. Rules-based systems produce per-flag attribution (rule ID, author, deployment date, version history) that satisfies audit requirements directly. AI-only systems require additional SHAP/LIME explainability layers to meet the same bar.

What is hybrid rules + ML fraud detection?

Hybrid fraud detection combines a deterministic rules engine with ML risk scoring inside the same execution path. Rules handle eligibility filtering, known fraud patterns, and decision routing. ML handles novel-pattern detection and anomaly scoring. The ML score is an input to the rules engine, not a replacement - rules carry the audit trail. This architecture reduces FP rates from 80%+ (legacy rules-only) to 25-40% while maintaining 30-50% investigation hit rates.

How do you reduce false positive rate in rules-based fraud detection?

Three techniques: (1) layer ML anomaly scoring on top of rules to suppress flags on claims that match rules but lack supporting anomaly signal; (2) refine rules using behavioral baselines instead of static thresholds; (3) integrate external data (ISO ClaimSearch, NICB) to cross-validate flags before SIU referral. Modern hybrid architectures achieve 25-40% FP rates - a 60-70% reduction from legacy rules-only systems.

What does NAIC Anti-Fraud Model Act require for fraud detection systems?

The NAIC Anti-Fraud Model Act mandates that insurers maintain an anti-fraud plan including detection, investigation, and reporting capabilities. 48+ US states have adopted versions of the model act. Specific requirements vary by state but commonly include: an active Special Investigations Unit, fraud reporting to state insurance departments, audit trails for fraud decisions, and documented anti-fraud training programs. Modern fraud detection platforms must produce per-decision audit trails that satisfy state fraud bureau review.

Can the same rules engine handle banking and insurance fraud detection?

Yes - for multi-line carriers with both banking products (mortgage life insurance, credit protection) and traditional insurance lines, a shared BRMS can host rules for both verticals. The BNP Paribas Cardif deployment is the public reference case: cross-vertical rule platform caught a fraud ring claiming on both banking and insurance products separately for 18 months, which siloed systems had missed. The shared rules layer enables entity-matching rules across product silos.

Related reading

What is a Business Rules Engine? A 2026 Guide

Insurance Underwriting Automation: Complete Guide  

‍How a Rules Engine Transforms Insurance Fraud Detection in 2026

‍Enhancing Fraud Detection in Banking with Rule-Based Decision Engines

‍Using Business Rules Engines to Support Anti-Fraud in Health Claims Management

‍Higson Business Rules Management System use case

Talk to Higson

If you’re rebuilding fraud detection architecture and the question on the table is “how do we keep what works in rules and add what AI does well without breaking NAIC audit” - that’s the conversation we have weekly with mid-market P&C carriers.

Schedule a 30-minute fraud architecture review - walk through ONNX integration patterns, the BNP Paribas Cardif cross-vertical model, MCP server demo for SIU rule authoring, and a sub-millisecond inline fraud check architecture. Book a slot.

Higson is available on AWS Marketplace at $0.63/hour for proof-of-concept deployments. Start here.