Machine Learning Problems in Insurance and Banking: Why Governance Beats the Model (2026)

When the CIO blocks the ML model: ML governance as the BRMS conversation

Last quarter I sat in on a CIO conversation at a $1.9B GWP P&C carrier in the Mid-Atlantic. The data science team had built an XGBoost model for underwriting risk scoring. The model showed 11% lift on loss-ratio prediction in offline validation. The data scientists wanted to deploy. The CIO blocked it - not because the model was bad, but because nobody could answer the question the Chief Underwriting Officer asked next: "When this model declines an applicant and they call the New York Department of Insurance, what do we tell the regulator about why we declined?"

In my experience, this is the most common pattern blocking ML adoption in mid-market insurance and banking in 2026. The model works. The data is good. The infrastructure runs. What stops production deployment is governance - specifically, the inability to explain individual decisions to regulators in terms the NAIC Model Bulletin on AI Use in Insurance accepts. The CIO is not anti-AI; the CIO has read the bulletin and knows that the model risk management framework regulators expect requires more than "our model is accurate."

This article covers the common machine learning problems mid-market insurance carriers and banks face in 2026 - and the governance pattern (BRMS as guardrail around ML) that lets you deploy ML without the CIO-block scenario. I cover the regulatory landscape that has tightened since 2024, the seven categories of ML problems that surface in production, the hybrid pattern that fixes most of them, and where Higson's ONNX integration and audit trail fit. The framing is Daniel-architect and Sarah-CTO at mid-market $500M-$5B GWP carriers and $1B-$20B AUM banks who have data science teams producing models and CIOs blocking deployment.

Skip to Section 5 if you want the BRMS-as-guardrail pattern (the user-note angle); Section 6 for the hybrid architecture with concrete code; Section 7 for the explainability framework. Section 4 covers the NAIC Bulletin and state-level AI regulations that mid-market carriers should treat as binding.

Honest disclosure: Higson is the BRMS my team builds, and we have specific differentiators in the ML governance space (native ONNX runtime, audit-trailed rule + model evaluation). I cover the governance pattern accurately whether or not your team uses Higson; the pattern matters more than the vendor.

What are the common problems with machine learning in insurance and banking?

The most common machine learning problems in 2026 insurance and banking deployments are governance and explainability problems rather than technical model problems. Seven categories surface repeatedly:

(1) regulatory explainability gap - NAIC Model Bulletin on AI Use in Insurance requires decision-level rationale that black-box models cannot provide;

(2) audit trail gap - ML models log inputs and outputs but not the rule-equivalent reasoning auditors expect;

(3) data quality - mid-market carriers have 5-10 years of historical data which is borderline for fraud and rare-event models;

(4) drift detection - production model performance degrades when underlying patterns shift;

(5) talent scarcity - production ML requires data scientist + ML engineer + MLOps engineer trio that mid-market carriers cannot always staff;

(6) integration complexity - ML models sit outside the BRMS rule library so changes are not coordinated;

(7) deployment timeline - prototype-to-production takes 6-18 months at mid-market scale.

The fix is not avoiding ML - it is the hybrid pattern where a BRMS provides the regulatory-compliant guardrail around ML inference, with rules and model running in a single audit trail. Higson with native ONNX runtime implements this pattern at 0.23 ms P50 execution.

Seven machine learning problems mid-market carriers face in 2026

Honest catalog of the ML problems I see consistently in mid-market insurance and banking. In my experience, these are not theoretical concerns from MLOps blog posts; they are the issues that surface in actual production deployments and CIO governance reviews. I recommend treating the seven categories below as a diagnostic checklist before any ML project crosses from prototype to production.

Problem 1: Regulatory explainability gap

The NAIC Model Bulletin on AI Use in Insurance (adopted December 2023, updated 2024-2025) requires that insurers deploying AI/ML systems maintain documentation of decision rationale that supports regulatory examination. State Departments of Insurance increasingly request this documentation during market conduct examinations. Black-box models (deep neural networks, complex ensemble methods) struggle here - the model output is a probability score, not an explanation of why the score is what it is. Mid-market carriers without an explainability framework around ML models face state DOI examination findings that delay or block deployment.

