The Data Question Every Underwriter Should Ask a Technology Partner

Every technology company pitching to an insurer leads with the same claim: "Our data will improve your underwriting." The claim may be true. But in our experience of assessing technology companies against our seven-dimension framework, the data conversation is where the gap between marketing and reality is widest — and where underwriters who ask the right questions can separate genuinely valuable data from noise.

Here are the questions that matter most, why they matter, and what the answers tell you about whether a technology partner's data is actually worth integrating into your pricing, risk selection, or claims processes.

1. What is the data, and where does it come from?

This sounds basic, but the answer is often less clear than you'd expect. A telematics company might generate proprietary driving behaviour data from devices installed in vehicles — that's first-party data with a clear provenance. A flood risk company might aggregate data from public hydrological records, satellite imagery, and proprietary sensor networks — that's a blend of sources with different quality levels and update frequencies. An AI underwriting platform might enrich submission data using third-party databases — in which case, the "data" they're providing is actually someone else's data that they've licensed and repackaged.

Understanding the data supply chain matters because it determines reliability, defensibility, and cost. Proprietary first-party data is typically the most valuable because competitors cannot easily replicate it. Licensed third-party data may be available to your competitors through the same or similar providers. Aggregated public data adds context but rarely creates competitive advantage on its own.

2. Has this data been correlated with actual insurance outcomes?

This is the single most important question and the one most technology companies cannot answer convincingly. There is a critical difference between data that is conceptually relevant to insurance risk and data that has been statistically validated against actual claims outcomes.

A building sensor company might have data showing that a property's internal humidity levels fluctuate beyond safe thresholds. That is conceptually relevant to escape-of-water claims. But has anyone actually tested whether properties with those humidity patterns experience higher claims frequency or severity? If not, the data is an interesting signal, not a validated rating factor.

The technology companies with the strongest insurance propositions have done one of two things: either they have partnered with an insurer to correlate their data with actual loss experience (the gold standard), or they have conducted their own analysis using proxy data and can present a credible statistical hypothesis with supporting evidence.

If the answer to this question is "we believe the data is relevant but haven't yet tested it against claims outcomes", that's not disqualifying — but it means the partnership needs to start with a data validation exercise, not a pricing integration.

3. What does the data not capture?

Every data source has blind spots. A telematics system captures driving behaviour but not vehicle maintenance history. A satellite imagery platform captures property condition but not internal building systems. A flood model captures surface water risk but may not account for subsurface drainage.

Understanding the limitations of a data source is as important as understanding its strengths. A technology company that can honestly articulate what their data does not capture — and what complementary data sources would be needed to build a complete risk picture — demonstrates the kind of intellectual honesty that sustains long-term partnerships. A company that claims their data is comprehensive when it manifestly isn't is a company that hasn't done the hard thinking about how their product fits into an underwriting workflow.

4. How fresh is the data, and how often is it updated?

Data has a shelf life, and that shelf life varies dramatically by type. Telematics data that is 12 months old may still be relevant for long-term behavioural patterns but worthless for assessing current risk. Satellite imagery from two years ago doesn't reflect recent construction, vegetation growth, or environmental changes. A company's financial data from the last accounts filing may be significantly out of date.

For underwriting purposes, you need to understand the data refresh cycle. Is the data streamed in real time? Updated daily? Monthly? Annually? And does the update frequency match the decision-making cadence of your underwriting process? If you're pricing annual policies but the data is only updated quarterly, there may be a latency gap that affects accuracy.

5. Who owns the data, and what happens when the relationship ends?

Data ownership in technology partnerships is surprisingly murky. If a telematics provider generates driver behaviour scores based on data collected from your policyholder's vehicle, who owns the raw data? Who owns the derived scores? Can you retain the scores after the partnership ends, or do they disappear with the provider?

The FCA's Consumer Duty and the broader regulatory framework expect insurers to maintain control over the data inputs to their pricing and underwriting decisions. If a technology partner holds the data and you lose access when the contract ends, you face a dependency risk that your compliance team should be uncomfortable with. The contractual terms around data ownership, portability, and post-termination access should be agreed before any data integration begins.

6. Could this data create fair pricing concerns?

The FCA has announced that in 2026 it will evaluate the risks and barriers to AI adoption in insurance, specifically examining how technology affects pricing fairness and transparency. This means any data source that feeds into pricing needs to be assessed for potential proxy discrimination.

Location data correlates with ethnicity and socioeconomic status. Driving behaviour data may correlate with occupation, shift patterns, or disability. Building sensor data may correlate with the age and income of occupants. None of these correlations are intentional, but they can produce pricing outcomes that disproportionately affect protected groups.

Ask the technology company: "Have you tested your data for proxy discrimination? What protected characteristics could your data correlate with, and what controls are in place to prevent discriminatory pricing outcomes?" A technology partner that has thought about this proactively is one that understands the regulatory environment their data operates in. One that hasn't is creating risk for you.

7. How does the data integrate with our existing systems?

The best data in the world is useless if it can't reach the underwriter's desk in a format they can act on. Ask about integration architecture: Is the data available via API? What format does it arrive in? Does it map to standard industry data models? Can it be ingested by your policy administration system or pricing engine without custom development?

The integration question is also a scalability question. A manual data exchange — spreadsheets emailed weekly — might work for a 50-risk pilot but cannot sustain a 5,000-risk production deployment. If the technology company doesn't have API-first integration capability, every deployment will be a custom project, and custom projects don't scale.

The underwriter's checklist

Before integrating any external data source into your underwriting or pricing process, you should be able to answer:

— What is the data, and is it first-party, licensed, or aggregated?

— Has it been validated against actual claims outcomes in our line of business?

— What are its known limitations?

— How frequently is it updated, and does that match our decision cadence?

— Who owns the data, and what happens if the partnership ends?

— Has it been tested for proxy discrimination?

— Can it be integrated via API at production scale?

If you can answer all seven with confidence, you have a data source worth integrating. If you can't, you have a data source that needs more validation before it touches your pricing model.

---