Home/Offers/Insurance & Claims/Property Risk Scoring API

Insurance & Claims

Property Risk Scoring API

Two houses on the same street can carry materially different flood risk. Postcode-level pricing cannot see the difference, and the market increasingly can.

Property insurers
MGAs
Reinsurance brokers
Mortgage lenders
Property platforms

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Peril pricing at postcode or zone level made sense when address-level hazard data did not exist. It does now. Elevation models are available at sub-metre resolution in many countries, flood modelling has moved to individual building footprints, and wildfire exposure depends on fuel load and defensible space within tens of metres of a structure. An insurer still pricing a zone is averaging across properties whose true risk differs by an order of magnitude, which means systematically overcharging the good ones and attracting the bad ones.

That adverse selection runs in one direction and compounds. Competitors with address-level data decline the properties they can see are exposed and undercut on the ones they can see are not. The zone-priced book accumulates exactly the risks the market has rejected, and the loss ratio deteriorates for reasons that look like bad luck in a management report.

Building this is mostly a geospatial data engineering problem with a modelling layer rather than a research problem. Hazard data has to be assembled from sources with genuinely different licences and resolutions, the property has to be geocoded to the building footprint rather than the street centroid, and structural characteristics have to be joined from whatever records exist. Geocoding accuracy turns out to be the dominant source of error — a flood score computed on a point forty metres from the actual building can be completely wrong.

Who buys this

Property insurers, MGAs, Reinsurance brokers, Mortgage lenders, Property platforms

Category: Insurance & Claims

What the API returns

What comes back

Per-peril risk scores at address level: flood, wildfire, windstorm, subsidence, coastal
Return-period depths and intensities per peril, not just a score
Building footprint geocode with the positional accuracy actually achieved
Site characteristics: elevation, slope, distance to water, surrounding fuel load, soil type
Structural attributes where records exist — construction, roof type, age, storeys
Expected annual loss estimate per peril against a declared sum insured
Portfolio aggregation with accumulation analysis and correlated exposure clusters
Data quality and confidence reporting per peril, including where coverage is absent

Endpoints

Method	Path	Returns
POST	/v1/properties/score	Score one address across all configured perils
GET	/v1/properties/{id}/perils/{peril}	Detailed hazard analysis for one peril
POST	/v1/portfolio/score	Batch scoring for an existing book or a submission
POST	/v1/portfolio/accumulation	Aggregate exposure and correlated clusters by peril
GET	/v1/properties/{id}/evidence	Underlying hazard data and sources behind each score
GET	/v1/coverage	Peril coverage, resolution and data vintage by country and region

Request and response

illustrative

Request

{
  "address": {
    "line1": "22 Mill Lane",
    "town": "Tewkesbury",
    "postcode": "GL20 5SA",
    "country": "GB"
  },
  "sum_insured": { "buildings": 420000.00, "contents": 60000.00, "currency": "GBP" },
  "perils": ["flood", "windstorm", "subsidence"],
  "include_evidence": true
}

Response

{
  "property_id": "prp_4412098",
  "geocode": {
    "latitude": 51.99214, "longitude": -2.15880,
    "matched_to": "building_footprint",
    "positional_accuracy_m": 3.1
  },
  "site": {
    "elevation_m": 11.4,
    "distance_to_watercourse_m": 86,
    "soil": "shrink_swell_clay_high",
    "slope_deg": 1.2
  },
  "perils": {
    "flood": {
      "score": 78, "band": "high",
      "return_periods": [
        { "period_years": 30,  "depth_m": 0.00 },
        { "period_years": 100, "depth_m": 0.41 },
        { "period_years": 200, "depth_m": 0.78 }
      ],
      "defences_present": true,
      "defence_standard_years": 100,
      "expected_annual_loss": 1840.00,
      "confidence": "high"
    },
    "windstorm": { "score": 34, "band": "moderate", "expected_annual_loss": 210.00,
                   "confidence": "medium" },
    "subsidence": { "score": 61, "band": "elevated", "expected_annual_loss": 640.00,
                    "confidence": "medium",
                    "note": "High shrink-swell soil; no tree proximity data available for this address" }
  },
  "data_quality": { "unavailable_perils": [], "stale_sources": [] },
  "as_of": "2026-10-21"
}

Where the data comes from

