Catastrophe Exposure Management Software: How Fast Can You Actually Say What Sits Inside the Cone?

The model is not the problem. The data going into it is.

A named storm forms in the Atlantic on a Tuesday. By Thursday the forecast track shifts west and the reinsurance broker asks a straightforward question: what is your total insured value inside the current cone, and what is your modelled loss gross and net. The exposure management team already knows the answer will take until Monday. The schedules of values for the commercial book are in a folder of broker spreadsheets. Half the locations geocoded to a postal centroid. Construction class is unknown on a meaningful chunk of the portfolio and the model quietly defaulted it. The personal lines extract is from the 3rd of the month and there have been two weeks of new business since.

The uncomfortable part is that the modelled number will be produced anyway, to two decimal places, and someone will make a reinsurance purchase decision with it. Precision in the output has nothing to do with quality in the input, and everyone in exposure management knows this and works around it.

Verisk Extreme Event Solutions, Moody's RMS, Karen Clark and Company and CoreLogic all build genuinely sophisticated science. That is what they sell. What they do not sell, and reasonably do not claim to, is your submission intake process, your broker specific cleansing rules, your defaulting policy for unknown characteristics, your link to the policy system that says which of those locations are actually on risk this morning, and your ability to answer a polygon question in fifteen minutes during a live event. Touchstone and Risk Modeler expect exposure in a defined schema with clean geocodes. Getting your book into that state is the work, and it is the work nobody sells you.

Problem one: every schedule of values is a different spreadsheet

A commercial property submission arrives as an Excel file. The broker has merged cells in the header. Building value, contents and business interruption are in three columns on one file and one combined column on the next. Addresses are in a single free text field with the suite number embedded. Square footage is in a column labelled area, in square metres, on a US risk. Year built is blank on 40 of 180 locations. The next submission from a different broker looks nothing like it.

Underwriting assistants retype this into the model import template. That is the whole process at most carriers and MGAs, and it is where the errors enter: a decimal shifted, a currency assumed, a location silently dropped because a row was outside the used range.

What a custom build does: an intake pipeline that treats every submission as a source document, not a paste job. Column classification maps the broker's headers to your canonical fields, and it learns per broker, because brokers are consistent with themselves even when they are inconsistent with each other. Units and currency are normalised with the assumption recorded. Rows that fail validation go to a review queue rather than into the portfolio. This is the honest use of machine learning here: header classification and address parsing at scale, with a human confirming anything below a confidence threshold. In our builds the no touch rate on a repeat broker's format settles high enough that the assistant's job becomes review rather than retyping, which is the point.

Problem two: a geocode is not a fact, it is a claim with a confidence

Street level match, parcel centroid, postal code centroid, city centroid. On a Kansas commercial risk the difference between the last two rarely matters. On a barrier island in Lee County it is the difference between first row from the coast and half a mile inland, which changes the distance to coast band, the flood zone and the modelled loss by a margin that would embarrass anyone who saw it.

Models will happily consume a postal centroid and return a number. The number is not wrong given the input. It is just not what leadership thinks they are looking at.

What a custom build does: store match level, the geocoding provider, the date and the original address string on every location, permanently, and never overwrite a better match with a worse one when a schedule is resubmitted. Then every accumulation report carries a match quality breakdown alongside the total, so the chief risk officer sees that 12 percent of the total insured value inside the cone is sitting on postal centroids and can weight the number accordingly. Reporting the uncertainty is not a weakness in the report. It is the difference between an analyst and a spreadsheet.

Problem three: unknown characteristics get defaulted by someone, somewhere

Construction, occupancy, year built, number of storeys, roof geometry, roof cover. Secondary modifiers drive vulnerability functions hard, and on real commercial books a large share 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 everybody wonders why the three loss estimates disagree.

