Applications

The Analytics Toolkit chapter built the analytical foundations: trials, distributions, and metrics. The Financial Modelling chapter showed how contracts transform loss as compositions of financial terms. This chapter connects both to business outcomes.

The goal is not to build a production system. It is to show how the analytical tools and contract compositions assemble into applications that answer real business questions. Every application follows the same pattern: a business problem arrives, the financial terms and metrics compose to answer it, and the output drives a decision.

By the end, you will be able to:

• Turn a cedent’s loss sets into the post-model report an underwriter structures a deal from
• Price a multi-layer program from its subject loss: ceded distribution, capital, technical premium, verdict
• Roll a portfolio of contracts up to one loss distribution and determine the capital it requires, its diversification benefit, and its return on that capital
• Recognise the shape all three stories share (losses and policy in, an artifact a decision is based on out) and what changes at production scale

The stories

Each story is a real task from a reinsurer’s analytics pipeline, and each is self-contained: prerequisites are linked where they matter, so the stories can be read in any order. Following one deal from submission to portfolio, they read naturally in this order:

• Risk profiling: the post-model report: A cedent’s submission has been through the catastrophe models. The cat modeller reconciles the loss sets, summarises the exposure, and characterises the subject loss for the underwriter, before any contract is applied. The Analytics Toolkit, exercised end to end.

• Standalone program pricing: The underwriter takes the risk profile and prices SunCoast’s three-layer renewal. Contract terms transform the subject loss into ceded loss, metrics on the ceded distribution become a technical premium, and the diversification within a program first shows up as a capital number.

• Portfolio analytics: Many priced contracts become one portfolio: the roll-up aggregates them at their participations, portfolio-level metrics quantify the risk posture, and the diversification benefit is computed rather than asserted; the portfolio risk-adjusted return on capital (RAROC) then shows whether the portfolio earns its cost of capital.

• Marginal pricing with portfolio view (planned): The application this chapter is building toward: how one new contract changes portfolio risk and capital in real time, and why that number, not the standalone price, is the one that matters.

At production scale discusses what changes when the stories run on production loss data: trial and row counts, loss-set bookkeeping, currency, reproducibility, and the partition-by-trial shape all three pipelines share. Each story’s page covers the consideration specific to it.

Key Insight

These applications share one computation at different scopes, and standalone pricing is the degenerate case of marginal pricing: with an empty base portfolio, and the contract taken at the same share the standalone metrics are computed on, the marginal capital $\Delta K$ is the whole standalone capital, Tail Value at Risk (TVaR) less expected loss (EL), $K = \text{TVaR}_\alpha - \text{EL}$, so the marginal technical premium reduces to the standalone one. What separates the applications is not the arithmetic but the assembly: which scope, which benchmark, which decision.

This chapter assumes everything from prior chapters: market mechanics from Foundations, metrics from Analytics Toolkit, and the term catalog from Financial Modelling. It also assumes a working intuition for cost-of-capital reasoning (capital held against risk must earn a return), not MBA-level finance, but enough business context to see why analytics exists to support pricing, underwriting, and capital allocation decisions.

Design principle: reproducibility

A financial model must be a pure function of its inputs. Given the same year event loss table (YELT), the same contract parameters, and the same pricing assumptions, the system must produce the same outputs every time. Reproducibility is not a feature. Auditability depends on it, and actuarial modelling standards name reproducibility on rerun among a model’s governance controls.¹

Every application in this chapter is API-only. We define inputs, transformations, and outputs. The presentation layer is out of scope, deliberately. An analytics engine with no presentation dependency can be driven by a batch job, a notebook, or a service without changing its code.

What this chapter does not cover

• User interfaces: no dashboards, no web apps, no Excel outputs. API-only.
• Deployment: no containers, no cloud, no CI/CD. The concepts apply regardless of infrastructure.
• Data engineering: building the pipelines that move and store loss data is an upstream concern. (Validating what those pipelines deliver is not: every story checks its inputs before using them.)
• Regulatory specifics: capital is computed under the site’s unexpected-loss convention at an illustrative confidence level, not a regulatory one. Regulatory frameworks define their own: Solvency II a one-year 99.5% Value at Risk (VaR) of basic own funds, the Swiss Solvency Test an expected shortfall at 99%. The risk measure, the horizon, and the balance-sheet basis all change, and none of that is treated here.

Caldera Re remains the running example. Every number in this chapter reconciles with the results established in Analytics Toolkit and Financial Modelling. The figures recur from page to page. The conventions the stories rely on are indexed on Scope, conventions & assumptions.

The chapter’s closing thesis, which each story earns in its own way: every application composes the same terms and metrics; what makes it an application is the scope it chooses, the decision it drives, and the judgement it is built to support.

Footnotes

1. Actuarial Standards Board, Actuarial Standard of Practice No. 56: Modeling, 2019, Appendix 1, lists “confirmation that model output is reproducible upon rerun” among the examples of model governance and controls, in material marked informational rather than mandatory. EIOPA, “Documentation standards”, Solvency II Single Rulebook (Directive 2009/138/EC, Article 125), requires internal-model documentation to set out “the theory, assumptions, and mathematical and empirical bases underlying the internal model”, which is the audit trail this principle serves; the article does not use the word reproducible. ↩