Three jobs, three different regulators
Insurance is the oldest applied-statistics business in America, which makes it an odd place to sell "AI." The math is not new. What is new is the model class, the volume of data feeding it, and the speed at which a decision can be reached about a policyholder without a human reading anything. That last part is what draws regulatory attention. It is also why the same gradient-boosted model can be a routine operations project in one department and a filing-blocking problem three doors down.
Insurance AI work splits cleanly into three jobs, and each answers to a different authority. Claims triage answers to the state unfair claims settlement practices statutes and to your own claims-handling manual. Fraud detection answers to the special investigation unit rules and the state fraud bureau. Underwriting and rating answer to the rate filing itself, to the anti-discrimination statutes, and increasingly to a written governance program the department can demand on 30 days' notice. Catastrophe exposure modeling answers to a commission that may have to approve the model before a single premium reflects it.
Teams get into trouble when they build one system and assume one review. Our engineers scope insurance work by asking which authority will read the output, because that answer sets the architecture. A routing model that never touches a coverage decision can use whatever performs best. A model whose output changes what a consumer pays cannot use anything it cannot explain in a sentence a claims rep could read aloud.
Deployability by use case — value delivered vs. regulatory friction
Editorial weighting from public regulatory sources and practitioner reading — illustrative, not a measured statistic.
Claims triage: the model routes, the adjuster decides
Claims triage is the safest high-value use of machine learning in an insurance operation, for one structural reason: the output changes who looks at a file and how fast, not whether the claim gets paid. A first-notice-of-loss model that predicts ultimate severity, complexity and litigation propensity puts a senior adjuster on the file that will become a six-figure loss and lets a straight-through path handle the glass claim. The gain shows up in cycle time and reserve accuracy, both measurable within a quarter.
The engineering is unglamorous and mostly about data. FNOL text is dictated, misspelled, and full of shop names. Police reports, medical bills and estimates arrive as PDFs of scans. Our teams spend more effort on deterministic extraction and entity resolution across claim, policy and vendor systems than on the predictive model, because a severity model trained on a field three call centers populate differently will learn the call center, not the loss.
Two guardrails keep triage clean. First, write down what the model may not do: close a claim, deny coverage, set a reserve without adjuster confirmation, or push a file past the statutory investigation window in any state. State unfair claims settlement practices statutes, most tracking the NAIC model act, require prompt investigation and prompt communication, so a queue that silently deprioritizes a class of claims can create a violation even though no one denied anything. Second, log the routing decision with its inputs. When a department asks why a claim sat for 40 days, the score, the model version, the features and the human who accepted the routing are the answer.
Fraud signals: a score is a referral, never a finding
Fraud models are where insurers most often confuse a hypothesis with a conclusion. A well-built fraud scorer is a prioritization engine for a special investigation unit. It says that of the 4,000 claims opened this week, these 60 carry combinations of features that historically preceded a confirmed referral. It does not say anyone committed fraud, and no part of the system may treat it as though it did.
That distinction has legal weight. State insurance fraud statutes generally require insurers to report suspected fraud to a state fraud bureau and give them immunity for good-faith reports. They give no cover for delaying or denying a claim on the strength of a score; the disposition has to come from an investigator who examined the file. Build the workflow so the score cannot reach the denial letter, and record the investigator's finding separately from the model output.
On the modeling side the useful signals are relational rather than individual: shared phone numbers and bank accounts across unrelated claimants, repeat provider and repair-shop clusters, staged-accident geometry, timing relative to policy inception, and image forensics on submitted photos. Graph features outperform tabular ones here because organized fraud is a network phenomenon. Set the precision target from SIU capacity, not from an F1 score: if the unit can work 60 referrals a week, tune for the best precision at that volume and report the confusion matrix at that operating point.
Catastrophe exposure: the model is approved before it prices anything
Catastrophe modeling has the longest history of formal regulatory review in insurance analytics, and the Florida precedent is the one to understand. Under Fla. Stat. § 627.0628, the Florida Commission on Hurricane Loss Projection Methodology evaluates hurricane and flood loss models against published standards, and a model must be found acceptable by the Commission before its output can support a residential property rate filing in that state. The review covers meteorology, vulnerability functions, actuarial standards, statistical treatment and computer science practice. It is a model validation regime that predates every current AI framework by decades.
California moved the other direction in late 2024, adopting a rule that allows forward-looking catastrophe models in homeowners rate filings for the first time, paired with a departmental review of the model and conditions tied to writing in wildfire-distressed areas. FEMA's Risk Rating 2.0, in force for the National Flood Insurance Program since October 2021, replaced zone-based flood pricing with a per-structure catastrophe model. The direction is consistent: regulators will accept more sophisticated exposure models, and they will want to see inside them.
For a carrier the work is rarely building a peril model from scratch. It is the accumulation layer around it: cleaning and geocoding exposure data, resolving construction and occupancy attributes that arrive blank on a third of the book, running the vendor model, blending views, and producing portfolio roll-ups that reinsurance brokers and rating agencies accept. Geocoding quality alone moves modeled losses more than most model-choice debates. That is data engineering, and it is where our teams spend the time.
What "model governance" means when an examiner says it
Governance is the word that decides whether a project ships. In insurance it now has specific content, drawn from four sources our teams treat as one checklist.
The NAIC Model Bulletin. Adopted by the NAIC on December 4, 2023 and issued in some form by more than twenty jurisdictions since, the bulletin on insurers' use of artificial intelligence systems expects a written AI Systems Program covering governance, risk management, internal controls, testing for unfair discrimination, and oversight of third-party models and data. It creates no new law: the Unfair Trade Practices Act (Model #880) and the Unfair Claims Settlement Practices Act (Model #900) already prohibit the outcomes regulators worry about. Its operative sentence is that the department may request the program, the model inventory and the testing results during a market conduct examination.
State rules with teeth. Colorado SB 21-169 bars insurers from using external consumer data, algorithms and predictive models that unfairly discriminate on protected characteristics. The Division of Insurance implemented it first through a governance and risk management framework regulation for life insurers effective November 14, 2023, with a follow-on regulation requiring quantitative outcome testing that estimates race and ethnicity by Bayesian Improved First Name Surname Geocoding where the insurer does not collect it. New York DFS Insurance Circular Letter No. 7 (2024), issued July 11, 2024, requires insurers using AI and external consumer data in underwriting and pricing to run quantitative and qualitative disparate-impact analysis, keep the documentation, and remain responsible for a vendor's model as if it were their own.
Bank-style model risk management. Federal Reserve SR 11-7 and OCC Bulletin 2011-12 have been the reference framework since April 2011: a model inventory, risk tiering, independent validation with genuine effective challenge, and ongoing monitoring. Insurers are not subject to it, but insurance groups with bank affiliates and most reinsurers have adopted its structure, and examiners recognize its vocabulary. Writing a validation report in SR 11-7 form is free credibility.
Actuarial standards. ASOP No. 56 (Modeling), effective for work performed on or after October 1, 2020, governs how an actuary may rely on a model built by someone else, what testing is expected and what must be disclosed. ASOP No. 12 covers risk classification, No. 23 data quality, No. 41 communications. If the output enters a rate filing, an actuary signs something about it, and that professional standard becomes your documentation requirement.
| Reviewer | What they read first | What stops the project |
|---|---|---|
| Market conduct examiner | The written AI program, model inventory, complaint file | No inventory; a production model nobody can name an owner for |
| Rate and form analyst | The actuarial memorandum and factor support in the SERFF filing | A factor whose derivation cannot be reproduced from filed exhibits |
| Appointed actuary | Validation report, data quality assessment, ASOP 56 disclosures | Reliance on a vendor model with no testing the actuary can cite |
| Compliance and legal | Adverse-action language, notice triggers, retention schedule | A reason code that does not match what the model actually used |
| Internal audit or validator | Data lineage, change log, monitoring thresholds, challenger results | Training data that cannot be reconstructed as of the scoring date |
| Reinsurer or rating agency | Exposure quality, accumulation method, model blend rationale | Geocoding and construction attributes with unexplained gaps |
Adverse action: the reason code is the deliverable
The moment a model contributes to a decision that makes a consumer worse off, a notice obligation attaches, and the notice is where unexplainable models die.
Under the Fair Credit Reporting Act, 15 U.S.C. § 1681m(a), a person who takes adverse action based in whole or in part on information in a consumer report must tell the consumer, identify the consumer reporting agency by name, address and phone, state that the agency did not make the decision and cannot explain it, and disclose the right to a free file copy within 60 days and the right to dispute. The statute's definition of adverse action at § 1681a(k) is broad for insurance: a denial, a cancellation, an increase in any charge, or any unfavorable change in terms or amount of coverage, existing or applied for. Higher premium counts.
Where credit information drives the decision in personal lines, most states have enacted a version of the NCOIL model act on the use of credit information in personal insurance, which requires the insurer to disclose the reasons for the adverse action, commonly capping the disclosure at four reasons. Those reasons must reflect the actual drivers for that individual, in plain language.
On the lending side of a diversified financial group, the Equal Credit Opportunity Act and Regulation B, 12 CFR 1002.9, require a statement of specific reasons for adverse action on credit. The CFPB addressed model complexity directly in Circular 2022-03, which said creditors cannot avoid the requirement because they use a complex algorithm they do not understand, and again in Circular 2023-03, which said the reasons must be specific and accurate and that picking the nearest entry from a sample-form checklist may not satisfy the rule. Different statutes, same posture: the burden of explanation runs with the decision, not with the technology.
Disparate-impact testing is a build requirement, not a compliance afterthought
Proxy discrimination is the failure mode regulators name most often: a facially neutral variable that reconstructs a protected characteristic. Vehicle make, ZIP-adjacent geographic granularity, occupation codes and shopping-behavior features are all candidates. Where protected status is not collected, testing usually relies on estimation such as BIFSG, which means the estimation method and its error properties become part of the documentation too. Run the test before the model is tuned, not after it is approved.
Why an unexplainable model cannot be deployed in a regulated decision
The argument is often framed as accuracy versus interpretability. In a regulated decision it is not a trade at all, because the explanation is a functional requirement of the output. If the system cannot produce, for this applicant, the ranked reasons that moved the decision, the notice cannot be generated, the filing cannot be supported, and the complaint response cannot be written. The model has failed a requirement, the way an API that returns no status code has failed a requirement.
That does not force everything down to logistic regression. It forces a decision architecture. Three patterns hold up: a constrained model form for anything touching a filed rate, generalized linear or generalized additive with monotonic constraints so each factor's direction can be defended; a more expressive model in a routing layer no consumer-facing decision depends on; and where a boosted model does enter a decision, a locked reason-code method with stability testing, so the same applicant with the same data yields the same reasons on every run.
Two failure modes recur. The first is post-hoc explanation that does not match the model: a SHAP-derived reason list computed against a different feature set than the deployed pipeline, or reasons ranked by global importance rather than by what moved this record. That is a false statement in a regulatory notice. The second is instability, a method that returns different top reasons for the same file on Tuesday than on Monday. Test reason-code stability the way you test accuracy, on a fixed holdout scored repeatedly across refits.
Generative models add one constraint. A large language model is a good tool for reading a claim file, summarizing a medical record or drafting correspondence, and a poor tool for making the decision. Use it for extraction and drafting, write extracted values into fields a human confirms, and keep the decision in a scored model whose behavior can be reproduced. Any LLM output that reaches a customer needs provenance back to a source document.
The documentation set that survives an examination
Nearly every governance regime above asks for the same artifacts under different names. Build them as the project proceeds. Reconstructing them a year later, from notebooks and Slack threads, costs more than writing them the first time and produces a weaker record.
- Model inventory entry with owner, business purpose, risk tier, in-service date, and every downstream decision the output feeds
- Data lineage and a point-in-time training snapshot that can be rebuilt from source systems, with the as-of date for every feature
- Development documentation covering candidate variables considered and rejected, the rationale for exclusions, and the tuning protocol
- Independent validation report in SR 11-7 form: conceptual soundness, outcomes analysis, benchmarking against a challenger, and limitations stated plainly
- Disparate-impact testing results with the estimation method, the metrics chosen, thresholds set in advance, and the remediation record
- Reason-code specification mapping model outputs to the exact notice language, with stability test results
- Monitoring plan with drift thresholds, population-stability triggers, review cadence, and the named person who acts when a threshold trips
- Change log and version register tying every scored decision to the model version that produced it and the approval that released it
- Vendor file for any third-party model or data source: due diligence, contractual audit rights, and the testing you performed yourself
One line carries more weight than the rest. Tying every scored decision to a model version means that when a complaint arrives eighteen months later, the organization can reproduce the exact score, on the exact inputs, from the exact model live that day. Carriers that can do this settle complaints quickly. Carriers that cannot end up explaining their release process to a department instead of explaining one decision.
How we sequence the work
From data access to a decision an examiner can audit
Where the pushback goes next
Three developments are worth tracking. State adoption of the NAIC bulletin keeps widening, and adoption converts a voluntary framework into an examination checklist, so the practical effect arrives with the first exam cycle rather than the adoption notice. The EU AI Act, Regulation (EU) 2024/1689, classifies AI used for risk assessment and pricing in life and health insurance for natural persons as high risk under Annex III, with those obligations applying from 2 August 2026; any carrier with EU operations should have the conformity work scoped already. And the NIST AI Risk Management Framework, released in January 2023, has become the common vocabulary across US regulators, so mapping an internal program to its Govern, Map, Measure and Manage functions answers many questionnaires with one document.
None of this makes insurance a hostile market for machine learning. It makes it a market where governance is part of the build, priced and scheduled alongside the model. The organizations getting real value stopped treating documentation as a tax paid after the fun part and started treating it as the thing that lets the model go live at all.
Bottom line
Put expressive models where they route work and prioritize attention. Put constrained, explainable models where they change what a person pays or receives. Write the reason codes before you tune the model. Test for proxy effects before anyone falls in love with a variable. Keep an inventory, a lineage, a version register and a validation report from the first week, because every reviewer in the chain asks for the same things. Do that and the model ships. Skip it and the model becomes a very good pilot legal will not clear.
Frequently asked questions
Yes, where the decision can still be explained for an individual applicant and the resulting rating factors can be supported in a filing. The constraint is not the algorithm family; it is whether the organization can generate accurate individual reason codes, defend the direction of each variable's effect, and reproduce the decision later. Many carriers use expressive models to select and shape variables, then deploy a constrained form for the decision itself.
Under FCRA § 1681a(k), adverse action in insurance includes a denial, a cancellation, an increase in any charge, or an unfavorable change in terms or amount of coverage, existing or applied for. If information from a consumer report contributed in whole or in part, § 1681m(a) requires notice identifying the reporting agency and disclosing the consumer's rights. State credit-information statutes add a requirement to give the actual reasons, commonly up to four.
It restates existing obligations and sets an expectation about how they will be examined. The underlying prohibitions come from state unfair trade practice and unfair claims settlement practice law. What it adds is the expectation of a written AI systems program, a model inventory, testing records and vendor oversight documentation a department can request during a market conduct examination.
In reading and drafting, not deciding. Extraction from claim files, medical records and policy documents works well when every extracted value carries a citation back to its source page and a human confirms anything consequential. Keep the scored decision in a model whose behavior is reproducible and whose reasons can be stated.
Built alongside development, it adds roughly four to seven weeks across validation, testing and the governance package on a first model, and much less afterward once the templates exist. Reconstructed later it takes longer and produces a weaker record, because point-in-time training data and rejected-variable rationale are the first things to become unrecoverable.