Tutorials › CAS Exam 9 - Risk Management for Actuaries › Taxonomy Hierarchies and Category Boundaries

CAS Exam 9 · Risk Concepts and Taxonomies · Tutorial 18 of 995

Taxonomy Hierarchies and Category Boundaries

Learn to use a clear hierarchy and explicit boundary rules to classify risk events consistently and roll categories up without double counting.

Beginner 10 min read

What You'll Learn

  • Distinguish a risk category from a particular risk event or consequence
  • Read parent-child relationships in a hierarchical taxonomy
  • Write inclusion and exclusion rules that clarify category boundaries
  • Assign an event to the most specific category supported by the facts
  • Roll up classified items only when the categories and measures permit aggregation
  • Identify boundary errors such as double counting and forced classification

Why Hierarchies Need Clear Boundaries

An enterprise risk taxonomy gives an organization a consistent structure for describing risk. A broad category such as operational risk is useful for an enterprise-wide view, but it may be too general for monitoring a particular exposure. Dividing a broad category into narrower categories makes the structure more informative. That division works only when users can tell what belongs in each category and where one category ends and another begins.

A category is a label for a class of risks; an event is a particular occurrence. For example, “technology availability risk” is a category, while a hypothetical outage of a claims system on a specified day is an event. A missed payment or a customer complaint could be consequences of that outage, but neither consequence is the category itself. Keeping these terms separate makes classification and reporting more consistent.

Definition: A risk taxonomy hierarchy is an organized set of categories arranged at different levels of generality. A parent category is a broader category that contains narrower child categories. A boundary rule states which risks or events belong in a category and, where needed, which similar items do not.

For instance, an organization might place technology availability and process execution under operational risk. A report can then use “operational risk” when a broad view is needed, or a child category when more detail is useful. The labels alone are not enough: a written definition must make clear how an item is assigned, especially when two labels sound plausible.

Parent-Child Relationships

The parent-child relationship expresses containment: an item classified in a child category is also included in its parent category. A useful hierarchy proceeds from broad categories toward increasingly specific ones. For example, a hypothetical insurer could use the following structure:

  • Financial risk
    • Market risk
      • Interest-rate risk
    • Credit risk
  • Operational risk
    • Technology availability risk
    • Process execution risk
  • Hazard risk
    • Property damage risk

A hypothetical loss caused by a change in bond yields could be classified at the leaf “interest-rate risk,” which rolls up to “market risk” and then “financial risk.” The leaf is the narrowest category shown. Classification at a parent level may still be appropriate when the available information does not justify a more specific assignment.

For reliable roll-ups, sibling categories—the children of the same parent—should ordinarily be mutually exclusive and collectively exhaustive for the stated scope. Mutually exclusive means that an item cannot be assigned to more than one sibling under the same classification rule. Collectively exhaustive means every in-scope item can be assigned to at least one child. If children overlap, adding their totals can count an item twice. If they leave gaps, some items cannot be classified without an “other” category or a revision to the definitions.

$$ \text{Parent total}=\sum_{j=1}^{k}\text{Child }j\text{ total} $$

This roll-up is valid only if the child categories partition the parent’s items for the measure being summarized: each item is counted once, all in-scope items are included, and the same measure and reporting basis are used throughout. It is not valid merely because the labels appear in a tree.

How to Apply a Boundary Rule

A boundary rule should be practical enough that two analysts applying it to the same facts will reach the same classification. It generally needs to identify the relevant feature of the risk, state important inclusions and exclusions, and explain what to do when the evidence does not support a narrow child category.

1
Identify the item being classified.
Decide whether the record describes a category, a risk statement, an event, or a consequence. Do not treat those terms as interchangeable.
2
Read the category definitions.
Use the written inclusion and exclusion rules, not just the category names or a familiar shorthand.
3
Choose the narrowest supported category.
Move down the hierarchy only as far as the facts permit. If the facts do not establish a child category, classify at the parent level or use the defined fallback.
4
Check the roll-up.
Confirm that the assignment belongs to the chosen parent and is not also counted in a sibling category under the same rule.

The reason for the roll-up rule can be stated precisely. Suppose the parent contains \(N\) in-scope items, and each item belongs to exactly one of \(k\) children. Let \(I_j\) be the set of items assigned to child \(j\). The children are exhaustive when their union is the full parent set, and mutually exclusive when any two child sets have no item in common. Thus every parent item appears in one and only one child set. For an additive measure, such as a count or total dollar amount, summing the child measures therefore counts every parent item exactly once:

$$ \bigcup_{j=1}^{k} I_j=I_{\text{parent}}, \qquad I_j\cap I_m=\varnothing\ \text{for }j\ne m \quad\Longrightarrow\quad T(I_{\text{parent}})=\sum_{j=1}^{k}T(I_j) $$

Here \(T\) must be an additive measure calculated on the same basis for each set. A ratio or percentage generally cannot be rolled up by simply adding child percentages; it must be recalculated from the appropriate underlying totals.

Worked Example: Classifying a Bond-Value Event

A hypothetical insurer uses the financial-risk hierarchy shown above. Its definition of interest-rate risk is “risk of a change in the value of interest-sensitive positions due to a change in market interest rates.” A separate credit-risk definition covers loss due to a counterparty’s failure to meet an obligation. During a reporting period, market yields rise, reducing the value of the insurer’s fixed-rate bond portfolio. No issuer defaults. Classify the event at the most specific supported level and identify the parent categories.

Method. Identify the event, test it against the child definitions, and then follow the parent-child links.

Step 1: Identify the event. The event is a rise in market yields that reduces the value of fixed-rate bonds. The decline in portfolio value is its consequence; it is not itself a taxonomy category.

