Insurance

The average hides the leak

At company level the portfolio looks profitable. That figure is an average — of profitable and loss-making lines, of good and bad agents, of efficient and inefficient branches. Averages are where leakage goes to hide.

How much did we sell? always has an answer. Where and why are we losing money? usually does not — not because the data is missing, but because answering it is expensive. Four places the value goes:

• Loss buried in an average. The overall loss ratio is acceptable, and inside it sit lines and agents doing damage that cannot be recovered.
• Late detection. An adverse trend is normally seen after the period has closed — by which time a full issuance cycle has been written at the same rate.
• Operational leakage. Delay in the claim cycle, leakage in instalment collection, open files. None of these has a cost line.
• Unused opportunity. Customers with genuine cross-sell capacity, and customers about to lapse, are both in the data and neither is visible.

What the delay costs

Every month of delay is one more issuance period written at the wrong rate. That is the whole argument, and it is not a rhetorical one: a rate correction made this month applies to policies not yet written, and a rate correction made next quarter does not.

The same arithmetic runs through the claim cycle. The company reports an average settlement time; it does not know which step of which branch produces it, so improvement is attempted by adding assessors rather than by fixing the one stage that creates most of the delay. And nobody asks what the delay costs, because the answer needs claim data joined to renewal data — two systems that are usually not connected to each other.

How the work changes

The hard part is not the query. It is framing the question, and in insurance the framing is where the disagreement lives.

"Why has our loss ratio gone up?"

That cannot be answered as asked. Which line? Paid ratio or incurred? Against the prior period or against the approved rate? So the system asks, agrees a scope and confirms it before anything runs, then proposes the axes an experienced technical specialist would look at: portfolio risk mix, written rate against approved rate, agent contribution, severity of large losses.

For questions whose answer is not a number, a research run dispatches an orchestrator and a fleet of workers — three to twenty per run — each testing a different angle against the relevant source, returning one documented report with the figures attached.

Two properties matter more than either. A user with the right permission sees the exact query that ran. And when the data will not support an answer, the system says so rather than producing a plausible number: a data-plane circuit breaker turns eight consecutive failures into an honest error instead of a confabulated one. Numbers that appear in a chart are computed by executing code against the result set, never written into a sentence by a model.

What it connects to

Nothing is migrated and nothing is copied out. Issuance, claims, health, finance, collections and the sales network stay where they are and are read. One adapter layer covers thirty database engines behind a single interface, which is what makes a single answer across issuance and claims possible at all.

The step that decides answer quality is not the install. It is schema documentation: a drafting assistant proposes a description for every table and column, and the company’s technical and actuarial experts edit and approve it. In insurance the definitions are the whole game. Once the system knows which columns and which reserves make up loss ratio in your company, the answers agree with your official reports. Until then they will not.

Where this is the wrong fit

• If you want a fraud engine, this is not one. It surfaces recurring patterns and the evidence for them, and it is equally useful for showing that an apparent anomaly is one large legitimate claim. The judgement stays with your people.
• If the actuarial and technical units have not agreed the definitions, that argument comes first. It surfaces in week one, which is at least useful.
• If claims and renewals are not both in the warehouse, the question everyone wants answered — what delay costs in retention — cannot be answered yet. Bringing them together is the prerequisite, not an optional extra.
• If the schema is undocumented, budget the documentation. No language model repairs a warehouse nobody can explain.
• If you need writes — reserving, adjustment, workflow — this is the wrong layer. Read-only is a design decision, not a gap.
• It is deployed in production for two organisations today. Early, deeply engineered, and we would rather you knew before the first meeting.