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]