Insurers use the recorded facts of the structure and the lot: construction and exterior wall, roof material and style, year built, building and living area, stories, heating and cooling, pool and garage, and parcel geometry and location. It comes from county assessor, recorder, and GIS offices, and it is used to pre-fill and verify applications, feed replacement-cost tools, scope claims, and analyze a book of business by geography. Carriers either pull it county by county or license it from a provider that normalizes roughly 3,000 county formats into one schema and delivers it by API or bulk transfer.
Property insurance starts with a description of the property, and most of that description already exists in public records. The assessor has the construction, roof, year built, square footage, and stories. GIS has the parcel boundary and location. Together they answer the questions an application, a claim, and a portfolio review ask about the structure, before anyone asks the applicant. The difficulty is that roughly 3,000 counties publish those facts in their own layouts on their own schedules. A normalized property data provider keys everything to the address and parcel, standardizes the field names, and delivers the record by API into application and claims systems or by bulk file for book-wide analysis. What it does not do is describe the person: the record is about the property, and it is not a consumer report.
Four groups cover most of what an insurer asks about a property. Structure and construction set the rebuild picture: construction type, exterior wall, roof material and style, foundation, stories, and basement. Size and age set the scale: building and living area, bedrooms and bathrooms, year built, and effective year built. Systems and features fill in the rest of the application: heating and cooling equipment and energy source, water, sewer, gas, and electric service, fireplace, pool, garage, and unit and building counts. Location and parcel place it on the map: coordinates, parcel geometry, census tract, acreage, and zoning.
The same record serves every desk. The application desk reads it to pre-fill and verify. The claims desk reads it to scope a loss against what was recorded. The portfolio desk reads it in aggregate to see how construction, roof, and age are distributed across a book by county, city, or map bounds.
Nearly all of it is public record. County assessors publish building characteristics, year built, and square footage as part of the tax roll. County recorders file deeds and transfers, which is how a record shows that a property changed hands. GIS departments publish parcel boundaries, coordinates, and zoning. What is not on file, such as a hazard score or a roof age, is not something the record claims to know.
The difficulty is scale. Each county chooses its own field names, formats, identifiers, and publication cadence, so a carrier writing in more than a few states ends up maintaining a parser per county or buying a one-off extract per market. A provider like Realie collects at the source, normalizes the counties into one schema keyed by parcel, refreshes it on a rolling, per-county cycle as counties publish, so vintage varies by county, and delivers it through an API for per-address lookups or bulk transfers for book-wide work.
Property data describes a parcel, not a person. It is not a consumer report, and Realie is not a consumer reporting agency. Realie's Terms of Use prohibit using the data as a factor in establishing an individual's eligibility for insurance, credit, employment, or housing, or for any other FCRA-regulated purpose, and Realie does not market owner lookups by name.
Property-side insurance workflows sit inside that boundary because they start from an address the carrier already holds: the application in front of a producer, the claim that was just filed, or the policies already on the book. The data describes the structure and the lot, not the policyholder, and it carries no risk scores or ratings. Starting from the address is both the compliant pattern and the one that produces the cleanest data.