Catastrophe Exposure Management Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the project get scoped as reporting instead of the pipeline?

Because the visible pain is a report that takes until Monday. A forecast advisory drops on Thursday, the broker asks what total insured value sits inside the cone, and the team already knows the answer will take days. So the brief becomes faster accumulation reporting, and what gets built is a dashboard over a book that is still wrong in the same ways it was wrong before, only now the wrongness renders in under a second.

The work that changes the outcome sits upstream. Submission intake, broker specific cleansing rules, geocoding with recorded provenance, the defaulting policy for unknown characteristics, and the link to the policy administration system that says which locations are actually on risk this morning. None of that is glamorous and none of it is what a vendor demonstrates, which is exactly why it stays undone.

The reframe that works is to treat the exposure database as the product and reports as views over it. Every location carries where it came from, how it was matched, what was derived rather than observed, and which policy transaction put it on risk. Once that exists, accumulation reporting is a query. Without it, it is a well presented guess, and the faster you produce it the more confidently it will be misused.

What goes wrong with schedule intake and geocoding?

A commercial property submission arrives as a spreadsheet with merged header cells. Building value, contents and business interruption sit in three columns on one file and one combined column on the next. Addresses live in a single free text field with the suite number embedded. Square footage appears in a column labelled area, in metric units, on a risk in the United States. Year built is blank on many locations, and the next submission from a different broker looks nothing like it.

Underwriting assistants retype all of that into the model import template, and that is where the errors enter: a decimal shifted, a currency assumed, a location silently dropped because a row sat outside the used range. Treating each submission as a source document rather than as a paste job is the fix. Column classification maps broker headers to your canonical fields and learns per broker, because brokers are consistent with themselves even when they are inconsistent with each other. Units and currency get normalised with the assumption recorded. Rows failing validation go to a review queue instead of into the portfolio.

Geocoding is the second half and the more consequential one. A geocode is not a fact, it is a claim with a confidence. Street level match, parcel centroid, postal centroid and city centroid are different assertions, and on a barrier island the difference between the last two changes distance to coast, flood zone and modelled loss by a margin that would embarrass anyone who saw it. Store match level, provider, date and the original address string on every location permanently, and never let a resubmission overwrite a better match with a worse one. Then put a match quality breakdown next to every accumulation total, so the reader can weight the number. Reporting the uncertainty is not a weakness in the report, it is the difference between an analyst and a spreadsheet.

Why do the policy system and model integrations break after launch?

The policy feed breaks on staleness. Exposure management usually reports off a monthly extract because that is what the policy administration system will give without a fight, which means new business, endorsements, cancellations and mid term increases in insured value between extracts are invisible. In a market with fast binding authority flow that gap is material, and nothing on screen indicates it.

The fix is incremental ingestion keyed on transaction rather than snapshot, with every location carrying its on risk from and to dates. That also answers the question that arrives with the claims, which is what was on risk at landfall rather than now. Carriers with two policy platforms plus a delegated authority feed should expect each source to be its own workstream, because endorsement and cancellation semantics differ in ways that only appear under test.

The model integration breaks on schema and on assumption. Exposure exchange formats are precise and unforgiving, and a field your pipeline populates slightly differently from the model's expectation produces a result rather than an error. Ask a prospective developer which exposure formats they have imported and exported, by name, and how they handle the same physical location appearing in two different accounts, because it will and double counting it in an aggregate is the kind of error that survives a long time undetected.

Stamp every imported value with the time it arrived and show that timestamp, so a stalled feed looks stalled instead of looking current.

What happens when defaulting policy and zone aggregates are not governed?

Construction, occupancy, year built, storeys, roof geometry and roof cover drive vulnerability functions hard, and on real commercial books a large number of them are missing. The model applies a default. Your carrier partners apply a different default. The reinsurer's own run applies a third. Then everyone wonders why three loss estimates disagree, and the discussion becomes about the models rather than about the data.

