Implementing CCR and CVA in a Primary International Bank

Transcription

1 Implementing CCR and CVA in a Primary International Bank

2 Index Introduction 1 Introduction 2 3

3 Index Introduction 1 Introduction 2 3

4 Counterparty Credit Risk and Credit Value Adjustment The main goal of the CCR is determining an adequate EC for actual unexpected counterparty credit losses, the future real distribution of the contracts exposures is needed, so that simulations can be performed with evolution of risk factors whose dynamics is calibrated on historical data, although the revaluation of the deals will be risk-neutral in any case. The CCR is not computed to be managed with hedging strategies, but it is based on a reserve approach. This means that sensitivities to risk factors are not needed. The CVA is a risk measure used to adjust the fair value of the derivatives contracts to account for expected losses due to the default of the counterparty. The value of a contract is adjusted at inception, either on a stand-alone or incremental basis, and then the adjustment is updated in the future accordingly to the NPV of the contract (or netted portfolio of contracts) and to the counterparty s PD.

5 Counterparty Credit Risk and Credit Value Adjustment Implications: The CVA is calculated using market data, Consistency constraints: The future distribution of the netted portfolio of contracts with a given counterparty, being risk neutral, is obtained by a unified framework whereby the both the simulation and the pricing are performed by the same (risk-neutral) dynamics for the relevant risk factors. CVA s sensitivities to the risk factors have to be computed so as to allow for a dynamic hedging of its volatility by market instruments. Challenges: the CVA is calculated by numerical schemes (e.g.: Montecarlo): the computational burden is quite heavy if these have to produce also sensitivities, the reliability of the results has to be carefully verified: numerical differentiation is unstable for Montecarlo and many thousands of simulations are needed to achieve acceptable accuracy.

6 Counterparty Credit Risk and Credit Value Adjustment CCR CVA Risk Factor Dynamics Real Risk Neutral Pricing of Contracts Risk Neutral Risk Neutral Sensitivities No Yes Goal EC Fair Value Adjustment & Hedging Table: Differences between CCR and CVA.

7 Index Introduction 1 Introduction 2 3

8 CCR Workflow

9 How Scenarios are Generated 1 The general principle is to take the initial market data and apply to them bumps computed by simulation models. 2 The bumped market data at the moment are Zero curves OIS and fixing (1M, 3M, 6M and 1Y) Libor curves; FX rates; 3 No bumping is applied to volatility surfaces future dates are considered. 5 For each future date, 1000 scenarios are generated.

10 Interest Rates Short rate bumps are generated through the following model: dr t = κ[θ(t) r t]dt +σdw t 4 BUMP EONIA BUMP EONIA This is a single factor short rate model which produces the entire set of discount factors for the basic OIS curve Fixing Libor curves are generated by assuming a constant spread over the OIS curve

11 FX Rates For the path simulation of the FX rate the model used is a Brownian bridge. The FX rate is assumed to be a standard BGM: 1.4 Bumping EUR/USD Bumping EUR/USD 1.2 ds = rsdt +σsdw The Brownian Bridge has the following distribution: W s u = ( (s u) W N, t u ) (t s)(s u) t u

12 Deal Revaluation For each time step and each scenario the FRE (Full Revaluation Engine) reprices every deal. For each deal there is a cube of NPVs over 1000 scenario 40 time steps. The risk control group receives these data and aggregate them according to existing netting and collateral agreements.

13 Facts at the Beginning of the Project CVA was calculated with the approach sketched above with the following IT resources: Hardware: grid of 3,500 Windows 64 bit cores, but only 300 actually exploited; Software: FRE client, a multi-thread Java application running on Solaris host. FRE server, a Java application developed as a Platform Symphony service (grid service) on Windows host The portfolio comprised about 45,000 OTC contracts. The computation time was 5 days.

14 Facts to Date The CVA project follows two lines of intervention: Overhaul of the FRE client and server, by eliminating bottleneck and allowing the complete usage of the available grid; Rewriting of the pricing function, in C++/Java. Some formulae of the proprietary financial library have been optimised to make them as fast as possible for CVA purposes. For FX products, pricing formulae have been written based on the B&S model with Vanna-Volga adjustments. The technological stream of the project has achieved a reduction in the calculation time to 3.5 hours. The methodological stream has added a further reduction so that the total computation time is now of 1.5 hours.

15 Future Steps In next future the project will focus on two classes of products to be added to the existing ones: Equity derivatives; Credit derivatives;

16 Index Introduction 1 Introduction 2 3

17 Full Revaluation Engine The core of the CVA calculation is the so called Full Revaluation Engine (FRE), performs the following tasks: loading trade data; loading market data for each scenario; pricing of each trade for each scenario and for each future date; output of data in a cube form (one dimension representing trades, another scenarios and the last one representing dates). A more centralized organization of the calculations is vital to achieve improved performances, which means more accurate results and more information (EPE, PFE, Greeks, etc.).

18 Full Revaluation Engine Scenario Netting Sets Simulation and Collateral Revaluation and Greeks Risk Metrics and CVA Scenarios generated for relevant asset classes: Interest Rates FX Spot Rates Credit Spreads Equity Prices Deals aggregation for: Clients Netting Set Collateral management Deals revaluation in all scenarios Greeks with respect to market risk factors Undrelrying asset(s) Volatility Correlation Expected and potential exposures: EPE PFE Fair Value Adjustment: CVA Figure: Proposed Workflow for the FRE.