Problem 2: Audit trail gap

ML models naturally log inputs and outputs - input feature vector goes in, prediction comes out. What regulators ask for during examinations is the rule-equivalent reasoning: which rule fired, what threshold triggered, what version of the model was current at the time of decision. ML inference alone does not produce this artifact; it has to be added through governance tooling. The Pega Decision Hub and FICO Blaze Advisor enterprise platforms include this; most mid-market deployments of XGBoost or PyTorch models do not, until governance becomes the deployment blocker.

Problem 3: Data quality and quantity

Mid-market carriers typically have 5-10 years of policy and claims data. For most underwriting and pricing decisions, that is sufficient. For fraud detection and rare-event prediction, it is often borderline - frequency of fraud labels in mid-market portfolios is low enough that supervised learning struggles. Carriers with strong actuarial teams can supplement with synthetic data and transfer learning from larger industry datasets; carriers without that capability either deploy weaker models or skip ML for the use case entirely. Data quality compounds the issue - inconsistent labeling, missing fields, and changing business definitions in legacy systems produce ML inputs that look clean in tooling but degrade model performance in production.

Problem 4: Drift detection and model degradation

Production ML models degrade as the underlying patterns shift. Pandemic-era claims patterns invalidated fraud models trained on 2018-2019 data; post-pandemic patterns invalidate the pandemic-era retraining. Carriers running ML in production need drift-detection infrastructure (statistical tests comparing live data distribution to training distribution) plus retraining workflows that retain regulatory approval. Mid-market carriers without an ML platform vendor (Databricks, AWS SageMaker, Azure ML) struggle here; rolling drift detection from scratch is a multi-month engineering effort.

Problem 5: Talent scarcity

Production ML requires three roles that mid-market carriers cannot always staff at scale: data scientist (model development), ML engineer (production deployment), and MLOps engineer (drift monitoring, retraining, governance integration). Fully loaded compensation for the trio runs $600K-$1.2M/year in major US markets. Carriers with established data science teams have the first two roles but rarely the MLOps function until they hit a production incident that exposes the gap. Outsourcing to consulting partners works for project-stage ML; it does not work for production operations long-term.

Problem 6: Integration complexity with existing decision systems

Mid-market carriers have existing decision systems - typically a BRMS or hardcoded rules - that need to coordinate with new ML models. The integration pattern matters: ML model serving in one infrastructure, rules engine in another, calling service in a third, no single audit boundary. When a fraud claim flag fires, the audit question is: did the BRMS trigger this, did the ML model trigger this, did both, and what was the order? Without explicit hybrid architecture (covered in Section 6), this integration creates more governance gaps than ML alone.

Problem 7: Prototype-to-production timeline

Gartner research has historically reported that 47-53% of ML projects make it from prototype to production. In mid-market insurance and banking, that timeline runs 6-18 months at minimum - the long pole is rarely model development (4-8 weeks typical) but rather governance integration, regulatory review, integration testing, and IT operations onboarding. Carriers that prepare governance infrastructure first (decisions on auditability, explainability, drift detection) accelerate subsequent ML deployments significantly; carriers that build the model first and figure out governance second invariably miss timeline.

The 2026 regulatory landscape: NAIC Bulletin, state DOIs, and what they actually require

The regulatory environment around AI/ML in insurance and banking has shifted significantly since 2024. In my experience, three changes matter most for mid-market deployments.

NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers

Adopted by the NAIC in December 2023 and updated through 2024-2025. The bulletin establishes that insurers must maintain a written AI Systems Program governing the development, acquisition, deployment, and oversight of AI systems. Key requirements that affect mid-market deployments:

• Documentation of all AI/ML systems used in adverse consumer decisions (declinations, rate increases, claims denials)

• Risk assessment for each AI system covering bias, accuracy, drift, and operational risk

• Decision-level explainability: ability to provide consumer rationale for individual decisions on request

• Vendor due diligence requirements for AI systems sourced from third parties

