Personas

You now understand the market, its participants, and the contracts they trade. But who are the people inside these organizations that produce, use, and depend on analytics? Understanding what each persona cares about — and what they need from analytical tools — shapes everything from the data that gets collected to the decisions that get made.

The key personas

The catastrophe modeller

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

What they do:

• Configure and run catastrophe models against the cedent’s exposure data (buildings, locations, insured values)
• Generate loss outputs: SELT and ELT data that represent simulated losses across thousands or millions of scenarios
• 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, inconsistent, or late
• Multiple views of risk — no single model is “right,” so they maintain several and blend them
• Computational performance — model runs can take hours or days; faster turnaround enables better decisions

How they interact with analytics systems:

The cat modeller’s output — the SELT — 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 SELT has geographic detail, geographically filtered contracts can be modeled. If it only has aggregate loss per occurrence, they cannot.

In Practice

Cat modellers and analytics teams tend to speak different languages. The modeller thinks in hazard intensities, vulnerability functions, and event sets. The analytics team thinks in data schemas, transformations, and metrics. The SELT 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
• Analyze 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 — in a hard market, being first to quote a price wins the business. Faster analytics is a competitive advantage

How they interact with analytics systems:

The actuary is the most demanding consumer of analytics. They need custom metrics, unusual contract structures, what-if analyses, and real-time comparisons across scenarios. Whatever tools they use must be powerful enough to express 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. The bridge between mathematical thinking and implementation is a formalism that both sides can read. This is exactly what the concept ladder (Intuition → Formal Definition → Code) in this site is designed to provide.

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 book of business: balance across geographies, perils, and cedent relationships
• Make real-time decisions during renewal season (January 1 is the busiest day in reinsurance)

What they care about:

• Decision speed — during the January renewal, underwriters may evaluate hundreds of contracts in weeks. They need answers fast
• Marginal impact — “What happens to my portfolio if I add this contract?” is the single most important question in underwriting. 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 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 — a well-diversified portfolio generates the same return with less capital
• Tail risk — what happens in the worst 1% of scenarios? Can the company survive it?
• Strategic positioning — is the portfolio positioned for the current 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 is flying blind.

The Chief Risk Officer (CRO)

The 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 regulatory capital requirements — Solvency II in the EU, the Bermuda Solvency Capital Requirement in Bermuda, and Risk-Based Capital standards in the US
• 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 scenarios dominated by a single peril, region, or cedent? Concentration kills
• Model risk — how sensitive are the risk numbers to modelling assumptions? What happens if the model is wrong?

How they interact with analytical tools:

The CRO consumes many of the same metrics as the CUO — VaR, TVaR, capital allocation — but through a different lens. The CUO uses them to optimize 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.

How the personas interact

The workflow forms a loop:

1. The cat modeller produces loss data (SELTs)
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

Key Insight

Every persona in this loop depends on the same underlying computation: applying contract terms to loss scenarios and computing metrics. The difference is the level of aggregation and the perspective. The cat modeller works at occurrence resolution. The actuary works at contract resolution. The underwriter works at portfolio resolution. The CUO works at strategic allocation resolution. The CRO works at the same portfolio resolution as the CUO but through the lens of limits and survival rather than return. The analytical chain must work at the finest resolution 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 optimization 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.

One thread runs through everything we have covered — the market, the participants, the contracts, and the people:

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 loss in a 1-in-100 year scenario? How much capital does this contract consume? What happens to the portfolio if we add one more contract? The Quantification chapter introduces the mathematical foundations to answer these questions.