Designing Bottom-Up Risk Modules

Why Bottom-Up Modules Need Explicit Design

A bottom-up capital model builds enterprise results from defined risk components. That structure is useful only when each component has a clear purpose and a dependable interface with the rest of the model. A module that reports an unexplained number, uses a different loss basis, or silently changes its units can make an enterprise result difficult to interpret and unsafe to use.

The earlier material on model boundaries, exposure granularity, loss bases, and architecture establishes the context for a module. The design task here is more specific: define what enters a risk calculation, how those inputs are transformed, what the module returns, and what controls ensure that its results can be used consistently. A module should be detailed enough to quantify its assigned risk, but should not duplicate losses assigned to another component.

Definition: A bottom-up risk module is a bounded calculation component that transforms specified exposure, assumption, and configuration inputs into defined risk outputs for a stated loss basis and measurement horizon. Its interface specifies both the information it receives and the format, meaning, and limitations of the results it returns.

The module is not merely a spreadsheet tab or software function. It is a documented calculation contract. The contract should say which exposures are in scope, which loss events are included, which transformations are applied, and how outputs are labeled. It should also identify assumptions and exclusions that affect how the results can be interpreted.

Specify Inputs, Transformations, and Outputs

A well-designed module keeps three things distinct: inputs, the calculation, and outputs. Inputs may include exposure records, risk parameters, contract terms, and model settings. Transformations convert those inputs to the loss quantity being measured. Outputs report that quantity in a form the enterprise model can interpret.

Interface element	Questions the specification must answer
Inputs	Which exposures and assumptions are required? What are their units, effective dates, and permitted ranges?
Transformations	How are exposure data, loss events, limits, deductibles, and other specified terms converted to the modeled loss?
Outputs	Which loss statistics or distributions are returned? What currency, horizon, basis, and calculation version do they use?
Controls	How are completeness, validity, units, scope, and reconciliation checked before results are accepted?

Output design should be driven by intended use. If an enterprise calculation needs a component loss distribution, returning only expected loss is not enough. If the intended interface is a set of specified statistics, each statistic needs a precise definition—for example, whether a reported capital amount is a loss quantile or a quantile less a stated reference value. A number without its basis and definition is not a complete output.

A module should also identify what it does not do. A component may return gross losses before reinsurance, for example, while a separate specified transformation produces net losses. Alternatively, the module may apply a defined reinsurance treatment internally. Either approach can be coherent, but the boundary must be explicit so the same contract is not applied twice or omitted.

From Exposure Data to a Defined Loss

Consider a frequency-severity module. Let $N$ be the number of claims in the measurement period, $X_j$ the loss amount on claim $j$, and $Y^L_j$ the payment per loss after applying the module’s specified contract terms. The aggregate payment is $L=\sum_{j=1}^{N}Y^L_j$, with $L=0$ when $N=0$. The terms “per loss” and “per payment” must not be confused: the payment per loss is the amount associated with an individual loss, while an annual aggregate is the sum across losses in the period.

For a simple illustration, suppose $N$ has a Poisson distribution with parameter $\lambda$, and claim payments $Y^L_j$ are independent and identically distributed, independent of $N$, with finite first and second moments. Then:

E[L]=\lambda E[Y^L], \qquad \operatorname{Var}(L)=\lambda E[(Y^L)^2].

The variance expression uses the second moment of payment per loss, not its variance alone. To see why, condition on the claim count. Given $N=n$, the sum has mean $nE[Y^L]$ and variance $n\operatorname{Var}(Y^L)$. The law of total variance gives:

\begin{aligned} \operatorname{Var}(L) &=E[\operatorname{Var}(L\mid N)] +\operatorname{Var}(E[L\mid N])\\ &=E[N]\operatorname{Var}(Y^L) +\operatorname{Var}(N)(E[Y^L])^2\\ &=\lambda\operatorname{Var}(Y^L)+\lambda(E[Y^L])^2\\ &=\lambda E[(Y^L)^2], \end{aligned}

where the last equality uses the Poisson assumption $E[N]=\operatorname{Var}(N)=\lambda$. This result does not apply automatically to every frequency model; for example, a non-Poisson count distribution generally changes the variance expression. The module specification must therefore state the frequency and severity assumptions actually used.

Worked Example: Specifying and Quantifying a Claims Module

A hypothetical insurer models one year of claims for 500 policies. Each policy has a Poisson claim count with mean 0.08, independent across policies. Claim severities $X$ are independent of counts and uniformly distributed from $0 to $10,000. The policy pays the amount above a $1,000 per-claim deductible, with no payment limit. Calculate the expected annual payment, its variance, and standard deviation for the module output.

