Personas

You now understand the market, its participants, and the contracts they trade. But who are the people inside these organisations that produce, use, and depend on analytics? What each persona cares about, and what they need from analytical tools, determines which data a reinsurer collects and which decisions it can defend. These are the analytics-facing roles; a reinsurer’s full organisation also includes claims, finance, exposure management, and governance functions, which appear here only where they touch the analytics.

The personas

Five roles produce, consume, or depend on the analytics. Each asks a different question of the same loss data, at a different resolution, and each question becomes a requirement on the system:

Persona	The question they ask	Finest resolution they need	What the system must provide
Cat modeller	Are the simulated losses realistic, and structured for what comes next?	Row: one occurrence by geography and line of business	A YELT whose resolution supports every contract downstream
Actuary	What is this risk, and what should it cost?	Contract, per trial	Expressive terms, custom metrics, and traceable intermediate results
Underwriter	Write it or not, at what price, and what does it do to the portfolio?	Contract and portfolio	Standalone and marginal answers inside renewal-season time
CUO	Is the portfolio earning its capital, and where should the next dollar go?	Portfolio	A rolled-up portfolio with capital, return, and allocation views
CRO	Can the company survive the risk it carries?	Portfolio tail, by peril, region, and cedent	Limits, stress tests, and sensitivities on the same numbers

The catastrophe modeller

The catastrophe modeller, cat modeller for short, is the person closest to the raw science. They operate the catastrophe models: complex simulation engines that produce the loss data everything else depends on, built by vendors such as Moody’s RMS, Verisk, and Cotality (formerly CoreLogic), or developed internally.

What they do:

• Configure and run catastrophe models against the cedent’s exposure data (buildings, locations, insured values)
• Generate loss outputs: the year event loss table (YELT), which groups simulated losses into 10,000 to 1,000,000+ trials (the simulated futures the Analytics Toolkit defines precisely), and the event loss table (ELT), which lists event-level losses with annual rates and no trial context
• Adjust model parameters to reflect different views of risk (vendor model A vs. vendor model B, with or without climate change adjustments)
• Validate model outputs against historical losses and engineering judgment

What they care about:

• Model fidelity: are the simulated losses realistic? Do they capture the physics of the peril correctly?
• Data quality: exposure data from cedents is often incomplete or inconsistent, and the model output is sensitive to how precise and how accurate it is¹
• Multiple views of risk: no single model is authoritative, so they run several and compare them, and for pricing they weight the results into one view; the weighting is used for pricing more often than for measuring the portfolio’s total exposure to a peril²
• Computational performance: the runs are scheduled jobs rather than interactive queries, so turnaround sets how often a revised view of risk reaches the people downstream. No public measurement of vendor model run times turned up for this site; the published timings are for the post-model simulation the analytics team runs³

How they interact with analytics systems:

The cat modeller’s output, the YELT, is the input to everything downstream. The quality, structure, and resolution of that data determines what the rest of the analytical chain can do. If the YELT has geographic detail, geographically filtered contracts can be modelled. If it carries only a loss per occurrence with no geographic breakdown, they cannot.

In Practice

Cat modellers and analytics teams describe the same data with different vocabularies. The modeller thinks in hazard intensities, vulnerability functions, and event sets. The analytics team thinks in data schemas, transformations, and metrics. The YELT is the handoff point, and getting its structure right is one of the most consequential decisions in the analytical workflow, because every downstream computation depends on it.

The actuary

The actuary is the quantitative analyst of the reinsurance world. They take the cat modeller’s loss data and compute the risk metrics, capital requirements, and pricing that drive business decisions.

What they do:

• Compute risk metrics: expected loss (EL), exceedance probability (EP) curves, Value at Risk (VaR), Tail Value at Risk (TVaR)
• Calculate capital requirements based on regulatory frameworks and internal risk appetite
• Price contracts: determine the premium that compensates for the risk being taken
• Analyse portfolio composition: which contracts diversify each other, where is risk concentrated, what is the marginal impact of a new contract

What they care about:

• Correctness: a pricing error of 1% on a $50M contract is a $500K mistake. Actuaries are obsessively precise
• Transparency: every number must be traceable back to its inputs. “Black box” systems are unacceptable
• Flexibility: actuaries constantly adjust assumptions, parameters, and methodologies. Systems that are rigid or hard to reconfigure are useless
• Speed: the underwriter’s quote rests on the pricing. Renewals concentrate in a few weeks of the year, the renewal period, so pricing turnaround limits how many submissions the team can evaluate. Faster analytics is a competitive advantage

How they interact with analytics systems:

The actuary’s requirements set the system’s ceiling: custom metrics, unusual contract structures, what-if analyses, and real-time comparisons across trials. Whatever tools they use must be expressive enough to state their requirements and transparent enough to let them verify every intermediate result.

In Practice

The most effective communication medium between actuaries and analytics teams is a shared computational artifact: a Jupyter notebook, a spreadsheet, or an API with clear inputs and outputs. What connects mathematical thinking and implementation is a formalism that both sides can read. Every concept on this site arrives with its intuition, its formal definition, and its code for that reason.