19 Full Revaluation Engine In the new setting, the FRE performance would benefit from the centralized operations on the deals aggregation and collateral management and on the joint scenario generation and revaluation. This will allow to implement very efficient procedures to: Price deals and netted portfolios; Management of the collateral and of the grace periods after defaults; Greeks calculations (see below).

20 Fast Pricing Function There is a huge scope for improving the performance of the calculation engine. Interest rate swaps (IRS) and caps&floors are best candidates. The guiding principle in optimizing the pricing functions are: Reduce the amount of arithmetic operations required to calculate the cashflows. The idea is to pre-compute all the cash-flows (both for the fixed and for the floating leg) and storing them into an array that is passed into the pricing function that evaluates the flows and do the present value calculation. Simplify the calculations and avoiding many calculations inside the pricing function. This strategy gives a reduction of the computational effort required by the pricing function, speeding up the overall computation time.

21 Fast Pricing Function For ease of comparison we show in table 2 the computation times of the standard Unilib functions and the new optimized functions for a standard swap contract and a cap&floor, both maturing in 5 years. The CPU is an Intel Core2Duo 2.93 GHz, 3.46GB of RAM. N. per 1 sec. IRS µs per 1 contract Standard Functions 200 5,000 Optimized Functions 50, N. per 1 sec. C&F µs per 1 contract Standard Functions 200 5,000 Optimized Functions 10, Table: Number of contracts priced in 1 second and the number of microseconds required to price 1 contract with the standard and optimized functions.

22 Parallel calculus and GPUs The availability of massively parallel hardware, such as GPUs, makes possible the acceleration of the pricing algorithms. To take advantage of this kind of hardware, the libraries have to be overhauled at a code level, by a complete re-writing to make them fit into a SIMD paradigm (single instruction multiple data). Two approaches are possible: 1 fast pricing of complex derivatives: parallel hardware is used to solve partial differential equations with finite elements method (involve linear algebra routines) or with Montecarlo method (simulation on many path in parallel); a single trade is priced in a fast way; 2 parallel pricing of simple products: pricing of plain vanilla trades of a large portfolio (e.g.: swaps) can be decomposed in the pricing of simple components (e.g.: swap cash-flows), components can be aggregated (stored in large arrays) and priced in parallel, finally components prices can be summed to get trades prices; many trades are priced simultaneously.

23 Parallel calculus and GPUs We show the calculation times for the optimized functions on the standard CPU described (same as in second row of table 2) and on a GPU Nvidia Tesla M2070Q. N. per 1 sec. IRS µs per 1 contract CPU 50, CPU 1,000,000 1 N. per 1 sec. C&F µs per 1 contract CPU 10, CPU 170, Table: Number of contracts priced in 1 second and the number of microseconds required to price 1 contract.

24 American Montecarlo Method Typically metrics such as EPE or PFE imply a numerical revaluation of netted portfolios via Montecarlo. Montecarlo simulations are used to generate scenarios of risk factors, and when also the deals included in the portfolio need a Montecarlo pricing, the computation burden easily becomes unbearable. The purpose of the American Montecarlo (AM) is to speed up the pricing of exotic trades that requires a Montecarlo method. The brute force approach would be a Montecarlo pricing in each of the (thousands) generated scenarios. The AM optimization consists in the use of the scenarios path to perform evaluation of the exotic trades, avoiding the run of a nested Montecarlo.

25 Greeks Introduction Greeks can be computed brute force by finite difference method: a Montecarlo simulation is launched with tilted starting value of the relevant stochastic factor(s) and/or parameters and the sensitivities are derived from the resulting change in the contract s value. This method is clearly very expensive under a computational point of view and it is worth exploring efficient alternatives whenever they are feasible. We suggest two methods with low computational intensity: 1 Adjoint algorithmic differentiation: It relies on the fact that computer programs are composed of a set of elementary functions; once partial derivative of these elementary function are known, derivatives can be computed using the chain rule. 2 Linear regression:ne tries and approximate by a polynomial the value of a contract. The coefficient of the polynomial are obtained by fitting the chosen function to the terminal valued of the contract simulated by the Montecarlo procedure. The calibrated polynomial is then used to retrieve the value of the contract at any date before the expiry.

26 About Iason Iason is a company created by market practitioners, financial quants and programmers with valuable experience achieved in dealing rooms of financial institutions. Iason offers a unique blend of skills and expertise in the understanding of financial markets, in the pricing of complex financial instruments and in the measuring and the management of banking risks. The company s structure is very flexible and grants a fully bespoke service to our Clients. Iason believes that the ability to develop new quantitative finance approaches through research, and to apply them in practice, is critical to innovation in risk management and pricing. It constantly strives to bring into all the areas of the risk management a new and fresh approach based on the balance between rigour and efficiency which its people aimed at when working in the dealing rooms. Besides tailor made services, Iason develops software applications to calculate and monitor credit VaR and conterparty VaR, fund transfer pricing and loan pricing, liquidityat-risk. c Iason /2011 This is a Iason s creation. The ideas and the model frameworks described in this presentation are the fruit of the intellectual efforts and of the skills of the people working in Iason. You may not reproduce or transmit any part of this document in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Iason ltd.