managing-market-risk-limits

# Managing Market Risk Limits

## When To Use

- Designing or overhauling a market risk limit framework for a trading desk, business unit, or enterprise
- Responding to a limit breach that requires escalation documentation and remediation steps
- Calibrating VaR confidence levels, holding periods, or sensitivity thresholds after portfolio changes
- Preparing limit proposals for Risk Committee or Board approval
- Reviewing whether existing notional, Greeks-based, or concentration limits remain fit for purpose

## Inputs To Gather

- **Portfolio composition**: Asset classes traded (rates, FX, equities, credit, commodities), instrument types (cash, listed derivatives, OTC), and approximate notional outstanding
- **Current limit structure**: Existing VaR limits, sensitivity limits (DV01, CS01, delta, vega, gamma), notional caps, concentration limits, stop-loss triggers, and any P&L-based limits
- **Risk appetite statement**: Board-approved risk appetite metrics, tolerances, and any capital allocation tied to market risk
- **Historical P&L and VaR data**: Back-testing results, VaR exceptions count over trailing 250 days, actual vs. hypothetical P&L series
- **Organizational structure**: Desk hierarchy, limit delegation chain (Board → CRO → Head of Trading → Desk Head), and escalation contacts
- **Regulatory context**: Whether the entity is subject to FRTB, Basel III/IV internal models approach, or standardized approach [VERIFY jurisdiction-specific regime]

## Workflow

1. **Map the limit hierarchy**
   - Define tier structure: enterprise-level → business-line → desk-level → trader-level
   - For each tier, identify which limit types apply (VaR, sensitivity, notional, stop-loss, stress)
   - Confirm aggregation rules — whether sub-limits sum to parent or allow diversification benefit

2. **Set VaR-based limits**
   - Select confidence level (typically 99% for internal, 97.5% for FRTB ES) and holding period (1-day for daily monitoring, 10-day for regulatory capital) [VERIFY regulatory holding period requirement]
   - Calibrate limit quantum: back-solve from risk appetite capital allocation, or benchmark against peer utilization rates (typical desk utilization target: 60-80% of limit)
   - Specify the VaR model used (historical simulation, Monte Carlo, parametric) and lookback window

3. **Set sensitivity and notional limits**
   - Define Greeks limits per risk factor: DV01 per curve tenor bucket, CS01 per credit rating/sector, delta and vega per underlier
   - Set gross and net notional limits by asset class and instrument type
   - Establish concentration limits — maximum single-name, single-sector, or single-country exposure as a percentage of total portfolio
   - Include tenor/maturity bucket limits where relevant (e.g., max DV01 in the 10Y+ bucket)

4. **Define stop-loss and P&L triggers**
   - Set cumulative loss limits (daily, monthly, year-to-date) at each hierarchy tier
   - Specify trigger levels: warning (e.g., 75% utilization), soft breach (limit hit, temporary exceedance allowed with approval), hard breach (mandatory position reduction)
   - Define the P&L attribution requirement — realized vs. unrealized, and treatment of reserve/valuation adjustments

5. **Document escalation and breach protocol**
   - **Warning level**: Desk head notified, risk manager alerted; no mandatory action but increased monitoring frequency
   - **Soft breach**: CRO and Head of Trading notified within 1 hour; desk must present remediation plan within same business day; temporary limit extension requires CRO sign-off
   - **Hard breach**: Immediate notification to CRO and CEO; position reduction must commence within defined timeframe; Board Risk Committee informed at next meeting or ad-hoc if material
   - Include cure periods, documentation requirements for each breach event, and post-breach review process

6. **Stress and scenario limits**
   - Define stress scenarios (historical: 2008 GFC, 2020 COVID; hypothetical: parallel rate shift ±200bp, credit spread widening +300bp, equity drop -20%)
   - Set stress loss limits separate from VaR limits — these act as a backstop for tail risk
   - Specify frequency of stress testing (daily for active desks, weekly for less active)

7. **Governance and review cycle**
   - Limits reviewed at minimum annually or upon material change in strategy, market conditions, or risk appetite
   - Document approval chain: proposed by risk management, endorsed by business head, approved by Risk Committee
   - Track limit utilization trends for recalibration; persistently low utilization (<30%) or frequent breaches signal misalignment

## Output

Produce a **Market Risk Limit Framework Document** containing:

- Limit hierarchy table: tier, limit type, metric, quantum, warning/soft/hard thresholds
- Escalation matrix: breach level → notification recipients → required actions → cure period → documentation
- VaR methodology summary: model type, confidence level, holding period, lookback, back-testing performance
- Sensitivity limit schedule: risk factor, tenor bucket, limit quantum, current utilization
- Stress limit schedule: scenario name, scenario parameters, loss limit, current estimated loss
- Governance section: review frequency, approval authority, amendment process

## Quality Checks

- Every limit has a defined warning, soft breach, and hard breach threshold — no gaps in the escalation ladder
- VaR confidence level and holding period are consistent with both internal policy and applicable regulatory requirements [VERIFY against current regulatory regime]
- Sensitivity limits cover all material risk factors for the portfolio; cross-check against recent risk reports to confirm no blind spots
- Stop-loss triggers are calibrated relative to VaR limits (a common check: monthly stop-loss ≈ 2-3x daily VaR limit)
- Aggregation rules are explicit — confirm whether diversification benefit is recognized across desks or whether limits are additive
- Stress scenarios include at least one historical and one hypothetical scenario per major risk factor
- Escalation timeframes are specific (hours, not "promptly") and roles are named (CRO, not "senior management")
- Back-testing exception count is documented; if exceptions exceed 4-5 in trailing 250 days, flag for model review [VERIFY Basel traffic-light thresholds]