• Records retention for AI model versions, training data lineage, and decision outputs

• Reporting obligations during state DOI market conduct examinations

As of May 2026, 30+ state Departments of Insurance have adopted the NAIC Bulletin or substantially similar requirements - including New York DFS, California DOI, Colorado DOI (which had pre-existing AI fairness regulation), Connecticut, New Jersey, and Texas. Carriers operating in multiple states face a patchwork that converges on the NAIC framework even when the specific state version differs in detail.

Colorado SB 21-169 (Insurance Practices That Unfairly Discriminate Based on External Consumer Data)

Pre-existing Colorado regulation requires insurers using external consumer data in ML pricing or underwriting to demonstrate that the data does not produce unfair discrimination. Implementation rules (effective 2024-2025) require carriers to test ML models for differential treatment across protected classes and document the testing methodology. This is more prescriptive than the NAIC Bulletin on bias testing and serves as a leading indicator for other state regulations.

NIST AI Risk Management Framework (AI RMF 1.0)

Federal non-binding framework released January 2023, increasingly referenced as the de-facto standard during state examinations. The framework's GOVERN-MAP-MEASURE-MANAGE structure provides a defensible governance model that satisfies both NAIC and most state-specific requirements. Mid-market carriers without an internal AI governance framework can adopt AI RMF as the baseline and customize state-specific requirements on top of it.

Practical implication for mid-market deployments: the era of "deploy the model first, figure out governance later" is over. State DOI examinations now ask the governance questions during routine market conduct reviews, not just during incident response. Carriers without explainable decision artifacts face examination findings that delay subsequent product launches. I recommend treating NAIC Bulletin compliance as a deployment gate rather than a post-deployment checklist.

BRMS as ML guardrail: the pattern that fixes the governance gap

The architectural pattern that resolves most ML governance gaps in mid-market insurance and banking is what I call BRMS as guardrail. The Business Rules Management System wraps the ML model, providing the regulatory-compliant audit trail and decision-level explainability the model alone cannot. The model contributes probabilistic scoring; the rules engine contributes deterministic reasoning, hard constraints, and the audit artifact regulators ask for.

How the guardrail pattern works

Three architectural elements work together:

1. Deterministic rules in the BRMS handle hard constraints - eligibility rules, regulatory floors and ceilings, state-specific restrictions. These rules are authored by business analysts in decision tables, version-stamped with author and rationale, and audit-logged on every execution. NAIC Bulletin explainability is satisfied by the rule definitions themselves.

2. ML model contributes probabilistic scoring - fraud probability, loss-ratio prediction, customer lifetime value estimate. The model produces a score; the score is one input among many that feed into the rule evaluation.

3. Rules orchestrate the combined decision - if the deterministic eligibility rules approve AND the ML score exceeds an explicit threshold, the decision is X; if either fails, the decision is Y. The thresholds are rule artifacts (authored, versioned, audit-trailed); the model score is one input variable. The final decision is explainable in terms of the rules that fired, with the model score as one named input.

Why this fixes the governance gap

The regulator question becomes answerable. When the New York DFS examiner asks "why did you decline this applicant," the response is "the underwriting eligibility rule R-247 declined because the deterministic rule for prior-claims-in-36-months exceeded threshold, AND because the fraud probability score from model FP-v3.2 exceeded the 0.85 referral threshold defined in rule R-892, both rule versions are active as of the decision timestamp." That answer is auditable in a way that "the XGBoost model produced a high-risk score" is not.

The pattern also fixes the audit trail gap (Problem 2). The BRMS logs every decision with rule version, input values, model score (treated as a named input), and final outcome. Regulators get a single auditable artifact rather than a stitched-together story from model serving logs, rule execution logs, and application logs.

Notus Finance implemented exactly this pattern with Higson - deterministic commission calculation rules in Higson Studio, with an ML model for tier-eligibility scoring called from inside the rule evaluation. The audit trail covers both the rule logic and the ML score in a single record per decision. State examinations of Notus' commission practices have been straightforward because the audit artifact is one document per decision rather than three.

