Modernising insurance data workflows: what our customers ask us most

25th September 2026BlogStuart Favier

Are you ready to get in touch?

Request a Call back

The questions insurers ask about modernising data workflows are strikingly consistent, and almost none are about insurance software features. They are about stopping rekeying, tracing a figure back to source, integrating with the systems that are staying, changing a rate without waiting for a software release, and starting without a large up-front project.

Key takeaways

  • The dominant themes are rekeying, data lineage, integration with the systems that are staying, and how to modernise without a big-bang replacement.
  • Manual re-entry is usually the largest single source of data quality problems, which makes it a sensible place to start.
  • Where a rating engine is configurable rather than hard-coded, quotation changes become business-user work instead of a development request.
  • With the central market platform shelved, this work now falls to individual firms and can be done in stages rather than as a single programme.

Northdoor has been building software for the London Market for more than 35 years, and NdexInsure manages data, processes and workflow across the insurance and reinsurance lifecycle: underwriting, claims, accounting and reporting.

The context has changed in the past year. Lloyd’s Blueprint Two was shelved, so the central platform many firms were waiting for is not arriving. The common data standards work it produced remains useful. What has gone is the expectation that the market will modernise on an insurer’s behalf.

What is striking, across insurers, reinsurers, managing general agents (MGAs) and coverholders of quite different sizes, is how similar the questions are. Here are the ones that come up most, and how we tend to answer them.

How do we stop rekeying the same data three times?

This is among the most common questions we are asked, and the one the market is still working out.

Rekeying is not primarily an efficiency problem, although it is expensive. It is a data quality problem. Every manual re-entry is an opportunity for a transposition, a mis-keyed date or a wrong currency code, and each of those propagates downstream into reporting, reserving and reconciliation, where it costs far more to find than it did to create.

Northdoor branded graphic on a dark slate background with cyan accents, carrying the line Captured once, not three times.

The structural fix is straight-through processing: the data is captured once, at the point it originates, and flows through to back-end systems without human re-entry. There is a lot of discussion in the market about how to achieve that and no single approach that fits every firm. Removing the central platform from the picture makes it a question each insurer now answers for itself, usually by agreeing a format with the handful of trading partners who account for most of the volume rather than waiting for the whole market to move at once.

Can we trust the numbers in the reporting?

The question behind this one is usually about lineage. Not “is the report correct?” but “can I trace this figure back to where it came from?”

That matters for three reasons: regulatory reporting has to be defensible, actuarial and reserving work depends on knowing what is in a figure, and disputes between underwriting, claims and finance are often definitional rather than arithmetic.

NdexInsure is designed around traceability from source to reporting as an explicit architectural principle, alongside consistent process enforcement and deep integration. The practical test we suggest is simple: take a figure from your most recent board pack and try to trace it to its originating transactions. If that takes more than a few minutes, lineage is your problem rather than accuracy.

We are not replacing everything. How does this fit with what we already have?

Nobody with a functioning finance ledger and a working document management system wants to replace them, and they should not have to.

This is why NdexInsure is built with an open, modular architecture: a set of configurable functional modules instead of a monolith you adopt whole. Insurers implement the units they need and integrate with the systems that are staying.

Our general advice on sequencing is to start where the manual effort and the data quality pain are worst, which is usually the submission and data capture end, rather than starting with whatever is technically easiest. The instinct is often to begin with the module that looks simplest to implement. Fix data capture first and a number of downstream problems you were planning separate projects for quietly stop being problems.

How long does it take to change a rate?

For a lot of insurers the honest answer is currently “six weeks and a development ticket”, which is a commercial constraint dressed up as a technical one. If reacting to the market requires a software release, you will react late.

A rating engine that is a configurable service rather than hard-coded logic changes that, because rating changes across multiple lines of business become configuration rather than code. The test worth applying to any platform: can a business user, with appropriate approval and an audit trail, change a rate without a developer?

Can we start without a large up-front project?

Increasingly the answer needs to be yes, particularly for MGAs and smaller carriers where a multi-year capital programme is not realistic. It matters more now that the central platform is not coming, because firms that were holding investment while they waited are having to decide what to do on their own terms.

With the right consultancy input this work can be broken into stages that each stand on their own: remove one point of re-entry, establish lineage for one reporting area, define the interface to one system that is staying. Each stage produces something usable and can usually be funded from operating budget rather than a capital programme. It also means the direction can change if the market does, which after Blueprint Two is not a theoretical concern.

What about analytics and AI?

This comes up in every conversation now, and the honest answer is that it depends entirely on the state of the underlying data.

Analytics and AI applied to fragmented, inconsistently defined insurance data produce confident and misleading output. Applied to data captured once, traceable to source, and consistently defined, they can produce genuine advantage in pricing, claims triage and portfolio management. Which is why we treat analytics and AI as an extension of a sound data platform rather than as a substitute for building one.

The sequencing point is worth stating plainly: fixing capture and lineage first is not a delay to the AI agenda. It is the AI agenda.

Who actually does the implementation?

Platform capability and implementation capability are different things, and insurance is a domain where the second matters disproportionately, because the edge cases are where the risk sits.

Northdoor provides services and consultancy across design, deployment, integration, migration, management and support, drawing on the same London Market experience the platform is built on. In our experience the domain knowledge of the implementation team matters more to a successful outcome than the feature list of the platform.

One customer, a director of underwriting, put it this way: “Northdoor were awarded a European IT Excellence Award for the work they performed for us. We have been very impressed with the business knowledge of their consultants.”

The common thread across insurance software conversations

None of these questions is really about software features. They are about reducing manual handling, being able to trust and trace the numbers, integrating with what already exists, and moving in steps rather than leaps. With the market platform gone, those steps are now each firm’s to choose. If any of them sound like your own conversations, we are happy to talk through how other insurers have answered them.

Frequently asked questions

A platform for managing data, processes and workflow across the insurance and reinsurance lifecycle, covering underwriting, claims, accounting and reporting. It is built on an open, modular architecture, so insurers implement the functional units they need and integrate with the systems they are keeping, instead of adopting it whole.

Through straight-through processing: capture the data once, at the point it originates, and flow it through to back-end systems without human re-entry. How firms achieve that varies, and with the central market platform shelved it is now a decision each insurer makes for itself, usually starting with the trading partners who account for most of the volume.

They can where the rating engine is a configurable service rather than hard-coded logic. That is the test worth applying to any platform: can a business user, with appropriate approval and an audit trail, change a rate across a line of business without waiting for a software release?

Yes, and the sequencing point matters. Analytics and AI applied to fragmented, inconsistently defined insurance data produce confident and misleading output. Fixing capture and lineage first is not a delay to the AI agenda; it is the AI agenda.


Stuart Favier All Author's Posts
1

Our Awards & Accreditations