Automation does not safeguard underwriting quality

Three pillars for moving from a system of records to a system of intelligence

Automation speeds things up. It does not safeguard quality.

The market talks a lot about automation. In underwriting, it is often associated with speed. Yet speed and quality are not synonymous.

An automated process can also simply make a poor decision faster. And in a P&C portfolio, an incomplete decision can weigh on a balance sheet for years.

The problem, therefore, is not to automate more but to design a system that safeguards the quality of decision-making.

My point is not that process automation is bad. Insurers have achieved significant efficiency gains by investing in data extraction, file routing, and conditional triggers.

My thesis rather is that these are not enough. These automations improve the organisation of work by shifting or accelerating tasks, but they do not answer the underwriter’s central question: what should I do with this risk?

In insurance, accelerating incomplete decisions merely speeds up the accumulation of risk debt.

This debt is dangerous because it appears in no balance sheet report. A portfolio can look stable in volume, premium, and number of policies, while risks drift beneath the surface. At its root, a system that executes steps without actually informing decisions.

This is the core of my argument today: to safeguard underwriting quality, the system must be designed as a decision layer.

Here are the three technological choices we built on to move from a System of Records to a System of Intelligence.

1. The Configuration Engine: turning guidelines into executable logic

Underwriting policies often remain in PDFs, spreadsheets, product notes, or committee decisions. A rule that is known but not executed in the workflow is not an operational rule; it is merely an intention.

The Configuration Engine transforms this body of guidance into executable logic. It starts by deriving versioned and reproducible rules from varied, multi-modal inputs: structured and unstructured documents, transcripts, product rules, internal guidelines, underwriting policies, risk appetite criteria, exclusions, reference thresholds, referral rules.

This logic applies to both stock and flow, to new business as well as existing policies, to distribution APIs as well as internal reviews, instantly.

Immediacy is paramount because every year, committees define new rules that take years to permeate the portfolio. In the meantime, the stock continues to be underwritten against obsolete rules. The Configuration Engine breaks this cycle by making the rule executable immediately, across the entire stock and flow.

A rule that lives in the Configuration Engine is operational upon publication. It does not depend on a distributor, an email, a committee memo, or training.

The Configuration Engine thus enables the shift from a declared strategy to an executed one. Risk appetite is no longer a document; it becomes computational logic living in an ecosystem. An insurer that can modify its rules and see them applied immediately can adjust its appetite in real time. It does not wait for the next renewal campaign.

Control becomes continuous. It is control that enables speed, not shortcuts.

2. Alerting & Risk Insights: from noise to prioritisation

Classic automation can produce many alerts, but an alert is not a decision. The underwriter does not need more noise. They need prioritised, explained signals attached to an action.

The Alerting & Risk Insights module ingests and harmonises a wide range of data: risk forms data, claims data, external data, geographic data, activity information, prevention data, unstructured documents, financial data, location information.

From there, the system must solve a major technical challenge: linking this data to the right policyholder, the right production site, the right policy, and the right scope. This step is often invisible, but it conditions everything else. External data that can’t be assimilated to the right policy is only an orphaned signal.

Then comes the cross-referencing of this data against deterministic rules, specialised insurance models, business heuristics, risk appetite criteria, criticality thresholds, and referral rules. The value comes from the cross-referencing.

As an aside, a generic LLM can read, summarise, and synthesise vast amounts of data, but in underwriting, reading is not enough. You must apply a strategy, manage rules, trace sources, and prioritise risks. The model alone does not make the system.

The goal is to build a precise sequence so the pipeline can be efficient. The logic follows this pattern:

1. Application of simple, low-cost filters: a change in activity detected by a deterministic rule does not require a model.
2. Deterministic rules.
3. Specialised insurance models: deployment of a model trained on sector data when a complex pattern is identified in claims data, for example.

NB: An LLM is only called upon when a strong signal requires reading unstructured documents or a complex synthesis.

This sequencing concentrates computational resources where the signal value is highest. It avoids calling a costly model on a case that a deterministic rule can already handle.

It also helps prevent alert fatigue, because the goal is not to maximise the number of alerts but to maximise the quality of the action to be taken.

Ten actionable recommendations are worth more than 10,000 alerts.

3. Decision Support: preparing and defending the decision

The Decision Support module then transforms signals into actionnable recommendations.

To do so, it must answer simple questions: what are we seeing? Why does it matter? What source justifies it? Which business rule is concerned? What action is recommended? What priority level should this task be given?

It must also be integrated into operations, whether that is the Continuity interface, the partner broker portal, the core system, the API, or the dashboard, etc.

Information must naturally arrive before the decision, at the right level of granularity and in the right system. A signal that arrives after the decision is merely a report.

The overarching objective is to craft a system where the underwriter remains the analyst and the decision-maker. The system only feeds him intelligence to make the right call.

That said, preparing the decision is not enough. In underwriting, a recommendation must also be defensible. The underwriter must understand why a risk is flagged, and teams must be able to reproduce a decision. Auditors, for their part, must understand the reasoning.

Without this, opaque automation erodes trust.

Reproducibility is the prerequisite for this trust. If two underwriters ask the same question at the same time on the same risk, the system must produce the same recommendation. If a rule is modified, the system must document the version used at the time of the decision. If an auditor requests the full reasoning, the system must be able to reconstruct it end-to-end.

A comprehensive decision architecture must document at least:

• the data used,
• the rules applied,
• the signals detected,
• the sources mobilised,
• the recommended actions,
• the versions of the rules used.

Each recommendation can thus be traced from source data to proposed action.

This documentation is not a compliance report. It is the guiding thread that makes the decision understandable, reproducible, and defensible.

Traceability is not an afterthought. It is part of the product’s design. An untraceable automated decision is not a defensible underwriting decision.

Adoption as proof of architecture

I would add that an underwriting system does not succeed because it is technically impressive. It succeeds because teams use it in their decisions.

If underwriters bypass the tool, it is not just an adoption problem. It is often a design problem. The tool must arrive at the right moment to reduce friction between data, risk, and the decision.

At Continuity, we follow this core conviction: automation must not replace judgement. It must make it more available, faster, and more traceable.

We have therefore designed the platform so that it links stock, flow, rules, data, and decisions.

The Underwriting Assistant filters the flow, SCAN continuously analyses the stock, while the API lets this intelligence be embedded in existing systems. It is important that intelligence is embedded where the underwriter works, not where the system sends them.

Speed must come from intelligence, not from shortcuts

In summary, in underwriting, speed is only valuable if it safeguards the decision.

Automation alone can accelerate the build-up of risk debt. The decision architecture makes it possible to go fast without losing control of risk.

The future of underwriting is not blind automation. It is governed, comprehensible, and decision-centred automation.

Speed must come from intelligence, not from shortcuts.

–

Pierre Beauhaire
CTO / Co-founder, Continuity