Method and assumptions. The aggregate claim count is Poisson with parameter $500(0.08)=40$, because independent Poisson counts add. For a severity $X$, the payment per loss is $Y^L=(X-1{,}000)^+$, where $z^+=\max(z,0)$. The payment is zero when $X\leq1{,}000$.

Step 1: Calculate the mean payment per loss. The uniform density is $1/10{,}000$ on the interval from $0 to $10,000. Thus:

E[Y^L] =\frac{1}{10{,}000}\int_{1{,}000}^{10{,}000}(x-1{,}000)\,dx =\frac{9{,}000^2}{2(10{,}000)} =\$4{,}050.

Step 2: Calculate the second moment per loss.

E[(Y^L)^2] =\frac{1}{10{,}000}\int_{1{,}000}^{10{,}000}(x-1{,}000)^2\,dx =\frac{9{,}000^3}{3(10{,}000)} =\$24{,}300{,}000.

Step 3: Calculate annual aggregate measures. The Poisson parameter is $\lambda=40$, so:

E[L]=40(\$4{,}050)=\$162{,}000, \qquad \operatorname{Var}(L)=40(\$24{,}300{,}000) =\$972{,}000{,}000.

The standard deviation is $\sqrt{\$972{,}000{,}000}=\$31{,}176.91$, rounded to the nearest cent. As a check, the expected annual count is 40 and the average payment per claim is $4,050, so the expected aggregate payment is 40 times $4,050, or $162,000. The module output should label these as one-year payments net of the specified per-claim deductible, in dollars, under the stated frequency and severity assumptions.

Common mistake avoided: Applying the deductible to the annual aggregate rather than to each claim would define a different contract transformation. Here the deductible is applied to each $X_j$ before summing claim payments.

Outputs Must Match the Enterprise Interface

A component can return a full distribution or a specified set of summaries. The enterprise model must know which it receives. For example, a module may return $E[L]$, $\operatorname{Var}(L)$, and a stated quantile of $L$; it may instead return simulated annual losses with a defined scenario identifier and ordering. These alternatives are not interchangeable without additional assumptions and calculations.

If a component reports a capital measure, its definition should include its probability level, loss basis, and any reference amount subtracted. For instance, if the module uses $\operatorname{VaR}_p(L)=\inf\{x:F_L(x)\geq p\}$, and defines component capital as $\operatorname{VaR}_p(L)-E[L]$, then both parts of that definition belong in the interface. The component capital is not itself the same thing as the loss distribution.

Worked Example: Translating a Component Distribution into a Capital Output

A hypothetical module covers two independent assets over one year. Each asset has a 0.10 probability of a $100,000 loss and a 0.90 probability of no loss. The module reports the 95% value at risk and defines its capital output as that value at risk less expected loss. Calculate the reported measures.

Method. Let $K$ be the number of assets with a loss. Independence gives a binomial distribution with two trials and loss probability 0.10. The aggregate loss $L$ is $100,000 times $K$.

The probabilities are $P(K=0)=0.9^2=0.81$, $P(K=1)=2(0.1)(0.9)=0.18$, and $P(K=2)=0.1^2=0.01$. Therefore, the cumulative probabilities for aggregate losses of $0, $100,000, and $200,000 are 0.81, 0.99, and 1.00, respectively. By the stated quantile definition, $\operatorname{VaR}_{0.95}(L)=\$100{,}000$, since the cumulative probability first reaches at least 0.95 at that loss.

Expected loss is $2(0.10)(\$100{,}000)=\$20{,}000$. The module’s defined capital output is therefore $\$100{,}000-\$20{,}000=\$80{,}000$. As a check, the quantile is at the one-loss outcome because the probability of zero losses is only 0.81, while the cumulative probability after one loss is 0.99.

Common mistake avoided: Reporting the $100,000 quantile as though it were the defined capital output would omit the expected-loss subtraction. The interface should return both values with distinct labels.

Interface Controls and Reconciliation

Controls should test more than whether a calculation completed. They should test whether the calculation received the intended exposures and assumptions, applied transformations in the intended order, and returned values on the intended basis. Useful controls include:

Scope and completeness: reconcile exposure counts or totals to an approved in-scope population, and identify exclusions.
Data validity: check required fields, permitted ranges, missing values, duplicate records, and effective dates.
Unit and basis checks: identify currency, scaling convention, horizon, gross or net basis, and whether amounts are dollars or thousands of dollars.
Calculation checks: test selected outputs against independently calculated cases and confirm that stated transformations are applied once.
Version and run controls: record the data date, assumptions, code or model version, and run settings needed to reproduce the result.
Output reconciliation: compare returned totals and summaries with component-level results and explain material differences.

