Why Architecture Is a Model-Design Decision
A capital model’s architecture determines how risk information is organized and brought together to support decisions. The choice affects how readily users can trace a result to its sources, how much data and modeling capability are needed, how sensitive the model is to changes in individual risks, and how much effort is required to build and maintain it. These are design trade-offs, not merely technical preferences.
The appropriate architecture depends on the model’s intended use and the organization’s capabilities. A model used to explain capital by business line may need more detail and traceability than one used primarily to assess enterprise-wide capital. Conversely, a highly detailed design may be difficult to support if the underlying data are weak. The comparison should therefore begin with the decisions the model must inform and the constraints it must satisfy.
These labels describe broad design approaches, not a fixed set of calculations. For example, a bottom-up design can use different levels of component detail, and a hybrid design can combine components and enterprise-level elements in different ways. The key distinction is where risk is represented and how the component and enterprise views are connected.
The architecture choice is aligned with the CAS Exam 9 (Risk Management for Actuaries) syllabus. It should be evaluated against intended use, materiality, available information, and the effort required to operate the model—not selected on the basis of a label alone.
Compare the Approaches Against the Same Criteria
A fair comparison uses criteria that apply to all candidate architectures. The following dimensions are useful starting points. Their importance will differ by organization and decision.
| Criterion | Question to ask | Common trade-off |
|---|---|---|
| Transparency | Can users trace the result to risk drivers and explain how changes affect it? | Component detail can improve traceability, but more components can make the complete model harder to oversee. |
| Data readiness | Are sufficiently reliable and relevant data available to support the proposed level of modeling? | Detailed components may require data that are unavailable or inconsistent; an enterprise view may need fewer component-level inputs but still needs credible overall calibration. |
| Risk sensitivity | Can the design show how changes in individual risks or assumptions affect the enterprise result? | Component-level representation can make specific changes easier to isolate, while an enterprise-level approach may capture broad effects without identifying their source as clearly. |
| Implementation effort | Can the organization build, govern, validate, and maintain the model with its available resources? | More component models can increase build and maintenance effort. A simpler structure may be easier to operate but less informative for some decisions. |
| Decision suitability | Does the model produce information at the level needed for its intended decisions? | A design suitable for an enterprise-wide assessment may not support decisions requiring detailed risk attribution. |
These are tendencies, not guarantees. A component model built on weak data is not automatically transparent or sensitive in a useful sense. A top-down model can be well governed and informative for its intended purpose, even if it does not provide detailed component attribution. State the assumptions behind each assessment rather than treating general tendencies as universal rules.
A Structured Comparison Method
A weighted decision matrix can make the trade-offs explicit. It does not turn a judgment into an objective fact; it records how a set of stated priorities applies to the candidate designs. Define a scale in which a higher score always means a more favorable assessment. For data, for instance, score data readiness rather than data burden: a high score means the data burden is manageable given the organization’s available information.
The formula is a weighted average: each criterion contributes its score multiplied by its share of total importance. Since the weights sum to one, a design scoring the same value on every criterion receives that value overall. If all criteria have equal weights, the formula reduces to their arithmetic mean. This explains why the weights must sum to one and why a higher score must consistently mean “more favorable.”
State what the model must support, such as enterprise capital assessment, business-level explanation, or monitoring changes in selected risks.
Choose relevant criteria and define what each score means. Use the same direction for every criterion, with higher scores consistently preferable.
Assign weights that reflect the decision, then rate each architecture using stated evidence and assumptions.
Remove candidates that fail essential requirements, examine close scores and influential assumptions, and check whether the leading design suits the intended use.
A weighted score should not compensate for failure to meet a mandatory requirement. For example, if the model must explain results at a specified level, a high score on implementation ease cannot by itself make an architecture that cannot meet that requirement acceptable. Apply feasibility gates before relying on an overall ranking.
Worked Example: Ranking Architectures for Traceable Capital Decisions
A hypothetical insurer wants a capital model that supports explanations by business area. Its design group assigns weights of 0.40 to transparency, 0.30 to data readiness, 0.20 to risk sensitivity, and 0.10 to implementation ease. Scores range from 1 to 5, with 5 most favorable. The group rates bottom-up as (5, 4, 2, 2), top-down as (2, 2, 5, 5), and hybrid as (4, 3, 4, 4), in the stated criterion order. Calculate the weighted scores and identify the highest-ranked design.
Method. Check first that the weights sum to one: \(0.40+0.30+0.20+0.10=1.00\). Then multiply each architecture’s score by the corresponding weight and add the four contributions.
Bottom-up: transparency contributes \(0.40(5)=2.00\); data readiness contributes \(0.30(4)=1.20\); sensitivity contributes \(0.20(2)=0.40\); and implementation ease contributes \(0.10(2)=0.20\). Therefore, \(R_{\mathrm{BU}}=2.00+1.20+0.40+0.20=3.80\).
Top-down: the contributions are \(0.40(2)=0.80\), \(0.30(2)=0.60\), \(0.20(5)=1.00\), and \(0.10(5)=0.50\). Thus, \(R_{\mathrm{TD}}=0.80+0.60+1.00+0.50=2.90\).
Hybrid: the contributions are \(0.40(4)=1.60\), \(0.30(3)=0.90\), \(0.20(4)=0.80\), and \(0.10(4)=0.40\). Thus, \(R_{\mathrm{H}}=1.60+0.90+0.80+0.40=3.70\).
The ranking is bottom-up at 3.80, hybrid at 3.70, and top-down at 2.90. Bottom-up ranks first under these weights and ratings, but its lead over hybrid is only 0.10 points. The result should prompt review of the ratings and the importance assigned to transparency and data readiness, not be treated as a definitive measurement of architectural quality.
Common mistake avoided: Do not round or estimate partial products before adding them. In particular, the bottom-up total is \(3.80\), not \(3.90\), and the top-down total is \(2.90\), not \(3.00\). The displayed products provide a direct check.
Let the Intended Use Change the Priorities
The same candidate ratings can lead to a different ranking when the decision changes. This is not a defect in the method: different uses legitimately value different attributes. A model intended for broad enterprise monitoring may put more weight on sensitivity to enterprise-level changes and manageable implementation than a model intended to explain results by business area.
Worked Example: Reweighting for Enterprise Monitoring
Use the scores from the prior example, but suppose the hypothetical insurer now prioritizes monitoring enterprise-wide risk changes. It assigns weights of 0.15 to transparency, 0.15 to data readiness, 0.45 to risk sensitivity, and 0.25 to implementation ease. Determine the new ranking and explain what changed.
Method. The weights sum to \(0.15+0.15+0.45+0.25=1.00\). Keep the architecture ratings unchanged and calculate each weighted average using the revised priorities.
For bottom-up, the contributions are \(0.15(5)=0.75\), \(0.15(4)=0.60\), \(0.45(2)=0.90\), and \(0.25(2)=0.50\). The total is \(0.75+0.60+0.90+0.50=2.75\).
For top-down, the contributions are \(0.15(2)=0.30\), \(0.15(2)=0.30\), \(0.45(5)=2.25\), and \(0.25(5)=1.25\). The total is \(0.30+0.30+2.25+1.25=4.10\).
For hybrid, the contributions are \(0.15(4)=0.60\), \(0.15(3)=0.45\), \(0.45(4)=1.80\), and \(0.25(4)=1.00\). The total is \(0.60+0.45+1.80+1.00=3.85\).
Top-down now ranks first at 4.10, followed by hybrid at 3.85 and bottom-up at 2.75. Its high scores on sensitivity and implementation ease matter more under the revised weights. The ratings did not change; the decision priorities did.
Common mistake avoided: Do not reuse the first ranking as if it applied to every purpose. The score is conditional on the chosen weights. Also, do not conclude that the top-down design is automatically suitable: confirm that its lower transparency and data-readiness scores are acceptable for the monitoring decision.
Use Feasibility Gates Before a Weighted Ranking
Some requirements are constraints rather than preferences. A minimum level of traceability, a required delivery date, or a limit on operating capacity may eliminate a candidate regardless of its weighted score. The ratings used for a gate should be defined in advance, and the gate should reflect a real requirement rather than being added after seeing which architecture wins.
Worked Example: Applying Traceability and Delivery Gates
A hypothetical insurer needs quarterly capital information for business-area decision makers. It has strong data for established risks but less developed information for a newer risk. The design group uses a 1-to-5 scale, where higher scores are more favorable. It sets two mandatory gates: transparency must score at least 4, and implementation ease must score at least 3 to meet the delivery schedule. Its ratings are bottom-up (5, 4, 2, 2), top-down (2, 2, 5, 5), and hybrid (4, 3, 4, 3), with the last score representing implementation ease. Which candidates pass?
Method. Test each architecture against both thresholds before considering any overall preference. A candidate is feasible only if it meets both requirements.
Bottom-up meets the transparency gate because \(5\geq4\), but fails the implementation gate because \(2<3\). It is infeasible under the stated delivery constraint. Top-down meets the implementation gate because \(5\geq3\), but fails the transparency gate because \(2<4\). It is also infeasible. Hybrid meets both: \(4\geq4\) for transparency and \(3\geq3\) for implementation ease. It is the only feasible candidate.
The hybrid design is therefore the choice among these three designs under the stated requirements. Its use of component-level modeling for risks with stronger data and an enterprise-level approach where component information is less developed is consistent with the mixed data position, provided the model can explain how those elements contribute to its result.
Common mistake avoided: Do not average a failed mandatory requirement into a favorable total. A candidate that misses a required transparency threshold does not pass merely because its implementation score is high.
What a Hybrid Design Does—and Does Not—Solve
A hybrid architecture can be useful when some risks are sufficiently understood for component-level representation while others are better handled at an enterprise level. It can also support more than one decision use, such as providing component information while retaining an enterprise view. But “hybrid” is not a substitute for a clear design. The model still needs a defined boundary between components and enterprise-level elements, controls against omission or double counting, and an explanation of how the combined result is interpreted.
A hybrid model can also inherit burdens from both approaches. Component models require appropriate inputs and maintenance; enterprise-level elements need a defensible basis and governance. If the organization cannot maintain the component data or explain the enterprise overlay, the apparent flexibility may come at the cost of reliability and usability. The design should be no more complicated than the intended decisions require.
For any architecture, record the purpose, key assumptions, criteria, weights, ratings, feasibility constraints, and reasons for the final selection. Review whether plausible changes in weights or ratings alter the ranking. A close result calls for particular care: it may indicate that the alternatives involve a genuine trade-off, not that the calculation has identified a uniquely correct design.
Common Architecture-Selection Traps
- Choosing by label. “Bottom-up” is not automatically more rigorous, and “top-down” is not automatically simpler or less useful. Evaluate the actual design against its purpose.
- Scoring the wrong direction. If a high score means greater data burden for one architecture but better data readiness for another, the weighted comparison is incoherent. Define every scale so that higher always means more favorable.
- Confusing weights with ratings. A weight expresses how important a criterion is; a rating expresses how well a candidate performs on it. Changing one is not the same as changing the other.
- Letting scores hide a failed requirement. Apply mandatory feasibility gates before ranking the candidates that remain.
- Treating ordinal scores as precise measurements. A score of 4 is not necessarily twice as good as a score of 2. Weighted totals are decision aids based on judgments, so examine the underlying rationale and sensitivity.
- Ignoring the users of the result. An architecture that supports an enterprise assessment may not provide the detail required for decisions at a more granular level.
Check Your Understanding
For each problem, apply the stated scale and assumptions. Higher scores are more favorable unless the problem specifies a gate.
- A hypothetical model committee gives transparency and data readiness equal weights of 0.50. A bottom-up design scores 4 on transparency and 2 on data readiness; a top-down design scores 2 and 5, respectively. Calculate both weighted scores and identify the higher score. (Answer: Bottom-up 3.00; top-down 3.50; top-down ranks higher.)
- A company scores transparency, risk sensitivity, and implementation ease using weights of 0.30, 0.50, and 0.20. A hybrid design scores 4, 3, and 5. Calculate its weighted score. (Answer: \(0.30(4)+0.50(3)+0.20(5)=1.20+1.50+1.00=3.70\).)
- For a quarterly enterprise-monitoring use, a committee assigns weights of 0.20 to transparency, 0.20 to data readiness, 0.40 to risk sensitivity, and 0.20 to implementation ease. A top-down design scores 2, 3, 5, and 4. Calculate its weighted score. (Answer: \(0.20(2)+0.20(3)+0.40(5)+0.20(4)=0.40+0.60+2.00+0.80=3.80\).)
- A model must score at least 4 for transparency and at least 3 for implementation ease. Bottom-up scores 5 and 2; top-down scores 3 and 5; hybrid scores 4 and 3. Which design passes both gates? (Answer: Hybrid only.)
- A committee initially uses weights of 0.40 for transparency, 0.30 for data readiness, 0.20 for risk sensitivity, and 0.10 for implementation ease. It changes the weights to 0.10, 0.20, 0.50, and 0.20, respectively. In one sentence, state what the committee must do before interpreting any new ranking. (Answer: Recalculate all candidates’ weighted scores using the revised weights, verify that they sum to 1.00, and check the result against mandatory requirements and the intended use.)