Step 2: Test the child boundaries. The change in market interest rates directly matches the stated interest-rate-risk definition. No counterparty failure occurred, so the stated credit-risk boundary is not met.

Step 3: Select the category and roll it up. The most specific supported category is interest-rate risk. Its parent is market risk, and that category’s parent is financial risk.

Check. The classification follows the cause specified by the category definition, and the event is included in the parent categories without being assigned to credit risk. A common mistake would be to call the event credit risk simply because the bonds were issued by other entities; the facts describe a market-rate change, not a default.

Boundary Rules in Practice

Category names that sound similar do not guarantee clear boundaries. A useful boundary rule identifies the basis for assignment and separates categories that might otherwise attract the same record. Exclusions are especially helpful: they show what a category does not include, rather than leaving users to infer the distinction.

A fallback category such as “other operational risk” can prevent users from forcing an event into a child category that does not fit. It should be monitored and periodically reviewed: frequent use may indicate that a definition is unclear or that the hierarchy has a gap. A fallback is not a license to skip the written definitions.

The same caution applies to levels of detail. A hierarchy should not imply certainty that the facts do not support. If a record establishes operational risk but does not distinguish technology availability from process execution, the parent category may be the most defensible classification. The analyst should not choose a leaf merely because the reporting system requests one; a documented “unclassified pending review” process or parent-level assignment is preferable to an unsupported label.

Worked Example: Rolling Up Category Counts

A hypothetical insurer defines three mutually exclusive and exhaustive child categories under operational risk: technology availability, process execution, and other operational risk. A review identifies 8 events in technology availability, 5 in process execution, and 2 in other operational risk. All counts cover the same period and use the same event inclusion rule. Find the operational-risk event count and state what must be true for the calculation to be valid.

Method. Because the three children are defined as a partition and the measure is an event count, add the child counts.

Step 1: Check the scope. The counts cover the same reporting period and use the same inclusion rule, so they are on a common basis.

Step 2: Check the category structure. By the problem’s definition, every operational event belongs to one of the three children, and no event belongs to two of them.

Step 3: Add the counts.

$$ 8+5+2=15 $$

The operational-risk total is 15 events. Check. The three child counts sum to the parent count because the children are exhaustive and mutually exclusive. A common mistake is to add counts from overlapping labels: if an event were counted in both technology availability and process execution, the sum would overstate the parent total.

Worked Example: Separating an Event Category From Its Consequence

A hypothetical insurer defines technology availability risk as disruption caused by a system being unavailable, and financial liquidity risk as inability to meet obligations when due. Its claims system is unavailable for several hours. Claims payments are delayed, but the insurer has sufficient cash and meets all obligations on time. Under these definitions, classify the event and explain why the related payment delay does not change the classification.

Method. Apply the stated definitions to the event itself, then check whether the separate category’s defining condition occurred.

Step 1: Identify the event. The claims system became unavailable. That is the occurrence to classify.

Step 2: Test the technology boundary. System unavailability is explicitly included in technology availability risk, so the event belongs in that child category and rolls up to operational risk.

Step 3: Test the liquidity boundary. Liquidity risk, as defined here, requires inability to meet obligations when due. Payments were delayed, but the insurer had sufficient cash and met its obligations on time. The defining condition for liquidity risk is therefore not established.

Check. The classification is technology availability risk, under operational risk. The payment delay is a consequence of the event, not proof of liquidity risk. A common mistake is to classify an event by any consequence it produces without testing the consequence against the category boundary.

Common Boundary Errors

  • Confusing a category with an event. “Process execution risk” is a category; a particular incorrect claim entry is an event that may fit it under the relevant definition.
  • Classifying by a related consequence alone. A delayed payment does not establish liquidity risk unless the defined liquidity condition is met.
  • Assigning the same item to multiple siblings. If the reporting rule expects one category per event, double assignment makes sibling totals unreliable.
  • Forcing a leaf-level answer. A parent-level assignment is more defensible when the facts do not establish which child applies.
  • Adding unlike measures. Child counts or dollar totals may be additive on a consistent basis; child percentages usually are not.
Key takeaway: A hierarchy is useful when each level has a clear relationship to its parent and each category has a usable boundary rule. Classify an item at the most specific level supported by the facts, and roll up totals only when the child categories form a complete, non-overlapping partition on a consistent measure.

Check Your Understanding

For each problem, apply the stated definitions and pay attention to what the category boundary requires.

  1. A hypothetical insurer defines market risk as loss from changes in market prices and credit risk as loss from a counterparty default. A bond’s market value falls after yields rise, and no issuer defaults. Give the narrowest category if the taxonomy has financial risk, with market risk as its child and interest-rate risk beneath market risk. (Answer: Interest-rate risk, rolling up to market risk and financial risk.)
  2. A taxonomy defines property damage risk as physical damage to owned premises and process execution risk as an error in carrying out a business procedure. A hypothetical insurer’s office is damaged by a burst pipe; no employee procedure failure is identified. Which category applies under these definitions? (Answer: Property damage risk.)
  3. Under a defined operational-risk parent, the mutually exclusive and exhaustive child counts are 6 technology events, 9 process events, and 3 other events for the same period. What is the parent event count? (Answer: 18 events.)
  4. A system outage causes a one-day claims-processing delay. The insurer has enough cash and pays all obligations when due. If the taxonomy defines technology availability risk by system unavailability and liquidity risk by inability to meet obligations when due, which category is supported? (Answer: Technology availability risk; the stated facts do not meet the liquidity-risk boundary.)
  5. A parent category has two children. One child reports 11 events and the other reports 7, but three events appear in both counts; the children otherwise cover the full scope. What is the correct parent count? (Answer: 15 events, since the three overlapping events must be counted once: 11 + 7 - 3 = 15.)
Clinical Biostats