Use case · Insurance
Unusual claims flagged, and every score explained
Claims, policies, assessments and payments come together in a model that flags the cases to review first. Every score comes with its reasons, every model version is approved before production, and your claims handlers keep the decision.
The challenge
Detect without suspecting everyone
- Data scattered across policy administration, claims management and payments.
- Personal data, sometimes health data, that requires limiting what the model sees.
- Claims handlers who need to understand a score to use it.
- A chain to document, from the dataset to the model in production.
How graal handles it
From claim to explained score
Step 01
Gather
Connectors read your operational databases — PostgreSQL, Oracle, SQL Server. The tables land in the lakehouse, queryable in SQL.
Step 02
Prepare
A pipeline computes the indicators of each claim and checks data quality; direct identifiers are replaced before training.
Step 03
Train and explain
Your data scientists train a gradient boosting model in a notebook or an XGBoost job. The contribution of each variable to the score is computed and kept with the run.
Step 04
Approve
A new version only goes into production after human approval: the approver, distinct from the author, sees the metrics and the training data.
Step 05
Score
New claims are scored on demand through a REST endpoint, or every night by a job. Data drift is tracked.
The typical scenario covers an insurer’s motor or home claims, over a few years of history. The model does not decide: it ranks the claims to review, and the handler sees why a case was flagged. The pilot can start on synthetic data, before being replayed on your data, in your infrastructure.
Regulation (EU) 2024/1689 on artificial intelligence classifies as high-risk the AI systems intended for risk assessment and pricing in life and health insurance (Annex III, point 5(c)). graal helps you trace and document these systems.
What you get
- A queue of claims to review, sorted by score
- For every score, the variables that explain it
- A complete history: data, parameters, approval and production version
- Tracked drift, to retrain at the right time
What stays with you
- Policy and claims data
- The pseudonymised dataset and the code that produces it
- The model, its explanations and its approvals
Capabilities involved
- Connectors
PostgreSQL, Oracle, SQL Server and files.
- Lakehouse and SQL
Iceberg tables and federated SQL with Trino.
- Notebooks
Jupyter and VS Code to explore and model.
- Machine learning
Experiments, registry, REST scoring and drift.
- Governance
Human approval, per-project permissions and audit.
Frequently asked questions
Does the model make the decision?
No. It ranks the claims; the decision stays with the claims handler, who sees why a case was flagged.
Can we start without real data?
Yes. The pilot can begin on a synthetic dataset, then move to your data once the platform is installed on your premises.
How do we prove what runs in production?
Every version is linked to its training run, its data, its approval and its author, and the audit trail records who did what.
Prepare this use case on your claims
In 8 weeks, a first explained model, installed in your infrastructure.