Niamh has just started as a cat modelling analyst at Arden Re, a Dublin-based specialty property reinsurer writing European natural catastrophe, marine, and a growing renewable energy book. Her first Monday, a submission lands on her desk a French industrial property portfolio, 85 locations across Normandy and Brittany, total insured value EUR 320M, exposure to storm wind and flood.
Her manager, Ciarán, drops by. "That's your first live account. Work it through the full process and have something for underwriting by Thursday." He gestures at the SOV attached to the email. "Start with the data. The model is the easy part."
Niamh opens the SOV. Eighty-five rows. Some have full construction data. Several have blank year-built fields. Three locations have coordinates that look wrong. Two have TIVs listed in what appears to be book value. The submission also includes a policy slip with deductibles she has not yet mapped to the exposure file.
She understands each of the individual concepts; COPE, geocoding, damage functions, the EP curve from her training. What she has not yet done is connect them into a single flowing process from the moment the submission arrives to the moment the underwriter has a number they can act on.
The cat modelling workflow is a sequential chain in which each stage depends on the output of the stage before it. This is not merely an organisational convenience it is a structural feature of how models work. The model cannot run without geocoded exposure data. The output cannot be interpreted without knowing what data quality limitations exist. The pricing decision cannot be made without understanding what the output does and does not include. Skip a stage or do it poorly, and every subsequent stage is compromised.
Ciarán's instruction "start with the data; the model is the easy part" reflects this precisely. The model run itself, once the data is prepared, takes minutes. The work that determines whether the result is reliable takes hours or days. A junior analyst who runs the model immediately on the raw SOV and presents the result has produced a number quickly. Whether that number is useful depends entirely on whether the upstream data work was done.
Every stage in the workflow has an input and an output. The input to stage N is the output of stage N−1. An error introduced at stage 2 does not stay at stage 2; it propagates through stages 3, 4, 5, 6, and 7, arriving at the underwriter's desk embedded in a plausible-looking number. Understanding the full workflow means understanding where each type of error originates and how far it travels before it can be detected.
The submission arrives from the broker; an email containing the SOV, the policy slip, and any supporting documents. Before anything else, Niamh reads it. She is establishing what she has been asked to model, what data she has been given, and what the policy structure is. She notes the 85 French locations, the EUR 320M TIV, the wind and flood perils, and the deductible structure in the slip. She also notes that some coordinates look wrong and some TIVs look like book values. This first pass is not modelling; it is understanding the scope of the task before starting it.
Gate: Is the submission complete enough to proceed?Niamh works systematically through the SOV. She checks geocoding quality; three coordinates that plot in the English Channel rather than Normandy are clearly wrong and need correction before the model can assign meaningful hazard scores. She flags the blank year-built fields, these will trigger default damage functions. She identifies the two probable book-value TIVs and contacts the broker for confirmation. She checks that the construction classes are populated and plausible for French industrial stock. She documents everything she finds.
Gate: Is data quality sufficient to produce a reliable result?Niamh corrects the three coordinates using the full postal addresses in the SOV; two resolve to street level, one to postcode centroid because the address is incomplete. She applies the confirmed TIVs received from the broker, flags the two remaining unconfirmed values, and maps the SOV fields to the model's import format. She notes which fields she has populated with defaults and which are confirmed data. The output of this stage is a clean exposure file, where every limitation/assumptions is documented.
Output: Exposure file ready for model importNiamh selects the vendor model and peril set European windstorm and European flood. She configures the financial module with the deductible structure from the policy slip. She checks that the currency matches the EUR denominations in the SOV. She selects the model settings appropriate for the portfolio. The configuration choices matter: different settings for the same exposure file can produce different outputs, and those choices need to be documented so anyone reviewing the run can understand what was done and why.
Output: Configured model ready to runNiamh runs the model. This is the stage that looks most dramatic from the outside; the software running, numbers appearing but in terms of elapsed analytical effort, it is the shortest stage. The model applies the stochastic catalogue to the prepared exposure file with the configured financial conditions, calculates the ground-up and gross loss for every event, and produces the EP curve, AAL, and location-level loss summaries. The run completes. What Niamh now has is raw output numbers that reflect everything the upstream stages produced.
Output: Raw model results EP curve, AAL, location lossesNiamh does not send the results immediately. She reviews them first. She checks that the location-level losses look sensible relative to TIVs; no location should produce a loss exceeding its TIV. She checks that the two unconfirmed book-value TIVs have not produced outsized AAL contributions that will distort the portfolio total. She checks that the EP curve shape looks reasonable for a European wind and flood portfolio. She compares the French wind AAL to her sense of what a comparable portfolio should produce. She identifies two locations in the results that look unexpectedly high and traces them back to the postcode-level geocode she noted in stage 3. The output of this stage is reviewed, not raw, results.
Gate: Are results fit for presentation to underwriting?Niamh presents to Ciarán on Thursday. She does not just hand him the EP curve and AAL. She explains what the data quality was, which locations have confirmed data versus defaults, what limitations apply to the output, and what the two high-loss locations represent in terms of geocoding uncertainty. She gives him the headline numbers; AAL EUR 1.8M, 1-in-100 year OEP EUR 22M; alongside the caveats that allow him to form a professional view of risk. Ciarán has what he needs to make a pricing recommendation to underwriting. The workflow is complete.
Output: View of risk for underwriting decisionThe workflow is not merely a best-practice checklist, each stage protects the stages downstream from a specific category of error. Skipping a stage removes that protection without removing the underlying risk.
Without reading the slip before starting, Niamh might model the wrong perils, miss an endorsement that changes the coverage, or prepare a financial module configuration that does not match the actual policy terms. Errors of scope are the hardest to detect downstream because they affect everything uniformly.
The three wrong coordinates in Niamh's SOV would have gone into the model not corrected. The model would have assigned hazard scores for the English Channel. The resulting losses would have been wrong in an undetectable way, not flagged by the model.
Without reviewing the location-level results, the EUR 280K AAL contribution from the Rouen warehouse would have been presented as fact. Ciarán would have priced based on a portfolio AAL inflated by a geocoding error. The premium would have been higher than the actual expected loss.
If Niamh sends Ciarán a headline AAL and OEP without the context, which locations have confirmed data, what the postcode centroid issue means, that two TIVs are unconfirmed, he makes his pricing decision without knowing the quality of the number he is working from. The caveats are not optional footnotes; they are part of the analytical output.
The seven stages are presented in sequence, but in practice the workflow often loops back. Niamh's Stage 06 output review found the Rouen geocoding issue, which sends her back to Stage 03 to correct the coordinate, then back through Stage 04 and 05 to rerun with the corrected data, then through Stage 06 again to review the updated result. This is not a failure of process; it is the process working correctly. The output review stage exists specifically to catch issues that require a loop back.
The workflow also interacts with external timelines. Niamh's request for confirmed TIVs from the broker (Stage 02) may not be answered before her Thursday deadline. She has to decide whether to present with the unconfirmed values clearly flagged, or to hold the result until confirmation arrives. The broker's renewal timeline, the underwriter's market deadline, and the cat modelling team's data quality standards are three separate schedules that must be managed simultaneously, a dimension of real-world practice that the seven-stage framework describes but cannot fully contain.
On your first live accounts, the most important professional habit to build is documentation at every stage. It is what allows you, and anyone reviewing your work to trace a result back to its inputs, understand what was confirmed and what was defaulted, and know what caveats should travel with the output. An analyst who runs fast without documenting is creating technical issues that shows up when results need to be explained, challenged, or revisited. An analyst who documents clearly at each stage is building a professional record that stands up to scrutiny.
The model run is Stage 05 of seven. The stages before it; submission review, data quality assessment, geocoding, configuration, determine whether the result is reliable. The stages after it, output review and communication, determine whether the result is used correctly. The model run itself is the fastest stage and the one requiring the least analytical judgement. Treating it as the main event misallocates attention.
Software speeds up computation (Stage 05) and can assist with geocoding tools (Stage 03) and output formatting (Stage 07). It does not speed up the analytical judgement required at Stages 01, 02, and 06, the stages where a practitioner needs to recognise what is wrong, why it matters, and what to do about it. Those stages take time proportional to the complexity of the submission and the experience of the analyst, not to the processing power of the software.
Stage 06 catches problems that are visible in the output, results that look anomalous relative to expectations. It does not catch problems that produce plausible-looking but wrong results. A coordinate error that places a building in a similar-hazard location to the actual building will not show up as anomalous output. The Stage 06 review is a necessary but not sufficient quality check, it catches obvious problems, not systematic ones.
Stage 07 is communication and decision, and the decision belongs to the underwriter. What happens after Stage 07, binding or declining, at what price, with what conditions, feeding into the portfolio accumulation model, is downstream of the cat modelling workflow but directly connected to it. The quality of the workflow determines the quality of the information the underwriter has when they make that decision.
The ordered sequence of stages from submission receipt to pricing decision. Each stage has a defined input and output and depends on the quality of the preceding stage's output. The structure reflects the logical dependencies in how models work.
The package of documents received from a broker when a risk is offered for consideration. For a property cat risk, typically includes the SOV, the policy slip, and supporting technical documents. The starting point of the workflow.
Stage 02 of the workflow, the systematic review of exposure data for gaps, errors, and limitations before the model is run. The stage that determines what the model can and cannot be trusted to produce. Cannot be replaced by the model's own defaults.
Stage 06 of the workflow, review of model results before presenting to underwriting. Checks for anomalous location-level results, implausible contributions relative to TIV, and flags from upstream data quality stages. The last line of defence before results reach a decision-maker.
A documented record of a model run, what inputs were used, what settings were configured, what data quality issues were noted, and what caveats apply to the output. The audit trail that makes results reproducible and explainable. Required for regulatory submissions and professional review.
The formatted exposure file produced at Stage 03 that is loaded into the cat model platform. The model cannot read a raw SOV, the exposure data must be mapped to the model's required field structure and format before import. The quality of the import file determines the quality of the model output.
Five questions · 4 of 5 correct (80%) to pass