Make the defaulting policy explicit, versioned and yours, with every derived value stamped as derived alongside the rule and rule version that produced it. Then run the portfolio twice, once with defaults and once with unknowns left unknown, and report the difference. That delta tells you how much of your modelled loss is science and how much is assumption, and it converts a data quality complaint into a costed decision: if most of the swing comes from a few hundred locations, you know which addresses are worth surveying.

Zone aggregates are the other governance gap. Monitoring accumulation against treaty and binder limits on a quarterly cycle means a binder filling up in a coastal county is discovered after the season rather than during it. Run the aggregates continuously against your accumulation zones so a threshold breach triggers a warning while there is still time to stop writing. That is the control that turns exposure management from a reporting function into an underwriting one.

Should you build custom or configure what you already own?

Never build a catastrophe model. The hazard and vulnerability science behind Verisk Extreme Event Solutions and Moody's RMS represents decades of specialist work, and Karen Clark and Company and CoreLogic bring their own credible views. Licence the model. What you build is the layer around it.

Do not build the surrounding layer either if you write personal lines in one or two states on a single policy administration system with a clean nightly extract and homogeneous risk characteristics. Your data is already tidy, Touchstone or Risk Modeler will consume it, and your reinsurance broker will run the accumulations. Do not build if your exposure question is answered adequately once a quarter and nobody has ever been surprised by the answer.

Build when two or more of these are true. You take commercial schedules of values from brokers in inconsistent formats. You write on more than one policy administration system or accept business from delegated authorities. You have been asked a live event question and could not answer inside a day. Your reinsurance renewal submission takes weeks of manual assembly. Or a carrier, reinsurer or rating agency has questioned your exposure data quality, which is the point at which this stops being an efficiency project and becomes a capital one.

How do hidden costs get into the quote?

Portfolio size, first, because performance engineering at ten million locations is a different job from a hundred thousand and the difference is not linear. State your location count before anyone quotes, and state your expected growth, since a design that works today and fails at twice the size is a rebuild.

Second, the number of source systems, since most carriers have at least two policy platforms plus a delegated authority feed, each with its own transaction semantics. Third, net of reinsurance, scoped separately and expected to be the hardest part, because modelling facultative placements, surplus treaties and multi layer excess of loss so a polygon query returns a defensible net figure is real work rather than a reporting toggle.

Fourth, multi peril and multi territory, since each model integration is its own effort. Fifth, geocoding licence costs, a genuine running expense at portfolio scale that belongs in the business case from day one. Sixth, review queue staffing, because the pipeline reduces retyping to review and review is a permanent role.

What separates a build that works from one that fails here?

Ask the developer to draw the model on a whiteboard: account, location, building, coverage, insured value component, geocode with match level and provenance, policy with on risk dates, treaty layer, accumulation zone, event. If they conflate location and building, or treat a geocode as two numbers rather than an object with quality attached, they have not done this and you will find out during an event.

Second, ask directly how a polygon intersection will be made fast at your portfolio size, and expect real numbers rather than reassurance. A properly indexed geospatial store answers an intersection over several million locations in seconds, and the answer should involve that index plus a considered approach to precomputed zone rollups. Vagueness here produces a system that is correct and unusable at exactly the moment you need it.

Third, get the intake pipeline into production before the reporting layer. Reports over bad data create false confidence faster than they create insight, and the intake work is what actually shortens the Thursday to Monday gap.

Fourth, use artificial intelligence where it belongs and nowhere else. Classifying broker spreadsheet columns, parsing free text addresses and flagging suspect rows are tasks where a model plus a human review queue beats retyping. Inventing missing construction characteristics and presenting them as observed data is not, and derived values must stay labelled as derived through every downstream report.

Finally, settle ownership before kickoff: the repository, the cloud accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns the code from the first commit. Your exposure database is the record of what you were on risk for, and that is not something to rent from a development shop.