Why PolicyTrace: the claims handler and the policy pack

When a new motor claim lands with a handler, the first job isn't really about the accident. It's about the policy. Was cover in force on the day? Is the person who was driving actually on the policy? Was the car being used the way the policy allows? Which excess applies? The answers are all in the policy pack, but the pack is usually four or five PDFs, and the answers are spread across them.

I've spent a lot of my career working on data and machine learning with UK insurers, and that first step is where I kept seeing time go. Handlers aren't slow; the documents are just awkward. A fact can sit in a table on page two of one document and contradict a sentence on page one of another. Finding it takes time. Missing it costs more, because a missed endorsement or a driver who isn't named on the policy can change the whole claim.

PolicyTrace is my attempt at that first step. It reads the pack, pulls out the facts a handler needs into one structured record, and shows exactly where in which PDF each fact came from.

The questions a handler asks, and where the answers live

Almost every one of those questions maps to a field PolicyTrace already extracts:

• Was cover in force? The period of cover, start and expiry, from the Schedule.
• Was the driver covered? The named drivers, with date of birth, licence type and who the main driver is.
• Was the use allowed? Class of use, the clause about social, domestic and pleasure use, commuting and business use. PolicyTrace takes this from the Certificate, because the Certificate is the legal document.
• What level of cover? Comprehensive or third party, and whether the policy covers driving other cars.
• Which excess applies? Compulsory and voluntary, the separate fire, theft and windscreen excesses, any excess specific to a driver, and the extra excess for using your own repairer.
• Anything else that affects the claim? Endorsements, modifications, and the no claims discount and whether it's protected.

Those fields are what a claim gets set up with, and what most validation rules check against.

Where the time goes, and what changes

Without a tool, the handler's job is searching: open each PDF, scroll, read, copy the value into the claims system, and hope nothing was missed. With PolicyTrace, the job becomes checking. Each field arrives with the document name, the page and a highlight on the source text. The handler looks, agrees or corrects, and moves on. Every value can be verified, overridden or flagged, so the person stays in charge of the decision.

Three things follow from that:

• Less searching. The time saved isn't in reading, it's in finding. That's the part of the job a tool can take on safely.
• Fewer misses. A structured record has a slot for every fact. An empty slot is visible; an unread paragraph isn't.
• A record of where each fact came from. If a decision is questioned months later, you can see which document and which line it was based on.

When the documents disagree

This is the part I find most useful for claims. The Schedule and the Certificate overlap, and sometimes they disagree. PolicyTrace doesn't quietly pick one. It applies a fixed rule (the Schedule wins, except for class of use and driving other cars), and it records the disagreement with both values.

A conflict is only useful if it's real, and my own demo is a good warning. On my runs, PolicyTrace has reported that the Schedule and the Certificate disagree about the main driver. When I checked the PDFs, the Certificate doesn't say who the main driver is at all. The model filled the gap, and my driver matching paired people up wrongly. Both are fixed now, and the same pack comes back with no conflicts. That conflict panel helped me find one bug, and showing both values and their source is what let me find the other. But in a real claim, a genuine main-driver disagreement is exactly the kind of thing a handler wants to see early. It can point to fronting, where a higher-risk driver is named on someone else's policy but is really the main driver. That isn't a conclusion, just a reason for a second look, and a disagreement buried in two PDFs is easy to miss.

What I'm not claiming

It matters to be clear about the limits:

• It doesn't validate exclusions yet. Most exclusion wording lives in the policy booklet. PolicyTrace reads only the first 20 pages of it and doesn't use it for evidence, because boilerplate matches everything. What it does give the handler is the facts that exclusions are checked against: use, drivers and endorsements. Pulling the relevant exclusion clauses from the booklet is the obvious next step.
• It hasn't been measured on real claims. PolicyTrace runs on a synthetic pack I generated. I'm not going to put a percentage on faster settlement that I haven't measured.
• Names stay masked. The demo masks personal data before the model sees it, and the record keeps the masked tokens. A handler would still check driver names against the PDF, and that part needs work before real use.
• It doesn't decide anything. It prepares the facts. The handler decides.

How an insurer could test it

The fair test is small. Take a batch of closed motor claims with their policy packs, run them through, and compare against what the handlers recorded. I'd measure four things: time from first notification to the first cover decision, how many fields handlers had to override, how often a disagreement between documents mattered, and how many facts were missed in the original handling. That shows whether the approach earns its place before anyone talks about settlement times.

The same approach also fits outside claims. New business and renewal checks, broker-submitted packs and data quality work all start with someone reading a policy pack to find a dozen facts.

Try it

The live demo loads a synthetic four-PDF pack in one click. If you'd rather run it yourself, I've written a step-by-step guide. If you work in claims and see a gap I've missed, leave a comment or message me on LinkedIn. That's the feedback I most want.