Hybrid architecture: ONNX models inside Higson rules

Concrete implementation of the guardrail pattern. Higson supports ONNX runtime natively - decision tables can reference ONNX models trained in PyTorch, TensorFlow, or scikit-learn, and the model inference runs inside the same Higson runtime call that evaluates the surrounding rules. The result is a single audit trail covering both rule logic and ML score.

Architecture pattern

Data scientists train models in PyTorch or TensorFlow using their preferred MLOps tooling (Databricks, SageMaker, MLflow, Vertex AI). When ready for production, the model is exported to ONNX format - a standardized open format that Higson runtime can load. Linda the BA authors the surrounding rule logic in Higson Studio, references the ONNX model by name in a decision table cell, and the model is invoked inline during rule evaluation.

Example: insurance fraud triage with hybrid scoring

A property claim fraud triage decision typically combines deterministic heuristics (was the claim filed within 30 days of policy inception, prior carrier history, attorney representation flag) with probabilistic ML scoring (fraud probability from features over 30+ claim attributes). The hybrid pattern in Higson:

// Higson rule referencing an ONNX fraud model 
rule "property-fraud-triage": 
  inputs: 
    claim: 
      filedDaysSincePolicyStart 
      priorCarrierClaimCount 
      attorneyRepresented 
      claimAmount 
      // ... 30+ features 
 
  // Call ONNX fraud model (data scientist trained, exported) 
  let fraudScore = onnx_model( 
    model: "fraud-v3.onnx", 
    features: claim 
  ) 
 
  // Combine deterministic rules with ML probability 
  if filedDaysSincePolicyStart < 30 AND fraudScore > 0.7 
     OR fraudScore > 0.9 
     OR (attorneyRepresented AND fraudScore > 0.6) 
  then 
     route_to: SIU 
     audit_reason: "high fraud score with risk indicators" 
  else if fraudScore > 0.4 
  then 
     route_to: adjuster_l2 
     audit_reason: "moderate fraud score, secondary review" 
  else 
     route_to: STP 
     audit_reason: "low fraud score, straight-through processing"

What the audit trail records

Every execution of this rule produces a single audit record containing the rule version (R-property-fraud-triage v2026.05.14), the inputs (all 30+ claim features), the ONNX model version (fraud-v3.onnx with cryptographic hash), the model score (e.g., 0.84), which branch of the rule fired (the SIU branch), the human-readable audit_reason, and the timestamp. When a state DOI examiner asks why a specific claim was routed to SIU, the response is the audit record - one document, fully explainable, defensible against examination.

The ONNX format matters because it is vendor-neutral and supports model lineage. The same ONNX file can run in Higson, in TensorFlow Serving, in ONNX Runtime standalone, or in Azure ML. Carriers retain portability over their ML investment while gaining the BRMS audit trail wrapper. This pattern works with Higson because ONNX runtime is native; it works with Drools via custom integration code (more engineering effort) and is harder to implement with vendors that have not built ONNX integration into the BRMS runtime.

Explainability: SHAP, LIME, and decision-level rationale

The NAIC Bulletin's decision-level explainability requirement is the regulatory hook for explainable AI (XAI) tooling. Three approaches matter for mid-market carriers.

SHAP (SHapley Additive exPlanations)

Game-theoretic framework for feature attribution. For any individual decision, SHAP produces feature-level contribution values - this claim was scored 0.84 fraud probability, with prior-carrier-claims contributing +0.31, attorney-flag +0.18, claim-amount-vs-average +0.15, days-since-policy-start +0.11, all other features summing to +0.09. SHAP is well-supported in Python ML stacks (shap library) and produces explanations that satisfy NAIC Bulletin requirements when documented in the BRMS audit trail. The compute cost is modest at inference time (5-15 ms per decision for typical mid-market feature counts).

LIME (Local Interpretable Model-agnostic Explanations)

Approximates the model's behavior near a specific prediction with a simpler interpretable model. Useful when SHAP compute cost is excessive or when the model architecture makes SHAP impractical. LIME produces decision-level explanations that approximate but do not exactly match SHAP's feature attribution; for regulatory purposes either approach satisfies the Bulletin's explainability requirement if documented consistently.

