FNOL, structured: agentic extraction for first notice of loss

The clock on a claim starts the moment a loss is reported — but for most carriers the first few hours are lost to plumbing. A broker emails a description of an accident. Someone opens it, reads it, decides what kind of loss it is, keys the claimant and date of loss into the claims system, checks whether the policy was even in force that day, and finally drops the claim into an adjuster’s queue. That handoff, repeated thousands of times a month, is where cycle time, leakage, and customer frustration all begin.

The problem is not that intake is hard to reason about — a good intake clerk does it almost automatically. The problem is that it does not scale, it does not run at 2 a.m., and it produces inconsistent records depending on who is on shift. InsightXtract treats FNOL as an agentic extraction problem: read the notice from whatever channel it came in, classify the loss, pull out the claim facts with citations, check them against policy data, and route — deterministically, and around the clock.

Every channel, one claim record

The first design principle is channel-agnostic intake. A loss does not care how it reaches you, and neither should your claim record. InsightXtract accepts the notice in whatever form it arrives:

• Broker email — free-text narrative in the body, often with an ACORD or photos attached. The most common and the messiest.
• ACORD FNOL form — a structured PDF such as the ACORD 1 (Property Loss Notice) or ACORD 2 (Automobile Loss Notice), filled by hand or typed.
• Partner API — a JSON payload from a program administrator, TPA, or aggregator posting directly into your intake endpoint.
• Phone transcript — the text of a call to the claims line, where the caller describes the loss conversationally and out of order.

Each of these is a different surface, but the agent’s job is identical: produce one normalized claim record with the same fields, the same validation, and the same routing decision. The channel becomes a detail of provenance, not a fork in the process.

The intake pipeline, end to end

Under the hood, every notice flows through the same agentic pipeline. It is classified, extracted, coverage-checked, and routed — with each stage feeding structured signal into the next.

flowchart LR
    E["Broker email"] --> N["Normalize notice
(text / OCR / transcript / JSON)"]
    F["ACORD FNOL form"] --> N
    A["Partner API payload"] --> N
    T["Phone transcript"] --> N
    N --> C["Classify loss type
(auto / property / GL / WC ...)"]
    C --> X["Agentic extraction
claimant, DOL, location,
description, vehicles/property"]
    X --> K["Coverage check
vs policy data (lookup/reference)"]
    K --> S["Severity hint"]
    S --> D{"In force &
covered?"}
    D -- "Yes, routine" --> AK["Auto-acknowledge
+ open claim"]
    D -- "Yes, needs handling" --> Q["Route to matched
adjuster queue"]
    D -- "Coverage in doubt" --> R["Route to coverage /
senior review"]
                    

The pipeline is a single run you can watch execute. Nothing is a black box: each stage records what it produced and why, so a claims supervisor can open any notice and see exactly how it became a claim.

Step one: classify the loss

Routing, coverage, and even which fields matter all depend on what kind of loss this is. So the first substantive step is classification: is this an auto-liability claim, a property loss, a general-liability incident, a workers’ compensation report? The agent reads the whole notice — not just a subject line — and assigns a loss type with a confidence score and a short rationale citing the language that drove the decision.

That rationale is not decoration. When a broker writes “our insured’s box truck rear-ended a sedan at the I-40 on-ramp and the other driver is complaining of neck pain,” the agent classifies it as auto liability with a bodily-injury indicator and quotes the exact clause that triggered the injury flag. A supervisor scanning the queue sees not just a label but the evidence behind it, which is what makes an automated classification trustworthy enough to act on.

Step two: extract the claim facts — with citations

Once the loss type is known, the agent extracts the facts that define the claim, shaped by that type. For an auto claim it pulls the claimant, the date of loss, the jurisdiction and location, a clean loss description, the vehicles involved, and any injury flag. For a property loss it would instead pull the affected location, the peril, and a damage description. Each extracted value carries a citation back to where it came from — the sentence in the email, the field on the ACORD, the timestamp in the transcript — so nothing is asserted without a source.

Citations matter most exactly when the source is messy. A phone transcript states the date of loss out of order, halfway through the call, in casual language (“this was, uh, last Tuesday the 3rd”). The agent resolves that to a normalized date_of_loss and links it back to the spoken line, so a reviewer can confirm the interpretation in one glance instead of re-reading the transcript.

Step three: coverage check against policy data

An extracted claim is useful; a coverage-aware claim is actionable. Before routing, the agent checks the claim against your policy data using lookup and reference tables: does a policy exist for this insured, was it in force on the date of loss, does the coverage part match the loss type, and does the loss location fall within the policy’s covered territory or listed locations? A date of loss that falls outside the policy period, or an auto claim against a property-only policy, is flagged immediately rather than discovered days later by an adjuster.

This is where reference data earns its keep. Jurisdiction codes, coverage-type mappings, and location schedules are resolved through the same lookup infrastructure InsightXtract uses across the platform — so “NC” and “North Carolina” and a county name all normalize to the same jurisdiction, and the coverage check compares apples to apples.

Step four: severity hint and routing

Finally, the agent attaches a severity hint — a lightweight signal based on the presence of injury, the number of parties, litigation language, or high-value property — and makes a routing decision. A clean, low-severity, clearly-covered loss can be auto-acknowledged: the claim is opened and a confirmation goes back to the broker or insured within minutes. A claim that needs a human goes to the matched adjuster queue for its loss type and jurisdiction. A claim where coverage is in doubt goes to coverage or senior review, with the specific concern spelled out.

Why this matters to claims leadership

• Faster first contact. Auto-acknowledgment and instant routing compress the gap between loss reported and claim assigned from hours to minutes — the window where customer satisfaction and leakage are most sensitive.
• Consistent records, every shift. The same fields, the same coverage check, and the same routing logic apply whether the notice arrives at noon or midnight, from a top broker or a first-time caller.
• Coverage caught at intake. Out-of-period losses and coverage mismatches surface at the front door instead of after an adjuster has already invested time.
• Adjusters get clean work. Every claim that reaches a queue is already structured, cited, and coverage-checked — so adjusters spend their time on judgment, not data entry.