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 Desk Implementation
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 credit-
risky (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 Implementation
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.
CVA Desk Implementation
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.
CVA Desk Implementation
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.
CVA Desk Implementation
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.
CVA Desk Implementation
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.
CVA Desk Implementation
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: PRO CESS
SCENARIO
GENERATOR SCENARIO FEEDER
ENGINE
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.
CVA Desk Implementation
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).
CVA Desk Implementation