Property & Casualty Insurance Data Provider · Head-to-head
FEMA NFIP Redacted Claims v2 (OpenFEMA) vs FEMA NFIP Redacted Policies v2 (OpenFEMA)
Which property & casualty insurance data provider data fits your job: FEMA NFIP Redacted Claims v2, or FEMA NFIP Redacted Policies v2. API, files, or your warehouse. Daily, weekly, or hourly.
FEMA NFIP Redacted Claims v2 (OpenFEMA)
FEMA NFIP Redacted Policies v2 (OpenFEMA)
Where the fields line up
7 shared fields — join on these.
| Field | FEMA NFIP Redacted Claims v2 | FEMA NFIP Redacted Policies v2 |
|---|---|---|
ratedFloodZone | documented | Flood zone used to rate the policy. |
occupancyType | documented | Coded occupancy of the insured building. |
totalBuildingInsuranceCoverage | documented | Building coverage limit in USD. |
totalContentsInsuranceCoverage | documented | Contents coverage limit in USD. |
elevationDifference | documented | Difference between lowest floor and base flood elevation. |
postFIRMConstructionIndicator | documented | Whether the building was built after the initial Flood Insurance Rate Map for its community. |
nfipCommunityName | documented | Name of the NFIP community. |
Coverage, side by side
| FEMA NFIP Redacted Claims v2 | FEMA NFIP Redacted Policies v2 | |
|---|---|---|
| Geographic | `state`, `reportedZipCode`, `countyCode`, `censusTract`, `censusBlockGroupFips`, rounded `latitude`/`longitude` | Same stack under `propertyState`; adds `femaRegion` |
What each contains
They tie on 4 attributes. Pick by fit, not by loyalty.
| FEMA NFIP Redacted Claims v2 | FEMA NFIP Redacted Policies v2 | |
|---|---|---|
| Record identifier | `id` (UUID) | `id` (UUID) |
| Time anchor | `dateOfLoss` plus `yearOfLoss` and `asOfDate` - when the water arrived | `policyEffectiveDate` / `policyTerminationDate` - when coverage ran |
| Geography | `state`, `reportedZipCode`, `countyCode`, `censusTract`, `censusBlockGroupFips`, rounded `latitude`/`longitude` | Same stack under `propertyState`; adds `femaRegion` |
| Flood zone | `ratedFloodZone`, `floodZoneCurrent` | `ratedFloodZone`, `floodZoneCurrent` |
| Occupancy | `occupancyType`, `numberOfUnits` | `occupancyType`, `numberOfUnits` |
| Carried coverage | `totalBuildingInsuranceCoverage`, `totalContentsInsuranceCoverage` | `totalBuildingInsuranceCoverage`, `totalContentsInsuranceCoverage` |
| Deductibles | `buildingDeductibleCode`, `contentsDeductibleCode` | `buildingDeductibleCode`, `contentsDeductibleCode` |
| Elevation profile | `baseFloodElevation`, `lowestFloorElevation`, `lowestAdjacentGrade`, `elevationDifference` | Same four fields |
| Community identity | `nfipRatedCommunityNumber`, `nfipCommunityNumberCurrent`, `nfipCommunityName` | Same three fields |
| Construction era | `originalConstructionDate`, `originalNBDate`, `postFIRMConstructionIndicator` | Same three fields |
| Money fields | Damage amounts, gross and net building/contents/ICC payments, `iccCoverage`, non-payment reason codes | `totalInsurancePremiumOfThePolicy`, `policyCost`, `federalPolicyFee`, `hfiaaSurcharge`, `reserveFundAssessment`, `iccPremium`, basic/additional rates |
| Event attribution | `floodEvent`, `eventDesignationNumber`, `causeOfDamage`, `waterDepth`, `floodWaterDuration` | None - pre-loss file |
| Underwriting flags | Partial (elevated, primary residence, small business, rental) | Full set incl. `mandatoryPurchaseFlag`, `crsClassCode`, `grandfatheringTypeCode`, `insuranceToValueCode` |
| Documented fields | 72 (42 shared with policies) | 82 (42 shared with claims) |
What each does better
FEMA NFIP Redacted Claims v2
Half a century of loss history. Loss dates run from 1970-08-31 forward, so Katrina-era surges, Superstorm Sandy and every named nor'easter in between are queryable as individual claim rows - the December 1992 Nor'easter sample row alone shows a New Jersey ZIP printing $7,243.04 paid on building and $3,000 on contents against $59,700 of building coverage. No catastrophe-model vendor gives you the government's own claim-level ground truth over that span.
Payment mechanics, not just totals. Gross amountPaidOnBuildingClaim sits beside net netBuildingPaymentAmount, contents and ICC versions of both, plus coded nonPaymentReasonBuilding and nonPaymentReasonContents - so closed-without-payment outcomes are separable from under-limit payouts. waterDepth and floodWaterDuration add physical severity that no financial ledger carries.
Event attribution. floodEvent names the storm ('December Storm - Nor'easter') and eventDesignationNumber ties a claim to its federal disaster declaration where one exists, letting you group losses into events instead of inferring clusters from dates.
FEMA NFIP Redacted Policies v2
27x the rows, and the denominator they unlock. With 73,601,802 policy transactions you can compute exposure, take-up rates and premium adequacy by ZIP, county or census tract - the numerator-only view the claims file offers cannot produce either. Loss-ratio work is structurally impossible without this file.
The full money trail of a policy. Total premium plus policyCost, federalPolicyFee, hfiaaSurcharge, reserveFundAssessment, iccPremium and even communityProbationSurcharge decompose what a policyholder actually pays; basicBuildingRate through AdditionalContentsRate expose the rate ladder itself, with rateMethod, subsidizedRateType and grandfatheringTypeCode explaining why two houses in one zone pay differently.
Underwriting attributes claims lack. mandatoryPurchaseFlag, primaryResidenceIndicator, elevatedBuildingIndicator, postFirmVzoneIndicator, crsClassCode, insuranceToValueCode, buildingDescriptionCode and the waiting-period and rollover-transfer codes describe the insured risk as written - the variables an actuarial or pricing model needs as features, not just as outcomes.
The verdict
Verdict: sample both, pick by fit - the question decides, not the row count. Reach for FEMA NFIP Redacted Claims v2 (OpenFEMA) when your unit of analysis is a loss event: catastrophe-model validation against actual paid claims, severity curves by flood zone or occupancy, event-level accumulation checks, climate-adjusted loss trends since 1970, or journalism that needs the government's own payout record. Reach for FEMA NFIP Redacted Policies v2 (OpenFEMA) when your unit of analysis is exposure: take-up-rate mapping by tract, premium sufficiency and cross-subsidy analysis, pricing-model feature engineering from rating attributes, or market-sizing for flood carriers and MGAs.
Three quick tests settle most cases. Need dollars paid after a named storm? Claims only. Need who was holding coverage before the storm, and what they paid? Policies only. Need a loss ratio - paid losses over earned premium? That is the both-of-them case, joined on geography and period.
Sample both, pick by fit. See FEMA NFIP Redacted Claims v2 · See FEMA NFIP Redacted Policies v2
Or take both in one feed
They stack into the classic actuarial loop, and the shared 42-field spine makes the join unusually cheap for two government extracts. A defensible workflow: build the exposure base from policies - counts, coverage limits and premium by ZIP and flood zone - then bring claims in as the outcome layer and read frequency and severity against it.
Align three things before joining. First, identity: there is no policy-to-claim key in the redacted extracts, so joins happen on geography and period, not on a shared ID. Second, names: apply the alias map (state/propertyState, crsClassificationCode/crsClassCode) or half your columns will null out. Third, meaning: policyCount describes claim-side policy association on one file and record-level multiplicity on the other. Get those right and the pair behaves like one database. Datadory ships either record alone or merged onto one calendar, delivered daily, weekly, or hourly - your call. Or take both in one feed.
API, files, or your warehouse. Daily, weekly, or hourly.
Fair questions
Is FEMA NFIP Redacted Claims v2 (OpenFEMA) better than FEMA NFIP Redacted Policies v2 (OpenFEMA)?
For studying floods, yes; for studying the insurance book, no. The claims file holds 2,721,780 loss transactions reaching back to 1970-08-31 with damage amounts and payments, while the policies file holds 73,601,802 policy transactions with premiums, coverage limits and rating detail. They score equally at 9/10 - sample both and match each to the question.
What do FEMA NFIP Redacted Claims v2 (OpenFEMA) and FEMA NFIP Redacted Policies v2 (OpenFEMA) have in common?
Forty-two documented fields, verbatim: the full geography stack down to census block group and rounded coordinates, rated and current flood zones, occupancy, carried building and contents coverage, deductible codes, the four-field elevation complex, community numbers, and construction-era markers.
Which dataset has more records, NFIP claims or NFIP policies?
Policies, by roughly 27 to 1 - 73,601,802 policy transactions against 2,721,780 claim transactions. That ratio is itself informative: it captures how much of the flood book never produces a claim, and it is exactly the denominator a take-up-rate or loss-ratio calculation needs.
Which NFIP dataset goes back further in time?
Claims. The earliest loss date in the claims extract is 1970-08-31, giving more than five decades of paid-loss history, while the policies extract's documented temporal coverage begins 2009-01-01 on policy effective dates. For long-run severity trends the claims file is the only instrument; for premium and exposure work the shared recent window is what matters.
Can the claims and policies files be joined?
Yes, but on geography and period rather than a shared key, since the redacted extracts carry no policy-to-claim identifier. The 42 shared fields make the join cheap: align ZIP or county, flood zone and year, apply the alias map for renamed columns like `state` versus `propertyState`, and treat `policyCount` carefully because its meaning differs between the two files.
Which should a cat-model analyst sample first?
Sample both, pick by fit. A catastrophe analyst validating a flood model starts with claims - actual paid losses tied to named events and disaster declarations. An analyst pricing or sizing the flood book starts with policies - exposure, premium and rating attributes. Teams running the full validation loop keep both in rotation and join them on geography and period.