Integration with BRMS audit trail

In my experience, the practical pattern is: data scientists compute SHAP or LIME values at model training time, the BRMS rule references the model output AND the feature attribution explanation, and the audit log captures both. The explanation is regulator-readable because it lists named features in plain language ("prior-carrier-claims = 4 contributed +0.31 to fraud probability") rather than tensor weights. The BRMS rule then translates the explanation into business-rule reasoning ("4 prior claims in 36 months triggered referral threshold per rule R-892"). The combined audit record is what regulators see.

Higson supports this integration pattern via custom decision-table columns that capture SHAP feature attributions alongside the model score. The data scientist owns the model and the SHAP computation; Linda the BA authors the decision-table rule that combines model score, feature attribution, and business logic into the final decision and audit record.

Decision framework: rules, ML, or hybrid?

The framework I run with carriers in early ML evaluation conversations. Five questions; first three identify the right architecture pattern, last two clarify implementation.

1. ‍Is the decision rule-expressible with clear conditions and outcomes? If yes for the entire decision, use a BRMS without ML - the regulatory and operational overhead of ML does not pay back when deterministic rules answer the question. Most underwriting eligibility, premium rating, and claims routing falls here.
2. ‍Does the decision require probabilistic scoring or pattern detection that rules cannot capture? Fraud detection, customer lifetime value, loss-cost prediction, marketing next-best-action. If yes, ML adds value - and you need the hybrid pattern from Section 5 to maintain governance compliance. ‍
3. Are you in a regulated industry with decision-level explainability requirements? Insurance (NAIC), banking (FCRA), healthcare (HIPAA / ADA), employment (EEOC). If yes, pure ML is not viable - the hybrid pattern is the only path to production for adverse consumer decisions. ‍
4. Do you have the MLOps capability to operate production ML responsibly? Data scientist + ML engineer + MLOps engineer trio (or vendor MLOps platform). If no, start with rules-only and add ML only when the operational capability matures. Deploying ML without MLOps creates production incidents that erode CIO trust and delay subsequent AI initiatives. ‍
5. Is the model's lift over rules-alone material? An ML model that adds 2% accuracy improvement over a rules-based baseline rarely justifies the governance overhead; a model that adds 15-25% lift on fraud detection or 10-15% on loss-ratio prediction usually does. Measure before deploying.

In my experience, mid-market insurance carriers land on the hybrid pattern (BRMS as guardrail with ML for specific scoring) for about 15-25% of operational decisions, pure BRMS for 75-85%, and pure ML for very few production use cases. Carriers that try to deploy more ML than this hit the governance wall described in Section 1.

Where the BRMS-as-guardrail pattern does not solve the problem

I would rather lose a deal than win one badly. Three scenarios where the hybrid pattern is not the right answer:

• Pure ML decisions where rules add no value. Real-time bidding, ad-tech click-through prediction, content recommendation at scale - these are ML-native problems where the rule layer is minimal. A model-serving platform (TensorFlow Serving, MLflow, BentoML) fits better than a BRMS for these use cases. Rare in insurance and banking; real in adjacent industries.

• ML models that cannot be made explainable. Some deep learning architectures (transformer-based, large vision models) genuinely resist SHAP/LIME explanation at the granularity regulators expect. If the model architecture makes explainability impossible and the use case requires regulatory-grade rationale, the model is not deployable - regardless of BRMS guardrail. The right answer is often a simpler model architecture that retains explainability.

• Carriers without data science teams. If you do not have a data science team capable of training, validating, and maintaining production ML, the BRMS-as-guardrail pattern does not magically create that capability. Start with rules-only and build data science capability before adding ML. The hybrid pattern earns its complexity when ML genuinely adds value over rules; it does not justify adding ML for ML's sake.

Within mid-market insurance and banking with mature MLOps capability and regulatory-grade explainability requirements, the BRMS-as-guardrail pattern resolves most production-blocking governance issues. Outside that profile, an honest evaluation acknowledges where the pattern runs out of road.

