A lot of technology discussion around underwriting starts with the decision.

Can AI assess the risk? Can it recommend pricing? Can it summarize the submission? Can it predict which cases deserve attention?

Those are interesting questions.

But there is a more basic one that comes first:

Does the underwriter actually have the information needed to make the decision?

A beautifully summarized submission is still incomplete if the exposure schedule is outdated. A risk score is not very useful if a key figure has no period. A document extraction system can read a PDF perfectly and still miss the fact that the PDF is last year's version.

That is why I think some of the most useful underwriting automation may sit before the judgement.

A submission can be complete on paper and still unusable

Imagine an underwriter opens a new commercial submission.

There is a proposal form, financial information, previous policy details, maybe a claims history, and a set of supporting documents. Technically, the file contains a lot of information.

Then the questions begin.

Is this turnover figure for the latest financial year? Is the location schedule current? Did the client's operations change? Is the loss information complete? Which entity does this answer refer to? Why is this figure different from the previous submission?

The problem is not always absence. Sometimes it is ambiguity.

And ambiguity creates follow-up.

Every clarification creates another coordination loop

The underwriter asks the broker.

The broker may know the answer. If not, the broker asks the client. The client may need finance, operations, HR, risk, or somebody else internally. The response eventually travels back through the same chain.

That is normal insurance work.

But when the loop repeats across many submissions, the underwriter starts spending time on something adjacent to underwriting rather than underwriting itself.

A useful system could help keep those loops structured without pretending it can replace the judgement at the end.

For example, it could help answer:

  1. Which underwriting questions are still open?
  2. Which answers came back without enough context?
  3. Has the same question already been asked?
  4. Which document supports the reply?
  5. Did the client confirm that last year's information is still current?
  6. Which issue needs underwriting judgement rather than another follow-up?

The underwriter should receive uncertainty, not have it hidden

One of the dangerous things about good software is that it can make weak information look clean.

A neat summary can create confidence that the source material does not deserve.

For underwriting, I think the opposite behaviour is more valuable.

If an answer conflicts with another source, show the conflict. If the date is missing, show the missing date. If the information was carried forward from last year and not reconfirmed, make that obvious. If a question remains unanswered, keep it open.

The goal is not to manufacture completeness.

The goal is to help the underwriter see the state of the information quickly enough to spend more attention on the actual risk.

A usable submission should expose its gaps

Completeness should be inspectable at the level of each underwriting question. A single progress percentage cannot show whether the missing item is routine or material.

For each important answer, a submission record could show:

  • the current value or document;
  • the person or source that supplied it;
  • the date or reporting period it covers;
  • whether it was confirmed for this submission;
  • any conflict with another answer;
  • the next clarification, if one is still needed.

This would let an underwriter distinguish between three different states that often look the same in a file list. The document may be absent. It may be present but outdated. Or it may be current but contain an ambiguity that requires judgement.

Those states should lead to different actions. An absent schedule may need a reminder. An old schedule may need confirmation or replacement. An ambiguous exposure may need a direct conversation between the broker and underwriter. Automation can help route the first two. It should make the third visible instead of forcing it through another generic information request.

The first useful underwriting agent may be a very boring one

It may not price the risk.

It may not recommend a limit.

It may simply make sure the information request keeps moving, remember what has already been asked, notice incomplete answers, and return a cleaner record of what is known and unknown.

That sounds less ambitious than autonomous underwriting.

It may also be much more useful in the near term.

I would like to understand where your underwriting time actually goes

If you are a commercial underwriter, I am interested in a very practical question: what information problem wastes your time most often?

Is it incomplete submissions? Outdated documents? Having to ask the broker for the same clarifications? Comparing renewal information with the previous year? Finding the source behind a number? Something else entirely?

If you have a recent example, I would be interested in hearing the real sequence of events. Not the ideal process map. The actual one.