What a custom build does: make the defaulting policy explicit, versioned and yours. Every derived value is stamped as derived, with the rule that produced it and the version of that rule. Run the portfolio twice, once with defaults and once with unknowns left unknown, and report the delta, so you know how much of your modelled loss is science and how much is assumption. Then feed the delta back into data capture priorities: if 60 percent of the swing comes from 400 locations, you now know exactly which 400 addresses to send a surveyor to, which is a data buying decision with a return you can actually calculate.

Problem four: the polygon question has to be answered in minutes

The National Hurricane Center publishes forecast advisories with track and cone geometry on a fixed cycle. Wildfire perimeters are published as they are mapped. Flood extents arrive after the fact. The operational requirement is simple to state and hard to meet: given a polygon that appeared twenty minutes ago, return total insured value, location count, in force policy count and modelled loss inside it, split by line, by carrier paper if you are an MGA, and gross and net of your reinsurance programme.

What a custom build does: keep in force exposure in a spatially indexed store rather than a file. A properly indexed geospatial database answers a polygon intersection over several million locations in seconds, not hours, and it can do it against last night's in force position rather than a month old extract. Zone aggregates against CRESTA or your own accumulation zones run continuously rather than on a quarterly cycle, so a binder that is filling up in a Florida county triggers a warning while there is still time to stop writing, not after the storm. During an event, the same query runs every advisory and the deltas are what leadership actually wants: what changed since the last cone.

Problem five: the exposure snapshot is always older than the book

Exposure management usually reports off a monthly extract because that is what the policy system will give without a fight. New business, endorsements, cancellations and mid term TIV increases between extracts are invisible. In a hard market with fast binding authority flow, that gap is material.

What a custom build does: incremental ingestion from the policy system, keyed on transaction rather than snapshot, so the exposure position is current as at last night and every location carries its on risk from and to dates. Then any accumulation can be asked as at a date, which is also what you need when the claims start arriving and someone asks what was on risk at landfall rather than what is on risk now.

What it costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this shapes up predictably. A first release with the intake and cleansing pipeline, geocoding with match level provenance, incremental policy ingestion and on demand polygon accumulation runs $80,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding model import and export in the standard exposure formats, gross and net of reinsurance views, continuous zone aggregate monitoring, event response reporting and the data quality feedback loop runs $200,000 to $450,000 phased over 8 to 14 months.

Cost drivers particular to exposure management: portfolio size, because performance engineering at ten million locations is a different job from a hundred thousand. The number of source systems, since most carriers have at least two policy administration platforms and an MGA feed. Whether you need net of reinsurance, because modelling treaty structures including facultative, surplus and multi layer excess of loss is genuinely hard work and should be scoped separately. Multi peril and multi territory, since each model integration is its own effort. And geocoding licence costs, which are a real running expense at portfolio scale and should be in the business case from day one.

Build versus buy, stated plainly

Never build a catastrophe model. The science behind Verisk and Moody's RMS represents decades of work and you will not replicate it, nor should you want to. Licence the model. What you build is everything around it.

Do not build at all if you write personal lines in one or two states on a single policy system with a clean nightly extract and homogeneous risk characteristics. Your data is already tidy and your broker will run the accumulations. Do not build if your exposure question is answered adequately once a quarter and nobody has ever been surprised.

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 system or take 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 moment this stops being an efficiency project and becomes a capital one.

How to choose a developer for exposure management software

Ask them 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, they have not done this.

Ask directly how they will make a polygon intersection fast at your portfolio size. The answer should involve a real geospatial index and a considered approach to precomputed zone rollups, with actual numbers. Vagueness here means you will get a system that is correct and unusable during an event, which is when you need it.

Ask what exposure formats they have imported and exported. The standard model exchange schemas are not casual work and someone who has done it will say so with specifics. Ask them how they handle the same physical location appearing in two different accounts, because it will, and how they avoid double counting it in an aggregate.

Ask who owns the code, and put it in the contract before kickoff. You should hold the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns it 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.