‍

FAQ

What are the common problems with machine learning in insurance and banking?

Seven categories surface repeatedly in mid-market production deployments: (1) regulatory explainability gap - NAIC Bulletin requires decision-level rationale black-box models cannot provide; (2) audit trail gap - ML logs inputs/outputs but not rule-equivalent reasoning; (3) data quality and quantity for rare events; (4) drift detection as patterns shift; (5) talent scarcity - data scientist + ML engineer + MLOps trio; (6) integration complexity with existing rule systems; (7) prototype-to-production timeline of 6-18 months. Most problems are governance and integration problems rather than technical model problems.

What is the NAIC Model Bulletin on AI Use in Insurance?

NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted December 2023 and updated 2024-2025. Requires insurers to maintain a written AI Systems Program covering AI development, acquisition, deployment, and oversight. Key requirements: documentation of AI systems used in adverse consumer decisions, risk assessment per system, decision-level explainability, vendor due diligence, records retention, examination reporting. As of May 2026, 30+ state DOIs have adopted the bulletin or substantially similar requirements.

What is the BRMS as ML guardrail pattern?

Architectural pattern where the Business Rules Management System wraps ML model inference, providing the regulatory-compliant audit trail and decision-level explainability the model alone cannot. Three elements: deterministic rules in BRMS handle hard constraints (eligibility, regulatory floors, state restrictions); ML model contributes probabilistic scoring (fraud probability, risk score); rules orchestrate the combined decision with thresholds as rule artifacts and model score as one named input. The final decision is explainable in terms of rules that fired with ML score as input variable, satisfying NAIC Bulletin requirements.

How do you make a machine learning model auditable for regulators?

Four practical steps: (1) wrap ML inference in BRMS rules so the audit log is the BRMS audit log, with rule version + model version + inputs + score + outcome in one record; (2) compute SHAP or LIME feature attributions at inference time to produce decision-level explainability; (3) document model lineage (training data, training methodology, validation metrics, version history) in a model registry accessible during examinations; (4) treat ML model versions as deployable artifacts that go through the same change-management process as application code, with regulatory sign-off where required.

What is ONNX and how does it help with ML governance?

ONNX (Open Neural Network Exchange) is a standardized open format for ML models that lets you train in one framework (PyTorch, TensorFlow, scikit-learn) and run in another runtime (ONNX Runtime, Higson, TensorFlow Serving, Azure ML). For ML governance, ONNX matters because: (1) the format is vendor-neutral - models are portable across runtimes, reducing vendor lock-in; (2) model lineage is preserved with cryptographic hashes for audit trail; (3) ML governance tools can verify the production model matches the validated training artifact; (4) Higson's native ONNX runtime lets data scientists train in their preferred framework and serve through BRMS guardrail without conversion.

What is SHAP and how does it help with regulatory compliance?

SHAP (SHapley Additive exPlanations) is a game-theoretic framework for ML feature attribution. For any individual decision, SHAP produces named feature contribution values that explain why the model produced its prediction. Example: this claim scored 0.84 fraud probability with prior-carrier-claims contributing +0.31, attorney-flag +0.18, claim-amount-vs-average +0.15. SHAP satisfies NAIC Bulletin decision-level explainability requirements when feature attributions are documented in the BRMS audit trail alongside the rule logic. The compute cost is modest (5-15 ms per decision) for typical mid-market feature counts.

Can a rules engine handle machine learning?

Modern BRMS handle ML integration through ONNX runtime (Higson native), model serving callouts (FICO Blaze, IBM ODM), or custom integration code (Drools, Camunda). Higson supports ML model invocation directly inside decision tables - a rule can reference an ONNX model by name, the model inference runs inline during rule evaluation, and the audit trail captures both the rule logic and the model score in a single record. This is the hybrid pattern that satisfies regulatory explainability requirements while preserving ML's pattern-detection capabilities.

When should you NOT use machine learning?