The underwriter

The underwriter makes the business decision: whether to write a contract, at what price, and on what terms. They combine the actuary’s quantitative analysis with qualitative judgment about the cedent relationship, market conditions, and strategic fit.

What they do:

• Evaluate individual contract opportunities: is this risk attractively priced given our portfolio?
• Negotiate terms with cedents and brokers: attachment, limit, premium, reinstatements
• Manage their part of the portfolio: balance across geographies, perils, and cedent relationships
• Make decisions against renewal deadlines, and most of them at once: more business incepts at 1 January than on any other date

What they care about:

• Decision speed: the inception date is fixed and the submissions arrive together, so an answer that arrives after the placement is settled is worth nothing. Quoting is the underwriter’s job, done in conversation with the broker while the terms are negotiated, and the quotes the broker collects set the firm order terms the following market subscribes to. Reinsurers name responsiveness to quote requests among the things that win them business.⁴ The firm order price is one price for everyone, so what an early answer competes for is the size of the signed line: an oversubscribed placement is signed down, and the broker and the cedent decide whose line stands. In this site’s assessment, in a hard market or a soft one, the reinsurer that answers early is more likely to keep the line it quoted for
• Marginal impact: “What happens to my portfolio if I add this contract?” is the question underwriting analytics exists to answer. It requires portfolio-level analytics
• Comparability: “How does this year’s renewal compare to last year’s?” requires consistent metrics across time periods
• Simplicity at the surface: underwriters are not technical users. They want dashboards and summaries, not raw data. But the summaries must be backed by rigorous computation

How they interact with analytics systems:

The underwriter is the decision-maker. The ultimate value of any analytical capability is measured by whether it helps underwriters make better decisions faster. The question they ask most often: given a new contract proposal, what is the standalone price and the marginal impact on the portfolio?

The Chief Underwriting Officer (CUO)

The chief underwriting officer (CUO) sits at the top of the underwriting function. They set the strategy: risk appetite, target portfolio composition, capital allocation, and return objectives.

What they do:

• Define the company’s risk appetite: how much catastrophe risk to take, in which regions, for which perils
• Allocate capital across the portfolio: which contracts and regions get priority
• Set return targets: the portfolio must generate sufficient return on the capital deployed
• Report to the board and regulators on the company’s risk position

What they care about:

• Portfolio-level view: the CUO does not think about individual contracts; they think about the portfolio as a whole
• Capital efficiency: how much return is generated per unit of capital at risk
• Diversification: risks that do not lose together need less capital together than apart,⁵ so a well-diversified portfolio can earn the same return on a smaller capital base; the portfolio view computes that benefit on the Caldera Re book
• Tail risk: what happens in the worst 1% of trials? Can the company survive it?
• Strategic positioning: is the portfolio positioned for the current phase of the market cycle?

How they interact with analytics systems:

The CUO needs strategic analytics: portfolio-level metrics, capital allocation breakdowns, diversification analyses, and scenario stress tests. They do not interact with analytical tools directly. They consume outputs through dashboards and reports prepared by actuaries and underwriters. But if the underlying analytics cannot aggregate from individual contracts up to portfolio-level views, the CUO has no reliable view of the position they are managing.

The Chief Risk Officer (CRO)

The chief risk officer (CRO) owns the risk management framework. Where the CUO asks “how do we make money from risk?”, the CRO asks “can we survive the risk we’re taking?”

What they do:

• Define and enforce risk limits: probable maximum loss (PML), aggregate exposure caps, single-event tolerances
• Monitor compliance with the regulatory capital frameworks the company reports under
• Stress-test the portfolio against extreme but plausible scenarios: what happens if a Category 5 hurricane hits Miami and capital markets crash simultaneously?
• Report the company’s risk position to the board, regulators, and rating agencies

What they care about:

• Solvency: the company must be able to pay all claims even in extreme scenarios. This is non-negotiable
• Regulatory compliance: capital models must satisfy regulators, and assumptions must be defensible
• Tail concentration: are the worst trials dominated by a single peril, region, or cedent? A concentrated tail is what turns a large loss into an insolvency
• Model risk: how sensitive are the risk numbers to modelling assumptions? What happens if the model is wrong?

How they interact with analytics systems:

The CRO consumes many of the same metrics as the CUO (VaR, TVaR, capital allocation) but for a different purpose. The CUO uses them to optimise return; the CRO uses them to enforce limits. The CRO also needs scenario-based stress tests that go beyond the standard model: hypothetical scenarios, reverse stress tests (“what loss would breach our capital?”), and sensitivity analyses that reveal how fragile the numbers are. Monitoring the limits themselves (tracking aggregate exposure and PML against risk appetite, zone by zone, as the portfolio changes) is a reporting discipline built on these metrics; this site teaches the metrics and leaves the monitoring out of scope.

