Insurance is a data business that has been generating data for longer than almost any other. That should be an advantage. In practice, for many UK insurers, MGAs and brokers, it produces a specific and familiar frustration: the organisation is confident the answer exists somewhere, and equally confident that getting to it will take three weeks and two spreadsheets.
Why is insurance data so fragmented?
It is worth being precise, because the causes determine the fix.
System sprawl by design. A typical insurer runs a policy administration system, a separate claims platform, a finance ledger, one or more broker or distribution feeds, a reinsurance system, and increasingly a set of cloud services for pricing, fraud detection or document handling. Each was chosen well for its own job. None was chosen to integrate.
Acquisition history. Books of business acquired over two decades arrive with their own systems, their own product codes and their own definitions. Migration is expensive, so the older platform is often kept running for the run-off, and the estate grows another layer.
Definitional drift. Underwriting, claims and finance each have a legitimate definition of a term such as ‘loss ratio’, ‘written premium’ or even ‘active policy’. None is wrong. They are different, and when reports built on different definitions land on the same board table, the discussion becomes about the numbers instead of the business.
Manual bridging. Where integration is missing, people fill the gap. Someone exports, someone reconciles, someone rebuilds the same pivot table every month. It works, it is invisible in any system diagram, and it stops entirely when that person leaves.
Why do platform projects not fix it on their own?
Most insurers have already invested in a data platform, a warehouse, a lakehouse, a BI tool, sometimes all three. The technology is generally not the constraint.
The constraint is that a data platform is not a finished asset. It is a living system of pipelines, transformations, definitions and permissions, all of which decay unless someone tends them. A source system upgrade changes a field. A broker changes their file format. A new product launches with codes nobody mapped. Each is small. Each quietly corrupts a downstream report.
In most insurance IT teams, the people capable of fixing that are the same people running the core platforms, and core platforms win the priority argument every time. So the pipeline breaks, someone works around it with a spreadsheet, and confidence in the reporting drops another notch.
“Nearly every insurer we talk to has already bought good technology,” says Martin Summerhayes, Head of Managed and Support Services at Northdoor. “What they haven’t got is somebody whose actual job, every day, is making sure yesterday’s data arrived, arrived correctly, and means the same thing it meant last month. That’s not a project. It’s an operational discipline, and it’s the bit that gets squeezed.”
What do managed data analytics services cover?
The specifics vary, but a service worth having covers the following.
Pipeline operations. Monitoring ingestion and transformation jobs, detecting failures and anomalies, and fixing them to agreed service levels, including out of hours where the reporting cycle demands it.
Data quality management. Automated validation rules with exception reporting, so that a broker file arriving with 30 per cent null postcodes is flagged on arrival rather than discovered in a board pack.
Model and definition governance. Maintaining a single agreed definition for the metrics that matter, documented, versioned, and applied consistently across reports.
Platform tuning and cost management. Cloud analytics costs scale with inefficiency. Query optimisation and storage tiering routinely pay for a meaningful share of the service.
Change support. Onboarding a new data source, a new product line or a new regulatory return, without waiting for the next internal project cycle.
Reporting and access governance. Making sure the right people can see the right data, which in insurance means being deliberate about personal and medical data in claims records.
What changes, measurably
The outcomes insurers tend to report are consistent.
- Reporting cycles shorten. Month-end reporting that depended on manual reconciliation compresses when the reconciliation is automated and monitored.
- Analyst time shifts. Data preparation commonly takes more of an analyst’s time than analysis does, and recovering that time is usually the largest single productivity gain available.
- Confidence returns. When the numbers stop being disputed, meetings are about decisions rather than about whose spreadsheet is right.
- Key person risk falls. The undocumented monthly process living in one person’s head becomes a documented, monitored pipeline.
- New questions become answerable quickly. Claims leakage by cause, broker performance by cohort, exposure aggregation by peril, all become queries rather than projects.
Is a managed model right for your organisation?
A managed model tends to suit organisations where the analytics estate matters to the business but is too small to justify a permanent platform engineering team; where reporting is business-critical but IT priorities sit elsewhere; where there is a real gap between what the data could answer and what it currently does; or where an acquisition has just doubled the integration burden.
It suits less well where the underlying source data quality is fundamentally broken at origin, in which case that needs addressing first, or where the organisation already has a well-staffed and well-funded data engineering function.
What this means for your organisation
The technology is rarely the constraint. The constraint is that nobody’s day job is making sure yesterday’s data arrived, arrived correctly, and still means what it meant last month. If that description lands, our managed data analytics services and our wider insurance work are built around exactly that gap. Tell us where yours is.