National flood hazard mapping	Published flood extent and depth models from environment agencies; open in some countries, licensed in others, and resolution varies enormously
Digital elevation and terrain models	High-resolution elevation data, which is the foundation of any credible flood or surface water analysis
Building footprint datasets	Needed to geocode to the structure rather than the street, which is the largest single driver of scoring accuracy
Wildfire fuel and vegetation data	Satellite-derived fuel load, canopy and land cover, plus historical fire perimeters where published
Soil and geology surveys	Shrink-swell potential and ground stability data, which drive subsidence exposure
Catastrophe model output	Licensed vendor model results where you already subscribe; licence terms generally prohibit redistributing their output through your own API

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Geocoding to building footprint with positional accuracy reported per property, because an address-level score computed on a street centroid is not an address-level score
Per-peril modelling with hazard-appropriate resolution rather than one grid for everything — wildfire needs tens of metres, windstorm does not
Defence and mitigation handling that reflects the standard of protection and residual risk, since a defended property is not an unexposed one
Expected annual loss derived from vulnerability curves calibrated on your own claims where you can share them, rather than generic damage functions
Explicit uncertainty per peril, driven by data resolution, vintage and geocode accuracy, so a confident-looking score from thin data is not produced
Accumulation analysis using correlated event footprints rather than simple postcode grouping, because a flood event follows a catchment and not an administrative boundary
Validation against your historical claims by peril and region, which is the only test that tells you whether the scores predict your losses
Source vintage monitoring, because hazard datasets are republished on multi-year cycles and a model quietly running on 2019 flood maps is a real risk

What it changes for the business

Reduced adverse selection

Address-level pricing stops the book accumulating the properties competitors with better data have already declined.

Faster underwriting

Risks that score clearly inside appetite can bind without referral, which is most of a residential book.

Accumulation control

Correlated exposure clusters become visible before an event rather than during claims reporting.

Defensible declinature

Per-peril evidence gives an underwriter a specific, explainable reason rather than a zone-based refusal.

How it fits into your product

How it embeds

Called inline at quote for single risks, with batch endpoints for portfolio re-scoring and submission analysis
Evidence endpoint so an underwriter can see the hazard data behind a score instead of taking a number on trust
Map components for site-level hazard visualisation, or raw geometry for your own mapping layer
Portfolio accumulation output designed to feed reinsurance submissions and capital reporting
Coverage endpoint so your rating engine can route uncovered regions or perils to referral automatically
Deployment inside your infrastructure where policyholder addresses must not leave your environment

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Can you cover every peril in every country?

No, and the coverage endpoint exists so you know where the gaps are before you quote. Flood mapping is good in much of Western Europe, North America and Australia, and poor to absent elsewhere. Subsidence depends on national soil surveys that some countries simply do not publish at usable resolution. Where data is missing the API returns an explicit unavailable flag rather than a score derived from a continental average.

Can we use catastrophe model output through this?

Only if your licence permits it, and usually it does not. Vendor catastrophe model licences are typically restricted to internal use and specifically prohibit redistributing model output through an API to third parties. If you are building this for your own underwriting, that is often fine. If you intend to resell scores to brokers or other carriers, the licence is the first thing we check and frequently the thing that reshapes the design.

How does this interact with pricing regulation?

Scores feed your rating, which stays inside your pricing governance. Several jurisdictions restrict or require justification for certain rating factors in property insurance, and some have specific rules about availability and affordability in high-hazard areas. The constraints are yours to define; our part is making sure every score is traceable to hazard evidence so a pricing factor can actually be justified.

How accurate is address-level flood scoring really?

It depends overwhelmingly on two things: the resolution of the national hazard model and whether the geocode landed on the building. With sub-metre elevation data and a footprint geocode, it is genuinely informative at property level. With a 25-metre grid and a street-centroid geocode, it is zone pricing wearing an address label, and we would tell you that rather than shipping it. Positional accuracy is reported per property for exactly this reason.

Does this account for climate change?

Partially, and with real uncertainty. Some national hazard datasets now publish future-climate scenarios, and where they do we can score against them. Where they do not, projecting hazard forward is a modelling exercise with wide bands that we would present as a scenario rather than a score. Presenting a single forward-looking number as a risk score would imply precision that does not exist.

All Insurance & Claims offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers