First Notice of Loss is the moment in the claims lifecycle where ML triage has the highest leverage — and the moment that most insurers handle least well. A claim that arrives at FNOL carries rich initial signal: the time and circumstances of the incident, the policy characteristics of the insured, the reporting channel, the structure of the initial description, potentially device sensor data or telematics history depending on the line of business. All of this signal is available in the first 60 seconds of a claim's existence. Most claims handling systems make no use of it.
What Claims Leakage Actually Means
Claims leakage is the difference between what a carrier actually paid on a portfolio of claims and what they should have paid according to their own coverage terms, applied correctly and efficiently. Leakage does not mean overpaying fraudulent claims — fraud detection is a separate problem, though it contributes. Leakage includes legitimate claims that were overpaid because reserve setting was too generous in the initial assignment, claims that could have been resolved faster (and therefore cheaper) if routed to the right handler, and claims where early intervention could have reduced total loss cost but the intervention did not happen because no one was triggered to provide it.
Estimates of claims leakage as a percentage of total claims cost vary widely by line of business and by carrier maturity, but consistent industry benchmarking from casualty and property books suggests leakage in the range of 10–20% of incurred claims cost is not unusual for carriers without systematic triage. For a mid-size European carrier writing €500M of annual premium with a combined ratio of 95%, the claims leakage at 15% represents €50–70M of potential loss ratio improvement. These numbers are not trivial. They are the reason claims automation attracts sustained institutional attention.
Why FNOL Is the Right Intervention Point
The intuition that FNOL is the highest-leverage moment is both actuarially and empirically grounded. Once a claim has been assigned to an adjuster and the initial reserve has been set, the anchoring effects are strong — adjusters working a file adapt their assessments to the opening reserve in ways that are well-documented in claims behavioural research. The initial routing decision — whether a claim goes to a fast-track automated pathway, a standard adjuster queue, or a complex-loss specialist — determines the cost trajectory for the claim's lifecycle.
Get the routing right at FNOL and a large proportion of simple claims resolve faster and cheaper through automated pathways, while complex claims that need specialist handling are correctly identified and staffed early rather than late. Get it wrong — route a simple claim to a full adjuster queue, or miss a complexity signal on a claim that needed early legal review — and the cost difference compounds through the claim's lifecycle.
The ML opportunity at FNOL is not replacing adjuster judgment on complex claims. It is performing the triage that determines which claims need adjuster judgment and which do not, in a way that is faster, more consistent, and — critically — improves continuously as the model accumulates claims outcome data.
The Feature Engineering That Matters
Building an effective FNOL triage model requires thinking carefully about what signals are available at the moment of first notice — before any investigative work has been done — and which of those signals are actually predictive of claim outcome rather than merely correlated with claim characteristics.
The signals that consistently appear in the models we see from our portfolio companies and from the research literature include: policy age at time of claim (newer policies carry different risk profiles than long-tenured policyholders across most lines); reporting lag (the time between incident and reporting, which varies meaningfully by fraud type); reporting channel characteristics (the linguistic patterns and structural features of free-text descriptions, combined with the metadata of how the claim was submitted); policy behaviour history (claims frequency and type for the specific insured, if available); and coverage boundaries proximity (whether the claimed amount is near policy limits, which shifts likelihood of inflation).
What is notably absent from the most effective models is over-reliance on demographic features that are both weakly predictive and potentially discriminatory under EIOPA fairness guidelines. A model trained on postcode, vehicle age, and policy price alone will show some predictive power — but the mechanisms are unclear, the features are proxies for variables the model cannot directly observe, and the regulatory risk of deploying demographic-heavy models for claims triage is non-trivial. The teams building claims triage models with genuine EIOPA-awareness build their feature sets around behaviour, history, and the direct characteristics of the claim event rather than insured demographics.
Integration Architecture and Why It Often Fails
The technical problem in claims triage AI is not model quality. The models that Sprout.ai and comparable companies are building work. The challenge that consistently appears in deployment is integration with the carrier's claims handling system — getting the model score into the adjuster's workflow at the point where it changes the routing decision.
Most carrier claims handling systems were not designed for real-time model inference. They are batch-oriented systems that process claims in queues. Inserting an ML triage score into the routing logic requires either modifying the claims system (expensive, slow, requires vendor involvement) or building an API layer that intercepts claims before they enter the queue and applies routing logic before assignment. The second approach is architecturally cleaner and carrier-system-agnostic, which is why the companies building portable claims triage products rather than carrier-specific integrations have a more scalable distribution path.
We are not saying carrier-specific integration is wrong — for a first deployment, working closely with the carrier's claims system vendor to pilot triage automation in one line is a reasonable approach. The architectural risk is building the product in a way that does not generalise beyond the first carrier, requiring a nearly ground-up rebuild for each subsequent deployment. The teams we back in this space are those who have thought clearly about the portability problem from the start.
What the Loss Ratio Data Shows
The available evidence from claims triage deployments — and this is still a relatively young dataset, with most serious ML triage systems deployed in 2020–2023 — suggests loss ratio improvement of 2–4 percentage points on the lines where triage is applied, in early production cohorts. That is a meaningful but not dramatic improvement from the first deployment generation. The improvement trajectory as models accumulate outcome data and routing decisions are reinforced by feedback is where the long-term economic case rests — the model that has seen 500,000 claims outcomes is substantially more accurate than the model that has seen 50,000. The carrier that builds this data flywheel earliest has a compounding advantage that grows annually.
For seed-stage founders building here: the economic case is clear, the market is large, and the technical approach is now well-established enough that differentiation requires either superior feature engineering, a superior integration architecture, or specific depth in complex loss categories where the triage problem is harder. Generic FNOL automation is competitive. Triage for liability, professional indemnity, or business interruption remains under-served and technically more interesting.