CVA Desk in the Bank Implementation Counterparty Credit Risk represents the risk that the counterparty of an OTC will default before the maturity of the contract and therefore will not make the remaining payments. The 2007 crisis has been the real boost for banks to handle Counterparty Credit Risk more accurately. To fill the gap, a dedicated Desk -CVA Desk- has been created. After a review of the CVA characteristics and the CVA Desk missions, this document draws the list of the required interfaces and engines to be implemented. The second half of the document provides the description of a possible framework.
Introduction Counterparty Credit Risk represents the risk that the counterparty of an OTC will default before the maturity of the contract and therefore will not make the remaining payments. Even though guide lines (FAS, IAS) existed, the 2007 crisis has been the real driver for banks to handle Counterparty Credit Risk more accurately for the following main reasons: No counterparty even big can be assumed as risk-free; trading with AAA mono lines can no longer be considered as a perfectly hedged strategy. The crisis has shown that Credit Risk was not perfectly tracked and evaluated when deeply embedded in some credit derivatives. As a result: New mitigation techniques have appeared and are now more popular, for example the increasing trend to servicing from OTC Clearing Houses. Banks have increased their efforts to better evaluate, monitor, analyze and hedge Counterparty Credit Risk. This latter point is the scope of this article. The first section introduces the Credit Value Adjustment (CVA) as the price of the Counterparty Credit Risk (CCR). The second section lists the reasons why the use of a dedicated CVA Desk to cope with the functional requirements appears appropriate. The following section draws a list of fields for investigations (interfaces to be developed in order to fully integrate any CVA Management solutions in an existing trading environment) and the technical/functional points to be addressed. The last section presents a generic architecture drawn from GMS experiences.
CVA Until recently, Counterparty Credit Risk was handled at portfolio level through batch analysis separately from standard Front-Office or Risk Management process (No interface with P&L, Hedge ) and posterior to trade booking: For example, a Credit Limit system was updated based on the periodical results provided by a PFE system. This passive way of managing CCR has at least two drawbacks: P&L is not affected by Counterparty Credit Risk although this risk may have a huge impact on the bank results, The risk is not quantified at trade level. CVA as the value of the Counterparty Credit Risk is filling these gaps. CVA can be expressed as a scalar representing the spread between a risk-free and a creditrisky (more realistic) valuation of a trade or a portfolio. Unfortunately, because of Netting mechanism and the nature of Credit Exposure (out of the money mark-to-market valuations have no exposure), this new portfolio P&L component is not additive and cannot be computed as the sum of individual trade CVAs: It means that the whole portfolio (or at least sub-portfolio per Netting agreements) is required to compute Credit Exposures and CVA. On the other hand a CVA value per trade is a must-have requirement for: Better decision making at trade inception: Before actually booking the deal, the trader may want to 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 does represent the difference of portfolio CVA before and after booking this deal. Allocation purposes after the deal is made: Global CVA is decomposed as the sum of individual Marginal CVA (Variation of the global CVA w/o a given deal). An important point in the CVA computation comes from the wrong-way risk : The trade/portfolio credit exposures and counterparty default probabilities cannot be assumed independent from each other. As a result, both PFE and PD have to be computed or simulated in a common framework reflecting these potential correlations.
CVA Desk The basic idea is to push Counterparty Credit Risk management out of Trading Desks and create a dedicated CVA Desk so that Traders can go on working in the risk-free world exactly as before, removing the need for: o Accessing the whole portfolio (which could have specific legs booked into different systems) o Handling the whole set of market data required to compute CVA At the CVA Desk level dedicated staff can concentrate on developing adapted simulation models and pricing algorithms, validating proxies, hedging CVA The CVA Desk assignments can be summarized as follow: Being able to deliver on demand to the Trading Desks, for a pre-deal, an incremental CVA expressed as a fee or spread (incremental CVA), Integrating in real-time executed trades in the global CVA process, Analyzing CVA and allocating results per trade (marginal CVA), Managing the CVA portfolio: Hedging the risks (credit and probably risks in addition to other risks due to wrong-way risk-), satisfying the legislation in terms of provisions or capital allocation Required data and engines Due to its highly complex and integrated model, a CVA implementation project involves many different teams including IT (for designing efficient real-time interfaces), IT Quant (for implementing efficient models), Quant (for defining valid models and scenario generations), Front-Office and Risk Management staffs (for validating the process from a business point of view) and Back-Office (for regulatory process and report). We start by drawing a list of data or modules required at CVA Desk level. Then we will describe a possible architecture for handling CVA processing based on the use of efficient technologies. Portfolio Data Before creating the CVA Desk the first question to answer is the management of the CVA for the existing portfolio. For pre-deal check, Trading Desks should interface in real-time with CVA Desk.
The protection trade between the Trading Desk and the CVA Desk (CVA against protection against default) has to be consistently stored into a database in order to keep the premium leg characteristics and payments (CVA fee or spreads). The protection leg contingent to a default in a portfolio (which can be defined on different Trading systems) can be computed dynamically. At this point, a decision has to be made regarding which booking system will host the trades: the trades from the trading desks could be stored at CVA Desk level or the opposite since an alternative solution would be to load them on demand from the CVA Desk (as soon as historical versions are available potentially used also for P&L purposes for example). The correct answer will most likely depend on the trading systems capabilities and constraints (how many are there, which systems are actually used to cover the overall bank portfolio ). Market data Market data needed for valuation CVA is similar to what is required by the Trading Desk (Modulo the differences in Pricing Models used by Trading and CVA Desks) In addition, the following is needed: Credit related Market data -CDS spread and Recovery curves- Correlation matrices between the models underlyings (swap rates, equity prices ) and credit market data in order to handle the wrong-way risk. This set of correlations matrices depends on the method used and assumptions made to take the wrong-way risk into account. They can be retrieved from providers or generated by in-house tools (For example, correlations based on historical data). Market data can be loaded from external providers or directly from trading systems - in order to take advantage of already processed cleaned-up market data or calibration routines-. Static Data This data is required to correctly interpret the trades coming from trading systems. As these systems may have heterogeneous referential, a data mapping is needed. In case of high-volume data issues, this mapping process should probably take place on top of the acquisition process.
CCR Mitigations 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. As for Trades, the question regarding the physical storage at CVA Desk level versus Trading Desk will also have to be addressed for Market Data, Static data and CCR Mitigations Data). The following three sections describe the engines required to compute the CVAs (portfolio, incremental and marginal) using a Monte-Carlo framework. This has become a market standard: The simple MtM+Addon technique although fast does not meet today s precision requirements and ignores Collateral and Netting features. Semi analytic methods are more precise but they also ignored Netting and do not handle path dependencies. 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 VaR which is a short term analysis (up to a 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. A scenario generation will be considered valid for a certain time which should remain scalable upon market conditions or user defined parameters. Pricing Engine Because the general framework is Monte-Carlo based, it is preferable for performance purposes not to use Monte-Carlo based pricing models. As a result, proxy pricing models are probably worth developing. One requires pricing a trade on each node a node being defined by a date and a path-. As a result the amount of unit pricing is very large: The use of GPU or Grid techniques should be investigated.
In terms of interface, pricing functions have to access Collateral data. Even though access to Market Data may in theory not be relevant (in case full market data set is provided by the scenario generator), it is probably safer to assume that the Pricing engine is interfaced with Market Data. Aggregation Engine The purpose is to compute a CVA number from the individual trade NPVs computed on each node. A key point is to take Netting information into account.
Process description The purpose of this section is to describe a possible framework to compute CVA and incremental CVA in an efficient and scalable way. This framework is based on Engine s output data referred as cubes. From a technical point of view, these cubes have to provide high volume capacities and fast computation times. These criteria are basically fulfilled by OLAP cubes technology. We assume that all required data warehouses (market, static, collateral, margin, netting and portfolio) are loaded and accessible. Scenarios cube This cube is filled in with a Scenarios Feeder. This feeder takes the output from the Scenarios Generator Engine and populates the cube. 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. Values cube 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 (For example, if a Barrier has been crossed or an option exercised). For this task, parallel computing (on trade and path axis) is a must-have. At that point and based on the fine-tuning results, one can decide to split the Values cube into intermediate cubes (For example one cube per Netting set). Based on these two cubes, we can describe the CVA and Incremental CVA processes: CVA Taking the Values cube as an input, the Aggregation Engine has to: Compute the portfolio credit exposure on each node by computing first the credit exposure per Netting set, then summing, Compute the portfolio CVA on each path by discounting and applying the default terms (Loss given default, default probability) then summing the credit exposures computed above, Average the CVAs computed on each path to get the portfolio CVA.
Incremental CVA for pre-deal check The original CVA is processed as described in the previous section. The Pricing Feeder is called on the incoming pre-deal in order to compute the value of this deal on each node. We then compute the CVA of the new portfolio (original portfolio + pre-deal) and get the incremental CVA as the difference between the original and new CVAs. The pre-deal values are deleted from the Values cube. CVA DESK: PROCESS SCENARIO GENERATOR ENGINE SCENARIO FEEDER SCENARIOS CUBE PRICING ENGINE PRICING FEEDER VALUES CUBE AGGREGATION ENGINE Incremental CVA, Marginal CVA, Portfolio CVA DVA has not been explicitly discussed but it can be handled by the same processing.
Conclusion This document gives an overview of the set of required interfaces for a CVA Information System. It describes a possible starting point that could be used to define a CVA Desk implementation project framework. Global Market Solutions is providing expertise in implementation and integration projects of financial software for all following activities: Front-Office and Pricing Models, Risk Management, Back-Office and Straight Through Processing, Accounting and Regulatory Reporting, Business and Technical analysis, solution design, development and project management on Capital Market software (Kondor+, Summit, ActivePivot, Orchestrade).