Claims severity, litigation propensity & loss-reserving prediction

Once a loss is reported, the insurer must decide how much to reserve, who should handle the claim and whether it will escalate into litigation. Machine learning on claim attributes, development history and adjuster notes scores every claim early, so simple claims are fast-tracked and complex or litigation-prone claims reach senior handlers sooner. At portfolio level, ML complements classical triangle methods for IBNR and ultimate-loss estimates. Humans, in particular claims handlers and the actuarial function, stay accountable for reserves and decisions.

Problem & value

• Today: case reserves are set by individual adjusters from experience and guidelines; routing rules are static; litigation is often recognised only after an attorney is already involved. Portfolio reserves are derived by actuaries with triangle methods (chain-ladder, Bornhuetter-Ferguson, GLMs) and judgement.
• AI value: earlier and more consistent signals on severity, litigation and large-loss development; better workload allocation; challenger estimates for reserving; more granular reserving on claim level instead of aggregated triangles only.
• Evidence: vendors such as CLARA Analytics position claim triage and litigation products for early identification of costly or attorney-involved claims [1]; their public pages give few audited numbers, so expect to measure the benefit on your own back-test data. Treat any published vendor improvement figure as marketing until reproduced on your data.
• Reporting context: IFRS 17 governs measurement of insurance contract liabilities for IFRS reporters [2]; Solvency II technical provisions apply to EU insurers; the CRAN ChainLadder package documents standard methods including the Solvency II claims development result [3]. Better ultimate-loss estimates feed both.

Variants

• Claim-level severity and triage (FNOL): classification and regression at first notice of loss; motor, property, liability, workers' compensation, health.
• Litigation / attorney-involvement propensity: especially relevant in liability and bodily-injury lines; in Germany and most EU markets litigation rates are structurally lower than in the US, so the target may instead be "dispute escalation" or "ombudsman complaint".
• Large-loss and reserve-development early warning: re-scoring open claims at each event to flag adverse development.
• Subrogation and recovery potential: a related target on the same data.
• Portfolio ML reserving: claim-level (micro) models, neural or gradient-boosted development models, Bayesian triangles with uncertainty, used as challengers to chain-ladder.
• Corporate self-insured / captives and TPAs: same models on fewer claims; typically bought as a service.
• Private use: not applicable.

How it works

1. claims system (FNOL, payments, notes, status events)
2. data prep (claim-level history snapshots, as-of dates, text cleaning, leakage control)
3. feature building (structured features + embeddings of notes + external indices)
4. models (severity regression / quantile models, litigation classifier, development model)
5. calibration + explanation (SHAP, reason codes) + uncertainty intervals
6. scoring service (at FNOL and at each claim event)
7. handler workbench: triage, reserve suggestion, alerts [human decision]
8. portfolio aggregation
9. actuarial reserving review [actuary decision]
10. monitoring: back-testing against actual settlement, drift, fairness checks

• Core models: gradient boosting (XGBoost, LightGBM, CatBoost) remains the workhorse on tabular claim data; XGBoost is open source under Apache-2.0 [4]. Tabular foundation models such as TabPFN can help on small claim sets, but check the licence: the current TabPFN weights are non-commercial, with a commercial enterprise edition [5].
• Heavy-tailed targets: model severity with Gamma/Tweedie or quantile objectives, splice a tail model for large losses, and report intervals rather than a single number.
• Text: adjuster notes and reports are turned into features via embeddings or classifiers; LLMs summarise notes and extract structured facts (injury type, liability indications). Do not let an LLM set the reserve itself.
• Time handling: training rows must be snapshots "as known at date t"; otherwise label leakage inflates accuracy.
• Human-in-the-loop: suggestions go to the handler; reserves and settlements are signed off by the claims and actuarial functions.

Data preparation

The core data are claim master records, payment and reserve histories, status events and adjuster notes. They typically live in the claims or policy administration system, in a data warehouse for the actuarial team, in the DMS (medical and expert reports as PDF or scans), and in mail. Reserving triangles are often maintained in Excel.

Typical gaps: free-text notes without structure, scanned reports, changed coding schemes across years, duplicate claimants, missing litigation flags, and history that only stores the current status instead of snapshots "as known at date t". Without snapshots, label leakage inflates accuracy.

Preparation steps: (1) inventory sources and owners (PREP-001, PREP-004); (2) export claim histories via APIs or ETL (PREP-005); (3) OCR and text extraction for reports (PREP-006, DOC-014); (4) build as-of snapshots and harmonise codes; (5) harvest labels (final cost, attorney involvement) from closed claims (PREP-020); (6) pseudonymise claimants for model development (PREP-022); (7) create a hold-out and back-testing set with claims experts (PREP-018). Tools: SQL/dbt, Python (pandas), Paperless-ngx or an OCR service, a feature store if volumes justify it.

