Why Scenario Architecture Matters
An enterprise stress scenario is more than a severe event described in a sentence. A statement such as “a major storm causes losses” leaves important questions unanswered: Which parts of the enterprise are exposed? Which kinds of risk are in scope? Is the assessment concerned with the event day, the following year, or both? Which financial results should decision-makers review?
Scenario architecture is the disciplined specification of those elements before the scenario is quantified. It gives analysts, management, and reviewers a shared scope. It also helps distinguish a deliberate boundary from an accidental omission. This tutorial is aligned with the CAS Exam 9 (Risk Management for Actuaries) syllabus.
The Five Elements of a Scenario
A useful scenario record makes each element explicit. The elements are related, but they answer different questions. In particular, a business line identifies where the enterprise is exposed, while a risk category identifies what kind of risk is being considered.
| Element | Question it answers | What a clear specification includes |
|---|---|---|
| Trigger | What adverse event or condition defines the scenario? | A bounded event, including relevant location, timing, or duration where needed |
| Business lines and operations | Which parts of the enterprise are in scope? | Named products, operating units, legal entities, or shared functions |
| Risk categories | Which forms of financial or operational exposure are assessed? | Named categories, with any material exclusions stated |
| Time horizon | Over what period is the scenario assessed? | The stress period, projection period, and dates at which results are reported |
| Financial outcomes | What results will be examined? | Defined measures, such as underwriting result, expenses, asset value, liquidity, or capital resources |
The trigger should be specific enough to distinguish the scenario from a general risk theme. “Severe weather” is broad; “a windstorm makes the company’s principal claims-processing site unavailable for five days” describes a more bounded trigger. Naming the trigger does not imply a probability or a loss estimate.
Business-line scope should reflect the intended decision. A scenario may include every product line, or only selected lines and shared operations. Risk categories should then be listed separately. For example, a claims-system outage may be assessed for operational expense and underwriting effects. The fact that the scenario has one trigger does not mean it belongs to only one risk category.
The horizon must also be unambiguous. An event may be brief while its consequences are assessed over a longer projection period. A scenario can therefore identify both the duration of the initiating event and the dates or period over which financial outcomes are examined. A result measured at the end of a year should not be mistaken for an event that lasts a year.
Finally, state the outcomes to be reviewed in measurable terms. “Financial impact” is not sufficiently precise on its own. Depending on the purpose, outcomes could include incremental claims, operating expenses, investment value, available liquidity, or capital resources. The selected measures should be consistent with the decision at hand; listing every conceivable measure can obscure the scenario’s purpose.
A Completeness Check
A simple completeness check treats the five elements as required fields. Let \(I_T,I_B,I_R,I_H,I_O\) each equal 1 when the trigger, business-line scope, risk-category scope, horizon, and outcomes are respectively specified, and 0 otherwise. Define the record’s field-completeness indicator as:
Because every factor is either 0 or 1, \(C=1\) only when all five fields are present. If even one field is missing, its indicator is 0 and the product is 0. This is a checklist, not a measure of scenario severity, probability, or quality. A filled field can still be vague, so reviewers must also test whether each specification is precise enough to guide consistent analysis.
A second useful check is cross-consistency: each named outcome should make sense for the chosen business scope, risk categories, and horizon. For instance, an assessment of claims expense should identify which claims operation or line is in scope and when the expense is measured. This check identifies a design gap; it does not prescribe how to model the outcome.
Worked Scenario Designs
Worked Example: A Claims-Processing Site Outage
A hypothetical insurer wants a scenario for a five-day outage at its only claims-processing site after a localized building failure. The planning team proposes assessing personal auto and homeowners business. Specify the architecture, identify a scope ambiguity, and calculate the total of the supplied illustrative financial outcomes.
Method. Separate the initiating event from the exposed operations, categories, horizon, and measures. The stated trigger is a five-day unavailability of the claims site. The affected business lines are personal auto and homeowners; the shared claims operation should also be named because it is the function directly affected.
For this scenario, the selected risk categories are operational risk and underwriting risk. The horizon is the five-day outage plus a 12-month projection period, with results reported at the end of the outage and at the end of month 12. These dates make clear that the event duration and the period used to assess outcomes are different.
The team provides illustrative 12-month outcomes: incremental claims expense of $1.25 million, additional claim-related payments of $2.40 million, and an estimated $0.35 million reduction in underwriting result from delayed processing. For a simple total of these stated adverse outcomes:
The computed total is $4.00 million. The calculation only adds the three supplied measures; it does not establish that they are economically independent or that this is an appropriate capital measure. The scope ambiguity is whether “claim-related payments” are a separate outcome from the underwriting-result reduction. The team must define the measures and check for overlap before interpreting their sum. A common mistake is to call the outage itself the full scenario and omit the affected claims operation, assessment dates, or outcome definitions.
Worked Example: A Regional Windstorm and Multiple Business Lines
A hypothetical insurer designs a scenario for a windstorm that closes two coastal offices and damages insured commercial properties. The purpose is to review results across commercial property and inland marine business. At the 12-month assessment date, the scenario team supplies illustrative amounts: commercial property claims of $8.60 million, inland marine claims of $1.40 million, and additional operating expense of $0.75 million. Build the architecture and calculate the total of these listed amounts.
Step 1: Define the trigger. The trigger is a windstorm affecting the specified coastal region, damaging insured commercial property and closing two company offices. The locations and closure are part of the hypothetical event definition; no probability or severity calibration is implied.
Step 2: Set the scope. The business lines are commercial property and inland marine. The affected operations are the two coastal offices. The included risk categories are underwriting risk for the insured losses and operational risk for the additional office-related expense. Naming both categories prevents the operating disruption from disappearing inside a claims-only description.
Step 3: State the horizon and outcomes. Assess the event over its immediate occurrence and report the specified financial outcomes at month 12. The outcomes are claims by business line and additional operating expense. The supplied amounts are already scenario outputs; this example does not derive them from a storm model.
Step 4: Add the listed amounts. First combine claims across the two named lines: \( \$8.60+\$1.40=\$10.00 \) million. Then include the stated expense: \( \$10.00+\$0.75=\$10.75 \) million. Thus the total of the three listed adverse amounts is $10.75 million.
Check. The total is greater than the $10.00 million in claims by exactly $0.75 million, matching the stated operating expense. This arithmetic is valid as a sum of the listed amounts, but a decision-maker should confirm that the measures are on a consistent basis and do not overlap. A common mistake is to name the storm and the property line but leave the operating effect and its risk category outside the scenario description.
Worked Example: A Payment-Network Interruption
A hypothetical insurer is reviewing a 36-hour interruption of a national payment network during a month-end processing period. The intended scope includes annuity administration and group-benefit operations. The team plans to assess delayed payments, additional processing expense, and available liquidity at 48 hours and at month-end. Determine whether the architecture is complete and use the supplied amounts to calculate the listed 48-hour cash requirement.
Trigger. A 36-hour interruption of the named payment network during month-end processing is bounded by event, duration, and timing.
Business and risk scope. The business operations are annuity administration and group-benefit operations. The included categories are operational risk, for processing disruption and additional expense, and liquidity risk, for the timing of cash needs. The scope names both operations rather than assuming that one business line represents the entire enterprise response.
Horizon and outcomes. The event lasts 36 hours. Results are assessed at 48 hours and month-end. The listed outcomes are delayed payments, processing expense, and available liquidity. These fields are complete for the stated purpose.
For the 48-hour liquidity assessment, the hypothetical team estimates that $2.80 million of payments are due and that $1.10 million of receipts are available to offset those payments. The net cash requirement, using the provided amounts, is:
The 48-hour net requirement is $1.70 million. The check is that adding the available receipts back gives the stated payments: \( \$1.70+\$1.10=\$2.80 \) million. This is a defined cash-flow comparison, not a conclusion about the insurer’s overall liquidity adequacy. A common mistake is to use the 36-hour outage duration as the only assessment date, even though the scenario explicitly calls for results at 48 hours and month-end.
Common Design Errors
Scenario architecture is useful only when different reviewers can identify the same scope from the written record. The following errors can produce inconsistent interpretations even before any quantitative model is used.
- Using a theme instead of a trigger. “Cyber stress” does not specify the event. State the hypothetical incident or condition that defines the scenario.
- Conflating business lines and risk categories. A product line is an exposure location; an operational or market risk category describes a type of exposure. Record both where relevant.
- Leaving the horizon implicit. State the event duration, projection period, and assessment dates needed for the decision. Do not treat them as interchangeable.
- Writing “financial impact” as the only outcome. Name the measures to be assessed, and define any potentially overlapping measures before combining them.
- Assuming a complete list is a complete analysis. Filling all five fields supports consistent scoping, but does not establish scenario plausibility, quantify shocks, or determine capital effects.
The purpose of architecture is to make the scenario’s boundaries and intended outputs visible. Subsequent analysis may quantify the event, examine how it affects exposures, and evaluate resulting financial positions. Those tasks depend on a clear specification, but they are not substitutes for it.
Check Your Understanding
For each original scenario below, identify the architectural issue or calculate the requested amount using only the supplied data.
- A hypothetical hail event affects farm property policies. The scenario lists farm property as the business line and claims as the only outcome, but says neither when results are measured nor whether claims expense is included. Name two missing or ambiguous fields. (Answer: The time horizon or assessment date is missing, and the outcome definition is ambiguous because claims expense is not addressed.)
- A hypothetical 72-hour outage affects a life insurer’s policy-administration unit. The proposed assessment names individual life and group life, operational risk, a 90-day projection, and additional expenses at day 90. What distinct duration and assessment period should be recorded? (Answer: Record the 72-hour outage duration separately from the 90-day projection period and day-90 assessment date.)
- A hypothetical regional flood scenario lists commercial property claims of $5.20 million, equipment claims of $0.80 million, and operating expense of $0.40 million at month 12. Calculate the total of these supplied amounts. (Answer: $6.40 million.)
- A hypothetical data-center interruption affects both claims administration and premium collection. The scenario includes operational and liquidity risk, lasts two days, and assesses operating expense at day 30 and available liquidity at day 2. Is the architecture internally consistent as stated? Explain the key timing distinction. (Answer: Yes, if both operations are explicitly in scope; the two-day event duration is distinct from the day-2 liquidity and day-30 expense assessment dates.)
- A hypothetical market closure affects a company’s investment operation and its retirement-products business. The stated outcomes are asset-value change at month 1 and capital resources at month 12. Identify the minimum additional specification needed to make this architecture complete. (Answer: State the triggering event or condition, explicitly name the included risk categories, and clarify the projection horizon spanning the month-1 and month-12 assessment dates.)