Three scenarios where ML is not the right choice: (1) when the decision can be expressed as deterministic rules - regulatory overhead and model maintenance cost do not pay back when rules already answer the question; (2) when you do not have a production-capable MLOps team - data scientist alone cannot operate production ML; (3) when the model's lift over rules-alone is immaterial (under 5% accuracy improvement). Most mid-market insurance operational decisions fit category 1 - underwriting eligibility, premium rating, claims routing, compliance disclosures. ML adds value selectively for fraud detection, risk scoring, and pattern-detection use cases where pure rules cannot capture the signal.

‍

Related reading

• What is a Rules Engine? Complete Guide for Insurance 2026 - the BRMS primer including AI/ML context.

• Business Rules Engine vs Decision Engine - terminology and category disambiguation including AI/hybrid patterns.

• Decoupling Decisions: BRMS in Microservices Architecture - integration patterns including ML adapter.

• Java Rules Engines: Drools, Easy Rules, Higson SDK Compared - ONNX integration code examples.

• Rules Engine Scalability - performance considerations for hybrid rule + ML pipelines

• Common Business Rules Examples - rule types BRMS handles in the hybrid pattern.

• Business Rules Engine Comparison 2026 - vendor landscape including ONNX support.

• Insurance Premium Calculation - ML pricing factors with rule-based regulatory floors.

• Simplifying Insurance Claims Management with Rules Engines - hybrid claims fraud triage.

‍

Talk to Higson

ML governance is where most mid-market insurance carriers and banks discover that the prototype-to-production gap is regulatory rather than technical. The data science team builds a working model; the CIO blocks deployment because the audit trail and decision-level explainability are not where they need to be. The BRMS-as-guardrail pattern resolves most of this - rules contribute the deterministic logic and audit artifact, ML contributes the probabilistic scoring, the combined decision is explainable in terms regulators accept.

Higson is built for mid-market insurance carriers $500M-$5B GWP, mid-market banks $1B-$20B AUM, and mid-size healthcare payers running ML alongside deterministic rules. The native ONNX runtime is one of the few mid-market BRMS implementations that supports hybrid patterns without custom integration code. We are not the right answer for pure ML decision systems (TensorFlow Serving, MLflow fit better), enterprise-tier ML governance with custom risk management framework requirements (FICO and IBM ODM have deeper enterprise tooling), or carriers without data science teams (start with rules-only first). Where we do fit, the hybrid pattern moves from PoC to production in 3-6 months with single-audit-record governance.

If you would like to see the BRMS-as-guardrail pattern in action - Higson decision tables calling an ONNX model with single audit trail - I would be happy to walk through it with your architect and data science teams.

Three ways to start:

• Try Higson on AWS Marketplace at $0.63 / hour - 15 minutes from subscription to first hybrid rule + ONNX model evaluation. Sample insurance fraud triage included.

• Schedule a 30-minute ML governance review - we will walk through your specific ML deployment, governance requirements, and the BRMS-as-guardrail pattern for your environment.

• Download the BRE Comparison Guide - vendors compared on ONNX support, audit trail capabilities, and ML governance integration.

Citations

1. NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (December 2023, updated 2024-2025) - primary regulatory framework for AI/ML in US insurance.
2. NIST AI Risk Management Framework (AI RMF 1.0, January 2023) - federal non-binding framework that serves as de-facto baseline.
3. Colorado SB 21-169 (Insurance Practices That Unfairly Discriminate Based on External Consumer Data) - pre-existing state regulation on AI fairness in insurance pricing.
4. Gartner research on AI/ML project deployment rates (historical 47-53% prototype-to-production).
5. ONNX Runtime documentation - the ML integration standard for hybrid BRMS patterns.
6. Lundberg & Lee, "A Unified Approach to Interpreting Model Predictions" (NeurIPS 2017) - foundational SHAP paper.
7. Ribeiro, Singh & Guestrin, "Why Should I Trust You? Explaining the Predictions of Any Classifier" (KDD 2016) - foundational LIME paper.
8. OMG Decision Model and Notation (DMN) Specification - the standard most BRMS implement for decision tables.
9. Notus Finance / Higson case study (hybrid commission calculation with ML tier-eligibility scoring)