None of the five works alone: each role’s output is another role’s input, and limits and strategy flow back the other way.

How the personas interact

The five roles form a closed loop, and the loop is what the analytics chain has to serve.

1. The cat modeller produces loss data (YELTs)
2. The actuary transforms loss data into risk metrics and prices
3. The underwriter uses metrics and prices to make contract decisions
4. The CUO sets strategy based on portfolio-level analytics
5. The CRO enforces risk limits and regulatory constraints: these constrain what the CUO can allocate and what the underwriter can write
6. Strategy and limits flow back down: capital allocation decisions change what the actuary prices and what the underwriter can write
7. New contracts or changed assumptions flow back to the cat modeller for updated model runs

One contract passes around the loop as the underwriting workflow: the broker’s submission arrives, the cat modeller models it, the actuary and the underwriter work the deal and quote, the cedent and its broker settle firm order terms, and the contract is bound and runs to its expiry. Most contracts run for twelve months, so the workflow repeats with each renewal cycle.

In the running example the loop is SunCoast’s renewal at Caldera Re. The cat modeller runs SunCoast’s exposure through the vendor models and writes the post-model report that characterises its subject loss. The underwriter and actuary price the three-layer program (C1, C2, and C3) standalone against that report’s metrics. The CUO works from the analytics of the portfolio those layers join, and the CRO holds the same portfolio to its limits. The same YELT carries through every step.

Key Insight

Every persona in this loop depends on the same underlying computation: applying contract terms to per-trial losses and computing metrics. The difference is the level of aggregation and the perspective. The table at the head of this page records the finest resolution each role needs. The analytical chain must compute at the finest of them and aggregate upward: you cannot derive occurrence-level detail from portfolio-level summaries, but you can always go the other way.

Why the domain matters

The analytical challenge of reinsurance is not that the math is hard. The statistics, probability theory, and optimisation are well understood. The challenge is that the domain is hard: dozens of contract structures, interacting terms, multiple perspectives, portfolio-level dependencies, and a business that demands both precision and speed. Getting the domain right is the prerequisite for getting the analytics right.

Reinsurance is a capital allocation problem driven by tail risk and structured through contracts.

To make capital allocation decisions under tail risk, you need to quantify the risk. What is the expected loss? What is the 1-in-100-year loss? How much capital does this contract consume? What happens to the portfolio if we add one more contract? The Analytics Toolkit chapter introduces the mathematical foundations to answer these questions. The Applications chapter then shows the personas at work: the cat modeller’s post-model report, the underwriter’s standalone program pricing, and the CUO’s portfolio view.

Footnotes

1. Dickie Whitaker, Catastrophe Modelling, Oasis Loss Modelling Framework, 2016: “Incomplete geocoding or geospatial data, or incorrect data … are contributory causes to uncertainty”, and the model output is sensitive to the granularity and accuracy of the exposure data it is given. ↩

2. Alan Calder, Andrew Couper, and Joseph Lo, Catastrophe Model Blending: Techniques and Governance, Institute and Faculty of Actuaries, 2012. Sets out why more than one model is used, describes comparing models and taking weighted averages as common practice in pricing, notes that the weighting step is less often carried through to accumulations, and records that S&P preferred at least two models when assessing catastrophe bond risk and that A.M. Best’s baseline treatment of multiple model output is a straight average. ↩

3. Blesson Varghese and Andrew Rau-Chaplin, “Data Challenges in High-Performance Risk Analytics”, Risk Analytics Lab, Dalhousie University, 2013. Measures the post-model aggregate simulation rather than the vendor model’s own run: at portfolio scale “a weekly simulation can be performed with limited possibility for a real-time simulation”, while a single contract’s million-trial aggregate simulation runs in seconds. ↩

4. Donald Mango, Reinsurance Market Microstructure, ASTIN Colloquium, International Actuarial Association, 2007. Places the broker’s solicitation of quotes, the setting of firm order terms, and the subscription of the following market in sequence, and describes the placement as a blind auction in which reinsurers never see each other’s quotes. Platinum Underwriters Holdings, Form S-1/A, SEC EDGAR, 2002: “operating as a lead or quoting reinsurer will result in our receiving solicitations from brokers for a broader range of business and provide us with greater access to preferred risks.” Third Point Reinsurance, Form 10-K for 2020, SEC EDGAR, 2021, lists “rapid and substantive responses to structuring and pricing quote requests” among the ways it seeks to become the first choice of brokers and clients. ↩

5. EIOPA, “Calculation of the Basic Solvency Capital Requirement”, Solvency II Single Rulebook (Delegated Regulation (EU) 2015/35, Art. 87). The Basic SCR aggregates the risk modules through the Annex IV correlation matrix rather than summing them, so imperfectly correlated risks require less capital together than apart. Michael Sherris, Risk Based Capital and Capital Allocation in Insurance, Institute of Actuaries of Australia Biennial Convention, 2007, which states that enterprise-wide risk-based capital “has to allow for a diversification benefit”. ↩