The advent of Basel III significantly changes the way in which financial institutions address counterparty credit risk. While a small number of banks are prepared for the regulatory changes and are actively managing CVA, the complexity and cost of implementing the necessary infrastructure remains a big job for the majority.
The market volatility experienced during the financial crisis has driven many firms to review their methods of accounting for counterparty credit risk. The traditional approach of controlling counterparty credit risk has been to set limits against future exposures and verify potential trades against these limits. Credit Value Adjustment (CVA) is new risk measure that offers an opportunity for banks to move beyond the system control of limits and to price dynamically counterparty credit risk of new trades. Many banks already measure CVA in their accounting statements, but the financial crisis has led pioneering banks to invest in systems that more accurately assess CVA, and integrate CVA into pre-deal pricing and structuring.
Towards active management of counterparty credit risk with CVA
Basle III and the CVA measure for Counterparty Credit Risk
Any firm participating in the OTC Derivatives market is exposed to the counterparty credit risk. This risk has been defined as the risk that occurs when counterparty defaults, implying the non-payments of the future cash flows that were agreed on the derivatives contracts.
Then modeling the credit future exposures is a fundamental part of the risk management and it introduces changes on the day to day pricing and hedging on transactions within this market.
Basel II Accords introduces many statistics on the law of distribution of the Future to Market in order to estimate the potential positive future exposures:
Among them a common adopted measure is the Max Peak Exposure which stands for the maximum amount of loss that would occur if the counterparty were to default at any point in the future, for a given statistical confidence level. Say it in another words, it is the greatest future exposure over all future paths of the relevant market risk factors between now and the future maturity date of the contracts.
Another kind of risk that was under estimate or neglected is that the value of the derivative contract can be highly and adversely correlated to the creditworthiness of the counterparty. This type of risk is often referred to the Wrong Way Risk.
As introduced and defined in Basel III Accord, There are two types of Wrong-Way Risk
Specific wrong way risk
Specific WWR arise when for instance a company chooses to use its own shares as collateral for position taking. In that situation if the company suffers cash flow difficulties, the value of stock will drop as the probability of default increases. This leads to a depreciation of the collateral value held to cover delivery of contracts the firm has open.
General wrong way risk
General form of Wrong Way Risk arises when the credit quality of the counterparty may for non-specific reasons may be correlated with other macroeconomic factors that may also impact the exposure of open derivatives transactions.
General Wrong Way Risk is linked to the economic conjectural factors that are both hard to detect on a Bank trading book and also hard to measure.
Example of wrong way risk
Assume that an investor A (protection buyer) buys a CDS from its counterparty, a bank B (protection seller) on a reference entity E that potentially can defaulted on.
This example shows that if the E’s and B’s default probabilities are positively correlated then A’s exposition increase while B’s credit quality decreases. This situation is typical of what we have called specific Wrong Way Risk.
The financial market turmoil that started on 2007 has clearly highlighted this underlying risk on OTC transactions. Before this date many financial institutions admitted as a consensus that the majority of their derivatives exposures were with “too big to fail” counterparties. Other institutions take into accounts this underlying risk but did not actively price or manage it.
Today it becomes obvious that the counterparty credit risk should also be taken into account when reporting the fair value of any derivative position. The adjustment to the value is known as the Credit Value Adjustment (or Credit Valuation Adjustment).
Credit Value Adjustment (CVA)
The Credit Value Adjustment is by definition the difference between the risk-free portfolio and the true portfolio value that takes into account the possibility if a counterparty's default. In other words, CVA represents the market value of the counterparty credit risk.
How is CVA calculated?
Let L* be the actualized losses that can occurs in the interval of time [0,T]
- LDG: is the Loss Given Default
- EE: positive Estimated Exposure
- PD: Default probability
CVA is formulated as the risk-neutral conditional expectation actualized losses
- Q: Risk neutral probability
- : Time when the default will occur
We also make the assumption that the Recovery Rate at default is a known constant and we then have the general expression of the CVA:
This mathematical expression and specifically the conditional expectation highlight the fact that there exists a correlation between the Bank exposure and the credit quality of the counterparty materialized by its expected default frequency. In other words this measure introduces the joint distribution of market factors and the credit factors that drives the potential default of the counterparty.
CVA measure changes environment for pricing and managing counterparty risk and most users derivatives have already CVA groups dedicated to controlling counterparty credit risk for their business lines. It seems natural to centralize the management of CVA since a typical counterparty can be linked with numerous trading desks.
CVA desks are generally created out of the Trading Desk in order to let Traders still working in a “risk free world” as usual. This way the Trading Desk is free of:
- Accessing the whole portfolio which could have specific legs booked into different system.
- Handling the whole set of market and credit data required to compute the CVA
CVA Desk can concentrate on developing adapted simulations models and pricing algorithms, hedging CVA ….
Running in parallel of the Trading Desk, the CVA Desk has in charge to express CVA as a scalar representing the spread between a risk-free and credit risky valuation of a trade or a portfolio. At portfolio level CVA is unfortunately not an additive measure and this implies that the Global CVA at global portfolio level cannot be computed as the sum of the individual CVA trades. This is due to the netting and collateral agreements that prevail on some OTC transactions and also due to the nature of the credit exposure (out the money Mark to Market have no exposure). Therefore the Desk has to compute CVA and credit Exposures on both trade and portfolio levels.
CVA Value per trade is a must have requirement for:
- Better decision making at trade inception; this means that before booking the deal the trader may ensure that the risk free NPV adjusted by the impact of this deal on the global portfolio CVA is positive. This is called the incremental CVA and stands for the difference between the portfolio CVA before and after booking the deal.
- Allocation purposes after the deal has done : Global CVA is then decomposed as the sum of individual Marginal CVA (Variation of the global CVA with respect to a given deal)
CVA Desk assignment could be sum up as follow:
- At Pre deal level: Being able to deliver on demand to the Trading Desk an incremental CVA expressed as a spread
- During the lifetime of the deal : integrating in RT executed trades in the global CVA process
- At post trade level: Analyzing CVA and allocating result per trade (Marginal CVA)
- Managing the CVA portfolio: Hedging the risk (detecting WWR), satisfying the legislation in terms of capital charge allocation.
Establishing such specialized groups can add enormous value to an institution’s ability to manage their risk. They improve the competitive advantage within transaction, and help to realize when it is best to run away from some risky full counterparties and when it is interesting to increase the level of business with some reliable counterparties.
CVA impacts IT systems
CVA is driving many firms to fundamentally re-evaluate their risk systems architecture, and firms have found that the proper calculation of CVA is non-trivial, even on a periodic basis
CVA models are time and resources consuming and require a sophisticated and highly flexible infrastructure. They involve many different teams including IT for designing the RT interfaces, IT Quant for implementing efficient models, Quant for defining and validating the models and scenario generations, Front office and Risk management staff for validating the whole process from a business point of view, Back Offices for regulatory process and reports.
Data and Module needed to run the CVA desk
For pre deal check Trading Desks should interface in Real Time with CVA Desk
Markets data needed for CVA Desk is almost the same as those required by the Trading Desk. In addition they need:
- Credit related Market Data CDS spread and recovery rate curves
- Correlations matrices between the model underlying’s (swap rates, equity rates ….) and credit market data in order to handle the WWR.
Market Data can be loaded from external providers or directly from trading systems
CCR mitigation data
- Collateral systems: Collateral data are required at pricing time.
- Margin process: Bank heavily involved in OTC derivatives trading are constantly increasing the use of margining in order to offset their credit exposure.
- Netting system: Netting agreements are required at aggregation time
Scenario generator engine
This module has to access market data.
The scenario engine also has to access the portfolio data, especially for building the time buckets.
Contrary to CVaR model where the horizon of time is 10 days horizon, CVA requires models expending to the latest maturity of the portfolio. As a result, these models can’t rely on simple hypothesis such as lognormal swap rate diffusion but rather take into account more complex effects such as mean reversion.
Though they are of course depending on market data, scenarios can’t be generated each time a CVA computation is required.
General Framework used is MC simulation and uses Grid Computing techniques.
The purpose is to compute a CVA number from the individual trade NPVs computed on each node (node defined a date and a path). A key point is to take Netting information into account.
The following schema describes a possible architecture for CVA computations based on OLAP cube’s technology.
This cube contains scenarios provided by the Scenario Generator engine. Each node (date, path) is stored in this cube. Data can either be the curves themselves or the factors of the model. In that latter case, it means that the curves will have to be rebuilt at pricing time.
This cube is populated by the Pricing Feeder with the pricing values of each trade of the portfolio and on each node of the Scenarios cube.
This task has to be processed ‘forward’ on each path to correctly propagate fixings and trade events.
Based on these two cubes, we can compute CVA and Incremental CVA.
CVA and CCR function
Existing trading systems will most be a poor starting point to provide credible CVA measurement, as these systems often process only a subset of all the trades with a counterparty, they do not have the ability to model netting and collateral agreements, and they cannot generate the required risk-neutral scenarios across all risk factors at the performance levels required. Furthermore, most existing systems do not have the performance or analytical capability to calculate sensitivities (greeks), which are required for management of CVA.
The key to running a successful CVA desk is to find the right balance between risk taking and active hedging. While CVA must be partially hedged to avoid dramatic profit and loss (P&L) variations, this hedging is far from perfect and the residual risks must be well understood.