The controls should be designed around the actual interface. A valid numerical result can still be wrong if, for example, it uses the wrong measurement horizon or is interpreted in the wrong currency unit. An unexplained mismatch is a reason to investigate, not a reason to apply an arbitrary scaling factor.

Worked Example: Diagnosing an Interface Scale Error

A controlled enterprise-model test uses two hypothetical modules. Their expected-loss outputs are $120 thousand and $200 thousand, and the interface specification requires all amounts to be reported in thousands of dollars. The correct combined expected loss is $320 thousand. A deliberately corrupted test run returns $240,080 thousand. Diagnose the scale of the discrepancy and state a suitable control response.

Step 1: Reconcile the expected component outputs. On the specified basis, the total is $120+200=320$ thousand dollars. This expectation reconciliation is valid regardless of dependence because expectation is additive for losses with finite means.

Step 2: Measure the discrepancy. The ratio of the erroneous result to the intended result is:

\frac{240{,}080}{320}=750.25.

The erroneous total is therefore 750.25 times the intended total. The absolute difference is $240{,}080-320=239{,}760$ thousand dollars. These calculations quantify the mismatch; they do not, by themselves, establish its root cause.

Step 3: Apply the interface controls. Reject the test result, verify that both modules supplied thousands rather than dollars, and trace the returned values through the input mapping and any aggregation transformations. Re-run the controlled test after identifying and correcting the defect, then confirm that the output reconciles to $320 thousand.

Common mistake avoided: Rounding the ratio to 751 and treating that as the exact discrepancy is incorrect; $240{,}080/320=750.25$. More importantly, a large ratio is not a complete control. The defined reconciliation—expected module totals versus enterprise total, on a stated unit basis—provides a reproducible check.

Common Design Traps

Modular design can create a false impression that component outputs are automatically comparable or safely additive. The following distinctions should remain explicit:

Expected loss versus capital: an expected loss, a quantile, and a quantile-minus-mean measure are different outputs and need separate labels.
Component quantile versus enterprise quantile: component quantiles generally cannot be added to obtain an enterprise quantile. The enterprise result requires a defined treatment of joint losses and their dependence.
Gross versus net: a contract adjustment must be assigned to a defined point in the calculation. Applying it twice or not at all changes the modeled loss.
Exposure count versus amount: counts, insured values, and dollar losses have different units. A successful calculation run does not prove that the inputs were interpreted correctly.
Assumptions versus outputs: a reported statistic is interpretable only alongside the assumptions, horizon, and basis that produced it.

A module design is strongest when a reviewer can follow one exposure from source field to modeled loss, identify every transformation, and reproduce the reported output. This traceability supports interpretation and troubleshooting; it does not eliminate the need for an enterprise-level method to handle interactions among component risks.

Key takeaway: Specify every bottom-up module as an explicit contract: defined inputs, documented transformations, labeled outputs, and reproducible interface controls. Component results become useful enterprise-model inputs only when their scope, units, horizon, and meaning are consistent and checked.

Check Your Understanding

For each problem, identify the relevant module calculation or interface check and verify that the stated basis is respected.

A one-year module covers 200 independent policies. Each policy has a Poisson claim count with mean 0.10, and each claim has a fixed payment of $2,000. What are the aggregate claim-count parameter and expected annual payment? (Answer: Poisson parameter $20$; expected payment $40,000.)
Severity $X$ is uniform from $0 to $5,000, and each claim has a $500 deductible with no limit. A module has an expected annual claim count of 20. Find the expected payment per loss and the expected aggregate payment. (Answer: $2,025 per loss; $40,500 aggregate.)
A module’s one-year aggregate loss is $0 with probability 0.512, $50,000 with probability 0.384, $100,000 with probability 0.096, and $150,000 with probability 0.008. Using $\operatorname{VaR}_{0.95}(L)=\inf\{x:F_L(x)\geq0.95\}$, calculate value at risk and capital defined as value at risk less expected loss. (Answer: $\operatorname{VaR}_{0.95}=\$100{,}000$; expected loss $30,000; capital $70,000.)
Three components report expected losses of $75 thousand, $110 thousand, and $40 thousand. What total expected loss should an enterprise reconciliation show, and does this sum require independence? (Answer: $225 thousand; no, expectation is additive without an independence assumption.)
A test fixture has intended module outputs of $85 thousand and $115 thousand, but the enterprise output is $150,200 thousand. Calculate the erroneous-to-intended ratio and name one interface field to check. (Answer: intended total $200 thousand; ratio 751; check, for example, whether the output unit is thousands of dollars.)

What You'll Learn