Introduction
What is a Risk Scenario?
A risk scenario is a structured description of a potential future event that could impact your organisation. In our application, scenarios are built using four key components:
- A narrative that tells the story
- Parameters that define key variables
- Assessments that capture uncertainty
- Expressions that calculate financial impacts
Why Use Our Scenario Builder?
Our application converts your risk scenarios into quantified insights through:
- Monte Carlo simulations that reveal the full range of possible outcomes
- Interactive visualisations that make complex data accessible
- Dependency analysis that shows relationships between variables
- Statistical analysis that supports regulatory reporting
Before You Begin
Effective scenario building requires:
- A clear understanding of the risk event you want to model
- Knowledge of key variables that drive the outcome
- Access to relevant data or expert judgment for parameter estimation
- An understanding of how different components interact
Building Your Scenario Narrative
Core Components
Your scenario narrative should include:
- Context: Brief background of your organisation or situation
- Trigger Event: The specific risk event being modeled
- Transmission: How the event creates financial impact
- Time Frame: The period over which impacts occur
Example: Good Narrative
"Over the weekend, TrustPensions implemented a production patch to their pension management system. The patch inadvertently included untested code that misallocated client funds among approximately 150 accounts. The issue was detected during end-of-day reconciliation, necessitating rollback, reprocessing, and detailed reconciliation."
What Makes This Good:
- Clear trigger event (system patch)
- Specific impact (misallocation across 150 accounts)
- Detection mechanism (end-of-day reconciliation)
- Required actions (rollback, reprocessing)
Writing Tips
- Keep it concise - 2-3 sentences is often enough
- Use specific numbers that will become parameters
- Focus on cause and effect relationships
- Avoid jargon unless necessary for precision
Common Pitfalls to Avoid
- Including multiple unrelated events
- Being too vague about impacts
- Forgetting to mention time frames
- Including opinions or judgments
Designing Parameters
Understanding Parameters
Parameters are the building blocks of your scenario. Each parameter represents a key variable that can change and affect the outcome. In our application, parameters have specific attributes:
- Base Value: The expected or typical value
- Distribution Type: How the value varies (uniform or normal)
- Measure: The unit of measurement (currency, time, percentage, etc.)
- Description: Clear explanation of what the parameter represents
Parameter Naming Conventions
Use clear, consistent names that follow these rules:
- Use underscores instead of spaces (Daily_sales not "Daily sales")
- Include units in name when helpful (Duration_days not just Duration)
- Start with letters, use only letters, numbers, and underscores
- Be specific (Customer_complaints_per_day not just Complaints)
Example: Good Parameter Design
{
"ParameterName": "Detection_Time_Days",
"parameterMeasure": "Days",
"ParameterBaseValue": 1,
"distributionType": "normal",
"ParameterDescription": "Time taken to detect the issue, measured in business days. Critical for determining total exposure and intervention costs."
}
Choosing Base Values
Base values should be:
- Realistic and based on historical data or expert judgment
- Round numbers where appropriate (100 not 97.3)
- Consistent with your organisation's scale
- Aligned with the scenario's context
Creating Assessments
Purpose of Assessments
Assessments define how parameters vary from their base values. They capture uncertainty and stress conditions by specifying:
- How often variations occur (Frequency)
- The range of possible variations (Upper and Lower bounds)
- The type of change (Absolute or Percentage)
- Expected mean impact when change occurs
Choosing Assessment Types
| Change Type | When to Use | Example |
|---|---|---|
| Absolute | For fixed amount changes independent of base value | Number of days lost, Fixed costs |
| Percentage | For changes proportional to base value | Market movements, Demand fluctuations |
Example: Good Assessment Design
{
"AssessmentName": "Weather_Impact",
"Frequency": 1,
"upperBound": 7,
"lowerBound": 0,
"mean": 2,
"ChangeType": "Absolute",
"AssessmentDescription": "Days lost due to severe weather conditions. Based on historical patterns, typically costs 2 days per season but can extend to a week in extreme cases."
}
Setting Realistic Bounds
When setting bounds:
- Use historical data where available
- Consider both normal variations and stress conditions
- Ensure bounds are asymmetric when appropriate
- Include expert judgment for rare events
Writing Expressions
Expression Basics
Expressions calculate outcomes using your parameters. Each expression:
- Must have a unique name
- Can use mathematical operators (+, -, *, /)
- Can reference parameters and other expressions
- Should build complexity gradually
Building Expression Chains
Structure your expressions in logical order:
- Basic calculations (e.g., available_days = total_days - lost_days)
- Intermediate results (e.g., daily_revenue = sales_volume * unit_price)
- Final outcomes (e.g., total_impact = daily_revenue * available_days)
Example: Expression Chain
{
"expressions": [
{
"name": "Total_available_days",
"description": "Calculate effective operating days",
"expression": "Season_duration - Days_lost"
},
{
"name": "Daily_revenue",
"description": "Calculate revenue per operating day",
"expression": "Daily_sales_volume * Base_unit_price"
},
{
"name": "Total_revenue",
"description": "Calculate total season revenue",
"expression": "Daily_revenue * Total_available_days"
}
]
}
Mathematical Operations
Available operations in expressions:
- Basic arithmetic: +, -, *, /
- Parentheses for order of operations
- Percentage calculations (use decimal form: 5% = 0.05)
- Parameter references by exact name
Expression Rules
- Always use defined parameters or previous expressions
- Avoid division by zero risks
- Keep expressions readable with clear structure
- Use descriptive names that indicate the result
- Write clear descriptions explaining the calculation's purpose
Best Practices
Mathematical Integrity
Essential Checks:
- Units match across all calculations
- Time periods are consistent
- Percentages are properly converted to decimals
- Currency conversions are explicit
- Ranges make logical sense (e.g., minimums < maximums)
Common Pitfalls
Issues to Watch For:
- Disconnected Parameters: Every parameter should influence at least one expression
- Hidden Dependencies: Make sure parameter relationships are clearly shown in expressions
- Unit Mismatches: Mixing daily and annual rates, or percentages and decimals
- Circular References: Expressions that depend on their own results
- Missing Assessments: Parameters that vary but have no assessment defined
Quality Checklist
Before running your simulation, verify:
- ✓ Scenario narrative clearly describes the risk event
- ✓ All parameters have appropriate units and descriptions
- ✓ Assessment ranges are realistic and justified
- ✓ Expressions build logically to final impact
- ✓ Dependencies are shown in the graph view
- ✓ Variable names are consistent throughout
Examples Library
Simple Scenario: Ice Cream Van Operations
Scenario Overview
Mr. Whimsy's ice cream van business faces weather and equipment risks during the summer season.
Key Components:
// Parameters
{
"ParameterName": "Season_duration",
"ParameterBaseValue": 100,
"distributionType": "uniform",
"parameterMeasure": "Days",
"ParameterDescription": "Length of summer season"
},
{
"ParameterName": "Daily_sales_volume",
"ParameterBaseValue": 100,
"distributionType": "normal",
"parameterMeasure": "Units per day",
"ParameterDescription": "Average ice creams sold per day"
}
// Assessments
{
"AssessmentName": "Weather_Impact",
"Frequency": 1,
"upperBound": 7,
"lowerBound": 0,
"mean": 2,
"ChangeType": "Absolute",
"AssessmentDescription": "Days lost to bad weather"
}
// Expressions
{
"name": "Total_available_days",
"expression": "Season_duration - Days_lost",
"description": "Actual trading days available"
},
{
"name": "Total_revenue",
"expression": "Daily_sales_volume * Total_available_days * Base_unit_price",
"description": "Total season revenue"
}
Complex Scenario: Client Money Misallocation
Scenario Overview
A system patch causes misallocation of client funds, requiring investigation and remediation.
Key Components:
// Parameters
{
"ParameterName": "Detection_Time",
"ParameterBaseValue": 0,
"distributionType": "normal",
"parameterMeasure": "Days",
"ParameterDescription": "Time to detect the misallocation"
},
{
"ParameterName": "Affected_Clients",
"ParameterBaseValue": 100,
"distributionType": "normal",
"parameterMeasure": "Count",
"ParameterDescription": "Number of impacted client accounts"
}
// Assessments
{
"AssessmentName": "Complex_Case_Resolution",
"Frequency": 0.2,
"upperBound": 100,
"lowerBound": 0,
"mean": 50,
"ChangeType": "Percentage",
"AssessmentDescription": "Additional time needed for complex cases"
}
// Expressions
{
"name": "Total_Resolution_Days",
"expression": "Detection_Time + (Affected_Clients * Reconciliation_Time_Per_Client)",
"description": "Total days to resolve all cases"
}
Risk Type Patterns
Operational Risk:
- Focus on time parameters (detection, resolution)
- Include volume metrics (affected clients, transactions)
- Consider resource costs (staff time, system costs)
- Add reputation/regulatory impacts
Market Risk:
- Use price movement parameters
- Include volatility assessments
- Consider correlation effects
- Add liquidity impacts
Credit Risk:
- Focus on exposure amounts
- Include default probabilities
- Consider recovery rates
- Add contagion effects
