How AI Analyzes Loss Run Reports for Underwriting

AI analyzes a loss run report by reading the document whatever its format, extracting every claim line into structured data, normalizing it across carriers and layouts, and then computing the numbers an underwriter actually needs, loss ratio, claim frequency, severity, and open reserve exposure, so the risk can be scored against your appetite. In WIR's architecture this work happens in an external AI layer that sits on top of your core policy administration system and never replaces it. The core stays the system of record. The layer just reads the history faster and more consistently than a person rekeying PDFs ever could.

What a loss run report is, and why it is hard to read

A loss run report is the claims history a prior insurer produces for a policyholder, usually covering the last three to five years. Each line records a single claim: date of loss, cause, amount paid, reserves still held, and whether the claim is open or closed. For an underwriter pricing a renewal or a new submission, it is the most important evidence of how a risk has actually behaved, not how it describes itself.

The difficulty is not the information, it is the packaging. Loss runs arrive as PDFs, and often as scans of printouts. Every carrier formats them differently. Columns move, labels change, and the same field can be named three different ways across three documents. A single mid-sized commercial account can carry several loss runs from several prior carriers, each in its own layout. Someone has to read all of it, rekey it, and reconcile it before any judgment is possible. That manual reading is exactly the kind of low-value work that quietly consumes an underwriter's day.

How AI analyzes a loss run report, step by step

Step 1: Read the document, whatever its format

The layer ingests the file as it arrives, a native PDF, a scanned image, or a spreadsheet, and reads it. For scans it applies optical character recognition, and for born-digital files it parses the layout directly. This is the same intelligent reading of submissions that lets an underwriter stop treating document handling as their job.

Step 2: Extract every claim line into structured fields

Reading is not enough. The layer maps what it read into consistent fields: loss date, claim status, paid amount, reserve, cause of loss, and claimant type. Free-text descriptions are classified into categories the underwriter can filter and sort. What was a flat, unsearchable document becomes a table you can actually query.

Step 3: Normalize across carriers, currencies, and periods

Because the loss runs come from different insurers, the same concept is expressed differently in each. The layer reconciles those differences, aligning field names, date formats, currencies, and coverage periods so the histories can be compared on one basis instead of five. This is where structuring unstructured insurance data turns a pile of documents into a single view of the risk.

Step 4: Compute the metrics underwriters actually use

With clean data in place, the layer calculates the figures that drive a decision. The loss ratio, incurred losses divided by earned premium under the standard industry convention, sits alongside claim frequency, average and peak severity, and the exposure still held in open reserves. These are not new metrics. The layer simply produces them in seconds, per year and per cause, instead of after an afternoon of spreadsheet work.

Step 5: Detect patterns and flag what needs a human

Finally, the layer looks across the normalized history for what a fast human read tends to miss: a rising frequency trend, a cluster of claims from one cause, a large open reserve that could still develop, or a gap that suggests a missing year of history. It surfaces these as flags with the underlying claims attached, so the underwriter reviews a prepared case rather than assembling one.

An AI loss run analysis is the automated reading, structuring, and scoring of a policyholder's prior claims history, so an underwriter receives clean metrics and flagged patterns instead of a stack of inconsistent PDFs to rekey by hand.

Why this belongs in an external layer, not the core

Core policy administration systems store policies, calculate premiums against filed rates, and manage billing and claims. They were never built to read a broker's scanned loss run or reason about whether its pattern fits your appetite. Forcing that intelligence into the core is what makes modernization projects long and costly. WIR's answer is to leave the core exactly where it is and add the intelligence beside it.

The external layer reads and analyzes the loss runs, then writes the structured history and the resulting metrics back into the core through its APIs. The core stays authoritative for the policy, the billing, and the claims record. Nothing it is meant to own ever leaves it. This is the same pattern behind automating underwriting without replacing your core system, applied to the specific document that carries the most underwriting signal.

Reading loss runs by hand is also a large share of where the time goes. Accenture's research on underwriting productivity has found that underwriters can spend as much as 40 percent of their time on non-core and administrative activities rather than on evaluating risk. Automating loss run analysis attacks that number directly, because it removes one of the most repetitive parts of preparing a submission.

What the loss ratio is telling you, and what it is not

A loss ratio computed from a loss run is a summary of the past, not a verdict on the future. It tells you how the losses on a book compared with the premium earned, under the standard convention of incurred losses over earned premium, but on its own it says nothing about why. A ratio that runs a few points above plan can reflect one large open claim, a single bad year, or a genuine deterioration in the risk. The value of structuring the history is that the underwriter can separate those cases quickly instead of pricing off a single headline number. The metric points to where to look. A person still decides what it means.

Explainability, SUSEP, and LGPD

WIR was born in Brazil, where two constraints shape any underwriting automation. The first is SUSEP, the insurance regulator, which expects insurers to own and justify their pricing and acceptance practices. The second is the LGPD, Brazil's general data protection law (Law 13.709 of 2018), whose Article 20 gives a person the right to request review of decisions made solely by automated processing that affect their interests.

Both point to the same design rule. Every figure the layer produces has to trace back to the specific claim lines behind it, and a person has to be able to review it. That is why the layer is built to show its work: each computed metric links to the source claims, and the analysis is a prepared input for a human underwriter, not an unaccountable verdict. Keeping a person in the loop is a deliberate WIR design choice, and it is how the layer honors the spirit of Article 20 in practice.

A note on proof

WIR has run this external-layer architecture in a proof of concept with a global insurer in the transport line, applying document intake and analysis on top of the insurer's existing environment. We reference it deliberately and sparingly, because the point of the pattern is that it reproduces across lines and systems, not that it rests on a single case.

The bottom line

A loss run report holds the clearest signal an underwriter has about how a risk really behaves, and today most of that signal is trapped in inconsistent PDFs. An external AI layer reads those documents, structures them, computes the standard metrics, and flags what deserves a second look, then hands the result to a person who still makes the call. Your core keeps doing what it does well. The underwriter gets the history in minutes instead of hours.