Real Estate & Property
Property Hazard Intelligence API
Hazard exposure is usually answered at postcode level, which is the wrong resolution for a decision about one building on one side of a street.
- Insurers
- Mortgage lenders
- Property portals
- Asset managers
- Surveying firms
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Physical risk has become a routine question in property underwriting and lending, and the usual answer is a postcode-level flag drawn from a national hazard map. For flood in particular that resolution is close to useless: elevation differences of a metre over fifty metres separate a property that floods from one that does not, and a postcode can contain both.
The underlying data has improved considerably. Elevation models, modelled flood extents at multiple return periods, soil and geology mapping, wildfire fuel and historical burn data, and downscaled climate projections are available at resolutions that support address-level assessment. The gap is integration — the datasets come from different bodies in different formats with different vintages and different licence terms.
The other gap is honesty about what the output means. A hazard model is a modelled probability under assumptions, not a statement about what will happen to a building. Subsidence in particular is driven as much by the specific foundation, the trees nearby and the building's own history as by the clay beneath it, and no dataset carries those. The useful product quantifies exposure and is explicit about the residual it cannot see.
Who buys this
Insurers, Mortgage lenders, Property portals, Asset managers, Surveying firms
What the API returns
What comes back
- Hazard scores per peril at address level, with the resolution of the underlying data stated
- Flood exposure by return period and by source: river, surface water, coastal, groundwater
- Heat exposure including urban heat island effect and projected change under climate scenarios
- Wildfire exposure from fuel load, terrain, historical incidence and interface proximity
- Subsidence and ground-stability exposure from geology, soil shrink-swell and tree proximity
- Historical incident records for the location where they are available
- Defence and mitigation context, such as flood defences and their standard of protection
- Per-peril confidence and a stated list of what the model cannot see
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/hazards | All peril scores for a location |
| GET | /v1/hazards/flood | Flood exposure by source and return period |
| POST | /v1/hazards/batch | Portfolio-scale hazard screening |
| GET | /v1/hazards/projections | Exposure under named climate scenarios and horizons |
| GET | /v1/hazards/history | Recorded historical incidents near a location |
| GET | /v1/coverage | Data availability, resolution and vintage by region and peril |
Request and response
illustrativeRequest
{
"location": { "lat": 53.8184, "lon": -1.5214, "uprn": "100051234567" },
"building": { "footprint_geojson": null, "ground_floor_level_m": null,
"year_built": 1935, "basement": false },
"perils": ["flood", "heat", "wildfire", "subsidence"],
"projections": ["baseline", "2050_mid_emissions"]
}Response
{
"location": { "resolved": "address_point", "geocode_confidence": 0.98 },
"perils": {
"flood": {
"score": 64, "band": "moderate",
"by_source": [
{ "source": "surface_water", "return_period_30y": "exposed", "depth_m_100y": 0.35 },
{ "source": "river", "return_period_100y": "not_exposed", "distance_to_extent_m": 180 }
],
"defences": { "present": true, "standard_of_protection_years": 75 },
"data_resolution_m": 2,
"confidence": "medium"
},
"heat": { "score": 58, "band": "moderate",
"urban_heat_island_uplift_c": 1.9, "days_over_30c_baseline": 4 },
"wildfire": { "score": 11, "band": "low", "interface_distance_m": 2100 },
"subsidence": { "score": 71, "band": "elevated",
"soil_shrink_swell": "high", "trees_within_15m": 3,
"confidence": "low",
"limitation": "foundation type and building history not in any dataset" }
},
"projections": [
{ "scenario": "2050_mid_emissions", "flood_score": 72, "heat_score": 74,
"basis": "downscaled climate projection, scenario-dependent" }
],
"not_modelled": ["building-specific drainage", "private defences", "foundation design"]
}Where the data comes from
| National and regional flood mapping | Modelled flood extents by source and return period, from official hazard mapping bodies, licensed where commercial use requires it |
| Elevation models | High-resolution terrain and surface models, which are what make address-level rather than postcode-level flood assessment possible |
| Geology and soil mapping | Shrink-swell potential, made ground and ground-stability data from geological survey bodies, usually under a commercial licence |
| Climate projection datasets | Downscaled scenario projections from official climate services, used as scenarios and never as a single forecast |
| Historical incident records | Recorded flood, fire and subsidence events, which calibrate and sanity-check modelled exposure |
| Vegetation and land-cover data | Satellite-derived fuel load, canopy and tree proximity, relevant to both wildfire and subsidence |
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.
- Address-point and building-footprint resolution rather than postcode centroid, since the centroid approach is the main source of error in existing hazard products
- Per-peril modelling with terrain-aware flood assessment, including surface water, which is frequently the dominant source and the one most often omitted
- Defence context applied explicitly rather than embedded, so a user can see whether a low score depends on a defence and what its standard of protection is
- Climate projections presented as named scenarios with horizons, never collapsed into one future number
- Subsidence modelled from geology, soil and vegetation with an explicit statement of the building-specific factors no dataset contains
- Geocoding quality propagated into the response, because an address resolved to a street rather than a point invalidates the resolution claim
- Validation against recorded historical incidents, reported per peril and per region, with known false-negative patterns documented
- Vintage and resolution tracking per dataset, surfaced in the coverage endpoint rather than hidden behind a uniform score
What it changes for the business
Underwriting at the right resolution
Address-level exposure replaces postcode flags that are wrong for a meaningful share of properties.
Portfolio screening
Physical risk across a book becomes measurable per property rather than estimated by region.
Consumer transparency
Portals can show exposure context with the limits stated, which is better for everyone than silence.
Scenario reporting
Climate scenario exposure supports the disclosure work lenders and asset managers now face.
How it fits into your product
How it embeds
- Single call by address, coordinate or property identifier for interactive use
- Batch screening endpoints for books and portfolios, with throughput sized to your volume
- Coverage endpoint so your product can state resolution and vintage rather than implying uniformity
- Map tile and GeoJSON output where you want to render hazard extents in your own interface
- Scenario configuration so your risk team chooses which projections are used and reported
- Deployment inside your environment where portfolio composition is commercially sensitive
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 weeksDiscovery 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
Does this tell us whether a property will flood?
No. It gives modelled exposure under stated return periods and scenarios, which is a probability statement about a location, not a prediction about a building. Properties inside a modelled extent go decades without flooding and properties outside one do flood, usually through surface water or a drainage failure no hazard map represents.
How good is the subsidence assessment?
Weaker than the others, and the response says so. Geology, soil shrink-swell and tree proximity are genuinely predictive at a population level, but subsidence risk for one building depends on its foundation design, its construction history, local drainage and past movement — none of which exists in any dataset we can buy. We score the exposure and name the residual rather than implying it is covered.
What resolution is it really?
It varies by peril and region, and the coverage endpoint reports it per dataset. Flood modelling can be two-metre grid in well-mapped countries and far coarser elsewhere. We would rather expose that variation than average it into one confident-looking score, because the variation is exactly what a user needs to know before relying on it.
Can we use this for insurance pricing?
Technically it can feed a pricing model, and several of the datasets are licensed with that use in mind — but the licence terms differ sharply between internal assessment, pricing and redistribution to customers, and some of them explicitly exclude one of those. We establish which uses each source permits during discovery, because this is a case where the data you may read is not the data you may price with.
How are climate projections handled?
As named scenarios at named horizons, always plural. Collapsing scenario projections into one number for a property would misrepresent the uncertainty, which in long-horizon climate projection is the dominant feature rather than a footnote.
Related blueprints
Building Energy Scoring API
Modelled energy efficiency, retrofit opportunities with indicative costs, and benchmarks against comparable stock, as an API for lenders and asset managers.
Automated Property Valuation API
Estimated property values with confidence ranges and the comparable sales behind them, as a valuation endpoint your portal or lending flow can call.
Rental Price Intelligence API
Expected rent for a property, neighbourhood comparisons and rental trend series, as an API letting agents and investors can call per address.
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.