Rough share of effort: 50 to 60 percent of the project, mostly leakage control and history reconstruction. See also GUIDE-003.

Implementation paths

Which path for whom

• SMB (small insurers, MGAs, TPAs): Path A, because mature claims-analytics modules from core-system and insurtech vendors exist and a small portfolio rarely justifies an own data-science team.
• Enterprise: Path B, because claims scoring and reserving are core processes where own history is the competitive asset and models must be tuned to the own portfolio and governed by the actuarial function.
• Developer: Path C, because gradient-boosting stacks (XGBoost, LightGBM) and open-weight embedding models run on modest hardware and give full control over leakage handling and back-testing.

Path A — Buy

• Claims analytics vendors: CLARA Analytics (triage, litigation) [1], Gradient AI (P&C and health claims/underwriting analytics) [6], plus ML modules of claims core systems (Guidewire, Duck Creek, Sapiens) and analytics vendors such as Shift Technology (EU, France; strongest in fraud, see ANOM-003).
• Reserving software: Milliman Arius, Willis Towers Watson ResQ, and R/Python tooling; Akur8 (EU, France) is focused on pricing (PRED-010).
• Choose A when: you want proven workflows, have limited data-science staff and your claim volume is modest. Verify EU hosting, model transparency, ability to back-test on your own history and AI Act roles (provider vs. deployer).

Path B — Build on cloud APIs

• ML platform: Azure ML, Google Vertex AI, AWS SageMaker (EU regions), Databricks or Snowflake for claim data; train boosting models on managed compute.
• LLM layer: a frontier or EU-hosted LLM (e.g. Mistral, Claude, Gemini or GPT via EU regions) for note summarisation, extraction of injury/liability facts and reason-code explanations; embed the notes for features.
• Integration: score via REST into the claims system; write suggestions to a task queue.
• Choose B when: you have a data-science team and want control of features and targets without owning GPUs; note that numeric models rarely need LLMs at all.

Path C — Self-host (open source)

• Stack: Python with XGBoost / LightGBM / CatBoost, scikit-learn, statsmodels, SHAP; R ChainLadder for triangle methods [3]; MLflow for model registry; PostgreSQL / parquet feature store.
• Text: open embedding models and a small open LLM (e.g. Qwen, Mistral, Llama class) via vLLM or Ollama for note extraction.
• Hardware: the numeric models run on CPU servers (HW1); only the optional LLM note-processing needs a GPU (HW2). Most insurers already require on-prem or sovereign hosting for claim data, so Path C is realistic and cheap in hardware.
• Ops effort: MLOps, data engineering from legacy claims systems and model governance dominate, not compute.

Path D — Custom training

This is the default path for large insurers: models are trained on the insurer's own claim history (typically years of closed claims with development snapshots; thousands of claims per segment at minimum, more for rare large losses). Sequence and neural-network reserving models can be trained in-house; always benchmark against boosting and chain-ladder baselines and keep them if the gain is marginal.

State of the art (2026)

• Boosting on engineered claim snapshots remains hard to beat on structured data; deep models add value mainly on text and on micro-level development sequences.
• Micro-level (individual claim) reserving and distributional / quantile models are active actuarial research areas, discussed in actuarial working parties such as the CAS and IFoA; classical triangle methods remain the regulatory and audit baseline.
• LLMs are now routinely used on the text side: summarising notes, extracting severity-relevant facts and drafting reason codes. They do not replace calibrated numeric models.
• Explainability and uncertainty (SHAP, conformal intervals) are expected by model-risk functions and supervisors; EIOPA's August 2025 opinion on AI governance and risk management sets supervisory expectations for insurers' AI use [7].
• Limits and failure modes: label leakage from using post-event information; social and legal inflation breaking historic patterns; structural breaks (new legislation, claims-handling changes, COVID-like events); feedback loops (a high-severity flag changes handling, which changes the outcome); small samples for large losses; and proxy discrimination if personal characteristics enter the model.

Shared resources & combinations

• Same stack (tabular-ml + time-series): PRED-010 insurance pricing (shares claim histories and features; its severity model is the pre-loss counterpart), PRED-025 warranty claims forecasting, PRED-030 telematics scoring, PRED-016 cash-flow forecasting (reserves drive expected payouts).
• Neighbours: ANOM-003 fraud detection (shares features, different target and different legal handling), AGENT-014 end-to-end claims handling automation (consumes triage scores), DOC-024 commercial submission intake (loss runs as input), PRED-038 litigation outcome prediction & legal analytics (court-case side; here the target is propensity per claim).
• Building blocks: claim data warehouse / feature store, MLOps registry, SHAP explanation service, embedding service for notes. One CPU cluster plus an optional HW2 GPU box serves all of the above.

Effort, cost & KPIs

• Path A: 2–6 months for integration and calibration; subscription or per-claim pricing.
• Path B: 4–9 months for the first production model including data engineering; cloud cost is modest relative to staff cost.
• Path C / D: 6–12+ months with a team of data engineers, data scientists and actuaries; the bulk of cost is legacy-data work and governance.
• KPIs: back-tested error of ultimate cost (MAE, calibration by decile, lift on large losses); AUC/precision at top-k for litigation; share of claims fast-tracked without later adverse development; reserve adequacy / run-off result versus prior estimates; adjuster override rate; cycle time and leakage; drift and fairness metrics.

People & change

Start with management (budget, risk appetite) and the head of claims as process owner; add the actuarial function and legal/compliance early because reserves and fairness are regulated topics. IT and data owners are needed for exports and integration; the DPO assesses legal basis and a DPIA, since claimant and health data are processed at scale (Art. 35 GDPR) and every external provider needs an AVV (GUIDE-005).

Works council: depends. Scoring claims is not monitoring of employees as such, but handler workbenches that log decisions, override rates or processing times are suited to monitor performance, so §87(1) no. 6 BetrVG likely applies; §90(1) no. 3 requires timely information when work processes change. Involve the works council before the pilot (GUIDE-004).

Measures to support AI literacy (Art. 4 AI Act) for handlers and actuaries: how scores arise, their uncertainty, and when to override (GUIDE-006). Pick a pilot group of experienced handlers in one line of business and compare against their own judgement. Typical concerns: fear of deskilling, of being measured by the score, and of unfair treatment of claimants. Address them with transparency, reason codes, and the rule that scores only support triage and reserve suggestions; handlers and actuaries decide, and the override rate is monitored, not punished (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: classification depends on use. Annex III point 5(c) lists AI systems for risk assessment and pricing of natural persons in life and health insurance as high-risk [8][9]. Claim triage, severity, litigation and reserving models for P&C are not listed as such, and portfolio reserving on aggregated data involves no natural-person decisions, so they are typically minimal or limited risk. However, if a score determines a claimant's benefits (e.g. health insurance claims, automated denial) the case needs legal review, and fraud-detection carve-outs apply only to financial fraud. Art. 4 AI literacy applies in all cases.
• GDPR: claim files contain personal and often health data (Art. 9). Art. 22 limits solely automated decisions with legal or similarly significant effect — keep a human on denial, reserve and settlement decisions. Use data minimisation and a DPIA; litigation scores about identifiable claimants are profiling.
• Insurance supervision: Solvency II governance, model-risk and actuarial function requirements, IFRS 17 for reporters [2], EIOPA opinion on AI governance [7]; DORA for ICT third-party risk when using cloud vendors; BaFin guidance (VAIT/VAIT-successor rules) in Germany.
• Fairness and conduct: avoid proxies for protected characteristics; do not use litigation propensity to treat claimants less favourably (unfair-claims-practice and good-faith duties); document how scores influence handling.
• Mitigations: human sign-off, conservative use as decision support, champion/challenger with classical methods, back-testing, reason codes, audit logs.

Getting started

1. Define the target precisely (ultimate paid, incurred at day 90, attorney involved within 12 months) and the decision it supports (triage, case reserve, IBNR challenger).
2. Build as-of snapshot data from the claims system and a leakage-safe train/validation split by accident date.
3. Fit a boosting baseline and compare with the current case-reserve and chain-ladder results [3][4]; report calibration, not just accuracy.
4. Pilot as read-only suggestions for one line of business with handler feedback; assess a vendor (Path A) in parallel using your own back-test data [1][6].
5. Run the AI Act, GDPR and model-governance review (DPIA, role as provider or deployer) before moving to production.

Sources

1. CLARA Analytics (product overview: triage, litigation) — https://claraanalytics.com/
2. IFRS Foundation — IFRS 17 Insurance Contracts — https://www.ifrs.org/issued-standards/list-of-standards/ifrs-17-insurance-contracts/
3. CRAN — ChainLadder package (claims reserving in R; v0.2.21, Feb 2026) — https://cran.r-project.org/web/packages/ChainLadder/index.html
4. XGBoost project (Apache-2.0) — https://github.com/dmlc/xgboost
5. Prior Labs — TabPFN (licence and limits) — https://github.com/PriorLabs/TabPFN
6. Gradient AI — https://www.gradientai.com/
7. EIOPA — Opinion on AI governance and risk management (Aug 2025) — https://www.eiopa.europa.eu/publications/opinion-artificial-intelligence-governance-and-risk-management_en
8. EU AI Act, Annex III (high-risk systems, point 5) — https://artificialintelligenceact.eu/annex/3/
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj