FDEs in insurance: map the workflow before putting AI on the file

Picture your first week at a commercial insurer. The demo reads ACORD forms cleanly and the whole room nods. Then an underwriter opens a loss run from a provider nobody has tried and asks: “What about this one?”

Many engineers’ reflex is to go back and tune the prompt. But an analysis in Insurance Thought Leadership on AI in commercial submission intake says plainly that the biggest barrier, far ahead of the others, is integrating AI into the existing intake workflow.

So the most valuable work an FDE does in this industry comes before the first line of code: understanding whose hands a submission passes through, where it stops and who is responsible for signing. Once you know that, you know which steps to automate and where a person has to stop the flow.

Underwriting and claims ask two different questions

Underwriting looks forward: should this risk be accepted, and on what terms? Claims looks back: a loss has happened, so should it be paid? The input data, the decision-makers and the first point of automation therefore differ between the two flows.

On the claims side, QBurst describes a fairly clear starting point: first-level reviewers usually follow predefined rules, so this work suits rules-based automation. A claim that meets the rules and passes the fraud checks can go straight to the payment determination step; the rest moves to adjudication with human involvement.

Prosper, a vendor, goes further, saying AI can approve or deny simple claims with little human intervention, leaving adjusters time for complex cases. Do not treat these two approaches as one. Before letting a machine deny a claim on its own, ask the client who will stand up and explain that decision.

Following one submission from email to system

Now walk through a hypothetical example on the underwriting side. A broker sends an email with three files: an ACORD form, a loss run and a statement of property values. This is exactly the group of documents that the same analysis regards as a good starting point for automation.

It sounds simple until you meet the loss run, because this kind of loss history report varies from provider to provider.

Suppose the ACORD form declares three losses and the loss run has four rows. The model can read both documents correctly, without a single wrong character, and the submission still has a problem. Extraction accuracy will never detect a contradiction like this. Only a cross-checking step can.

Here is one more calculation to take into the meeting. Suppose each submission has 40 fields, each field is 98% accurate and errors across fields are independent. The probability that a whole submission is clean is 0.98 to the power of 40, or about 44.6%: out of every 100 submissions, roughly 55 have at least one wrong field.

The 98% on the slide and the 55 in the underwriter’s queue describe the same system. So the next thing to write is the routing step, not another round of model tuning:

def route(sub):
    reasons = []
    if sub.loss_run_provider not in KNOWN_TEMPLATES:
        reasons.append("loss run from an unseen template")
    if sub.acord_loss_count != len(sub.loss_run_rows):
        reasons.append("loss count differs between ACORD and loss run")
    missing = [f for f in REQUIRED_FIELDS if not sub.get(f)]
    if missing:
        reasons.append(f"missing fields: {missing}")
    if sub.min_confidence < CONFIDENCE_FLOOR:
        reasons.append("confidence below threshold")
    queue = "exception_review" if reasons else "standard_review"
    return queue, reasons

Note two details. Both branches end with a person looking at the submission, because there is no path on which the machine closes the case by itself.

This design follows the recommendation of the same analysis: human experts keep the final judgement, and low-confidence cases must pass to a person. FurtherAI, for its part, treats an interface for underwriters to review the output as the mark of a good tool.

The second detail is reasons. An underwriter who receives a submission with the words “loss count differs” knows which page to open, whereas a confidence score of 0.71 tells them nothing.

Last comes measurement. Go back to the 100 submissions in the calculation above, roughly 55 of which have a wrong field, and suppose the routing step sends 60 submissions to the exception queue and 40 to the standard queue.

You check all 40 of those by hand and find 4 that are wrong but were not flagged. These are the slipped errors: the submissions still reach a person in standard_review, but the underwriter reviews them without receiving any warning.

Those same 4 submissions yield two rates, and they should not be confused. Measured against the standard queue, 4/40 is 10%: one in every 10 unflagged submissions is wrong. Measured against the submissions with errors, 4/55 is about 7%: that is the share of wrong submissions the routing step misses.

Those are the two numbers to put in front of the client, along with the size of the exception queue. They match what the same analysis demands for production: proving that AI runs reliably in the real workflow, including exceptions and missing or contradictory data, rather than merely reporting model accuracy.

What to do in your first week at the client

Start by sitting next to an underwriter or a claims handler and watching them work through five real files, including the kind of case they hate most. Note every time they switch screens, call someone or send an email to ask a question, because that is where the real workflow lives, not in the process documents.

Next, draw a one-page map and mark three kinds of step: those with clear rules, those that need judgement and those that require a person’s signature. The steps with clear rules are the ones to consider automating first; the steps that need a signature are where a person must review. Take the map back to the very people you observed and have them correct it.

Then ask for a sample of loss runs from each provider, count the formats and rank them by submission volume. From there, choose a small piece of work to start with, such as only the few most common templates, and send everything else straight to the exception queue. A narrow scope that really runs is more persuasive than a broad one that only runs in a demo.

Product and jurisdiction change the whole design

Two projects carrying the same “AI for underwriting” label can face very different requirements. The EU AI Act classifies AI used for risk assessment and pricing of life and health insurance for individuals as high-risk, under Annex III.

Extracting a loss run for a commercial submission is a different problem, but that boundary should be confirmed by the legal department.

In the US, the NAIC adopted a model bulletin on AI on 4 December 2023. It sets principles-based standards for the practices that insurers using AI are expected to follow, and it is left to each state to adopt.

So the question to ask in the very first meeting is: which product, individual or business customers, operating in which states or countries, and which instruments have been adopted?

Whatever the answer, the design advice is the same: record the model version, the routing reasons, who reviewed and when from the start. This is a precautionary engineering habit, because adding these fields early is usually less work than reconstructing them when someone asks about an old submission.

The traps right behind the demo

These five mistakes are all easy to make, because when you first make them they look like progress:

• Treating the demo as proof. A demo on clean documents says nothing yet about production.
• Reporting average accuracy per field. This number hides both submission-level errors and the rare loss run templates the model has never seen.
• Talking only to the buyer and the leadership team. You need to sit with the people who handle submissions every day.
• Leaving the exception queue without an owner. Difficult submissions merely move from one inbox to another screen and get handled no faster.
• Letting unreviewed data flow into downstream systems just because the integration is ready. Keep the data load after the review step, at least until slipped errors are low enough for the underwriters themselves to agree to loosen it.

What to put on your CV to prove this skill

When reading a job description, look for signs that the company understands this work: words such as ACORD, loss run, FNOL, exception handling or human-in-the-loop show they have touched the real workflow. If the description talks only about models and prompts, ask in the interview who handles exceptions at the client.

On your CV, replace “built a document extraction pipeline” with a sentence that covers the workflow, the review gate and the measurement: which types of exception you routed, who reviewed them and how the slipped-error rate was measured. The skill also transfers to other industries with files and people who sign off on them.

An exercise for this week

Create two fake loss runs from two imaginary providers, with different column names and date formats, plus a fake ACORD form that deliberately misstates one loss. Write the route function above, run it on 20 submissions you generate yourself and seed with errors, then count how many errors slip through.

Then give the reasons list to someone who is not an engineer and ask what they would do next. If they cannot answer, your function only knows that a submission has a problem. It does not yet help anyone deal with it, and that is the gap an FDE is paid to close.