The post Strata and multi-curve: Interpolation and risk appeared first on OpenGamma.
]]>One important point in the discussion on interpolation in interest rate curve, before the question on how to interpolate should be the question of What to interpolate? I do not plan to discuss that issue in this blog, but you can find my rant on the subject in Section 4.1 of my book on the multi-curve framework (Henrard (2014)). In this blog, I have decided to use interpolation on the zero-rate (continuously compounded), which is probably the most used approach
We start with the graphical representation of impact of interpolation. For this I use that same data as used in the previous blog, calibrating two curves in GBP to realistic market data from 1-Aug-2016. One curve is the OIS (SONIA) curve and the other one is the forward LIBOR 6M curve. The nodes of the curves are the node prescribed by the FRTB rules (see BCBS (2016)). Similar effects would be visible with roughly any selection of node; they were selected for convenience.
We will use through this blog three types of interpolation schemes: linear, double quadratic and natural cubic spline. The reason for the choice is to have interpolation schemes with different properties, I do not claim that those are the best for all (or even any) purposes. The graph of the forward Sonia rates, daily between the data date and 31 years later is displayed in Figure 1. Each date is represented by one point.
Figure 1: Overnight forward rates with three different interpolators.
The forward rates for the Libor curves are provided in Figure 2.
Figure 2: Libor 6M forward rates with three different interpolators.
The graphs are like the familiar one on any note related to curve interpolation. The linear interpolation leads, even with very clean data like in this example, to forward rates profiles with saw tooth effect. Some impacts are very pronounced; in the middle of the graph there is a drop of 40 bps in forward rate from one day to the next. An almost similar drop if visible in the Libor graph, but this time on a period of 6 months (one tenor of the underlying Libor). There is also a large difference between the different interpolators. In the case of the overnight rates, the largest difference in forward rate is 39.29 bps and is observed for the rate starting on 31-Jul-2046 (30 years forward) between the linear and the double quadratic.
The code used to produce the above graphs are available in the blog example Strata code [link]. The code to produce the above curves is roughly 10 lines. The code to export the data to be graphed by Matlab is longer than the calibration code itself.
The interpolation mechanism does not only have an impact on the forward rates, and thus on the present value, but also on the implied risk. We now look at this risk, using the bucketed PV01 or key rate duration as the main risk indicator. For this we take one forward swap with starting date in 6 months and a tenor of 9 years. The fixed rate is 2.5% (above market rate). For that swaps, the par rate bucketed PV01 are provided in Figures 3 to 5.
Figure 3: PV01 with linear interpolation scheme
Figure 4: PV01 with double quadratic interpolation scheme
Figure 5: PV01 with natural cubic spline interpolation scheme
The first point to notice is that the sum of the bucketed PV01 for both the OIS curve and the Libor curve are almost the same for all interpolation schemes. A parallel curve move results in similar change of PV and there is only a very small effect from the level and the curve shape.
The interesting part is obviously the differences. The double quadratic and natural cubic spline are non-local interpolators. The sensitivity to the cash flows in the 5Y to 10Y period extend beyond the 5Y and 10Y nodes. There is a sensitivity to the 3Y and 15Y points, and in the case of the natural cubic spline (NCS), even to the 20Y and 30Y points. The non-locality can lead to non-intuitive hedging results. In the NCS case, the hedging of the swap with a maturity of 9Y and 6M is done with swap up to 10Y but also with swaps of maturity 15Y, 20Y and 30Y. Note also the “wave” effect where the hedging is done alternatively with swap of the opposite direction as the original one and the same direction.
The code to calibrate the three sets of curves and computing the related par market quote sensitivities – the variable mqs in the code – takes only 10 lines:
/* Calibrate curves */ ImmutableRatesProvider[] multicurve = new ImmutableRatesProvider[3]; for (int loopconfig = 0; loopconfig < NB_SETTINGS; loopconfig++) { multicurve[loopconfig] = CALIBRATOR.calibrate(configs.get(loopconfig).get(CONFIG_NAME), MARKET_QUOTES, REF_DATA); } /* Computes PV and bucketed PV01 */ MultiCurrencyAmount[] pv = new MultiCurrencyAmount[NB_SETTINGS]; /* Computes PV and bucketed PV01 */ MultiCurrencyAmount[] pv = new MultiCurrencyAmount[NB_SETTINGS]; CurrencyParameterSensitivities[] mqs = new CurrencyParameterSensitivities[NB_SETTINGS]; for (int loopconfig = 0; loopconfig < NB_SETTINGS; loopconfig++) { pv[loopconfig] = PRICER_SWAP.presentValue(swap, multicurve[loopconfig]); PointSensitivities pts = PRICER_SWAP.presentValueSensitivity(swap, multicurve[loopconfig]); CurrencyParameterSensitivities ps = multicurve[loopconfig].parameterSensitivity(pts); mqs[loopconfig] = MQC.sensitivity(ps, multicurve[loopconfig]); }
It is also interesting to look at a “dynamic” version of the above PV01 report. For that I will produce the same report for swaps with starting dates between the data date and two years later and all of them with a tenor of 8 years. The swap maturities will be between 8 years and 10 years. Let’s start with the linear interpolation scheme as it displays the profile that most people would probably consider as intuitive (at least I do). That profile is displayed in Figure 6. For a 8Y spot starting swap (the left side of the graph), the sensitivity is mainly on the 5Y and 10Y IRS with more on the 10Y. The main sensitivities are represented by the colour curves; the other sensitivities (Libor and OIS) are represented by the dark grey thin lines. When we move to the 2Yx8Y swap along the X-axis, we see the sensitivity to the 10Y increase and the sensitivity to the 5Y decrease down to zero. The sensitivity to the 2Y increase in absolute value but with the opposite sign to the 10Y. The total sensitivities of the swaps are fairly constant.
Figure 6: PV01 profile for linear interpolation scheme.
Figure 7: PV01 profile for double quadratic interpolation scheme.
Let’s jump immediately to the natural cubic spline profile displayed in Figure 8; the Figure 7 for double quadratic is in between the other two. For that profile, I will start the explanation from the right side, with the 2Yx8Y forward swap. The risk is very similar to the one depicted by the linear interpolation. The main sensitivities (2Y and 10Y) are on nodes and the sensitivity in the two cases are similar. When we move away from the nodes, in our case with the starting date moving down from 2Y to valuation date and the maturity from 10Y down to 2Y, a different profile appear. Sensitivities are not anymore only to the nodes surrounding the swap dates. There are now significant sensitivities to the adjacent nodes (3Y and 15Y for example) with the opposite sign to the main sensitivities with a non intuitive behavior. For example the sensitivity to the 15Y node increases when the maturity of the swap moves away from that node. A significant sensitivity appear on the 2Y when the start date of the swap moves away from the 2Y node and is the larger in this profile for the spot starting swap.
Figure 8: PV01 profile for natural cubic spline interpolation scheme.
Obviously the sensitivity to different nodes will lead to recommended hedging using swaps with those tenors. The 8Y swap will be hedged with 2Y, 3Y, 5Y, 10Y and 15Y swaps. Maybe not the most intuitive approach. It is also possible to easily compute the require notional to hedge each sensitivity, and that will be described in a forthcoming instalment of this blog.
The goal of this blog was not to provide a definitive answer on which interpolation scheme to use for curve calibration – I don’t with there is such a definitive answer – but to show that a personal analysis is important. The analysis can be done easily with the right tools. The code used to produce figures 3 to 5 is available in the examples associated to this blog. The main part of the code consists in roughly 10 lines of code, for calibration and sensitivity computation. The other figures required a loop around that code to produce the sensitivities for roughly 500 swaps (2Y of business days).
In this instalment of the multi-curve blogs, we have provided some example of interpolation impact on forward rate and risk computations. We also showed how easy it is to obtain those results in the Strata code.
Henrard, M. (2014). Interest rate modelling in the Multi-curve Framework: Foundation, Evolution and Implementation. Palgrave.
BCBS (2016). Minimum capital requirements for market risk. Basel Committee on Banking Supervision, January 2016.
The post Strata and multi-curve: Interpolation and risk appeared first on OpenGamma.
]]>The post Strata and multi-curve: Curve calibration and bucketed PV01 appeared first on OpenGamma.
]]>Over the last few years, the pricing of vanilla derivatives has become more complex than ever before. This is the result of the basis increases, in particular OIS vs. LIBOR, and the generalisation of Variation and Initial Margins. At the same time, the market has moved to increased standardisation.
In this new framework it is more important than ever to have a flexible and generic approach to curve calibration, derivatives pricing and sensitivity computations. The first production release of our open source analytics library, Strata 1.0, was made available to the public on 15 July 2016. The second release, Strata 1.1, was released on 7 October 2016. One of the key strengths of Strata is its support for multi-curve pricing and risk calculations.
Over the coming months, I will publish a number of posts that detail some examples (and corresponding code) of how Strata can be used for OTC derivatives valuation and risk. This blog series is for quantitative analysts, risk managers, model validators and regulators who want to access tools that provide the required flexibility and precision in an easy-to-access environment.
Each of the blog posts will describe, in financial terms, the analysis that I have performed and the results obtained using Strata. I will make the code available for each example in our Strata examples project so that the readers can easily reproduce the analysis. If you have any questions or comments, please feel free to get in touch below or contact me directly at marc@opengamma.com.
In the first instalment, I will describe how to calibrate curves and compute PV and bucketed PV01 for swaps. The curve calibration will start from curve descriptions and data in simple CSV files and will cover the computation of ‘Jacobian’ matrices used later for sensitivity computations. The calibrated curves will be used to compute present values and bucketed PV01, also called bucketed delta or key rate duration. I will also comment on the efficiency obtained from the Algorithmic Differentiation used throughout the library. This instalment will be a little more technical than future ones as we will go through the code used to run the analysis. However, the step-by-step method should help non-technical users understand the process. Subsequent posts will focus more on the finance and risk management side.
Curve calibration is a mechanism that requires a lot of fine-tuning and precision, and at the same time is normally based on standard instruments and conventions. One would like to have a lot of flexibility and at the same time be able to create standard curves very easily. Luckily, Strata has been built with those two, almost contradictory, goals in mind.
Let’s start with the standard part. Many indices, conventions, and calendars in the main markets are built in. These standard objects can be accessed easily by name, which is just a simple string. For example, if you want to access the calendar for good business days in London, knowing its code GBLO is enough; to access the GBP LIBOR 6M index and its convention, knowing its name GBP-LIBOR-6M is enough; to access the standard market conventions for the GBP IRS with LIBOR 6M floating index, knowing its name GBP-FIXED-6M-LIBOR-6M is enough.
If you have read the paragraph above, you know almost enough to be able to calibrate curves in Strata.
Before going to the calibration, let’s discuss the flexibility side. The lists of built-in objects described above can be extended easily by the user. If you don’t like the list of holidays predefined in GBLO – perhaps a royal wedding needs to be added, or you have your own source of data – you can create your own calendar and use it in the same way as the built-in ones. If you want to create a new GBP index – maybe a potential replacement for LIBOR – you can add this to the library without writing a single line of code, simply by adding a single CSV file.
But enough of the flexibility for now. Let’s look at the calibration of a standard multi-curve framework with standard instruments in GBP. The description of a multi-curve starts by specifying which curves you have and what each of them are used for. In our simple case, we would like to have two curves: one for discounting in GBP and for forwards related to SONIA, and the other one for forwards related to GBP LIBOR 6M. Suppose that we give our multi-curve framework the name GBP-DSCONOIS-L6IRS, and our curve names are GBP-DSCON-OIS and GBP-LIBOR6M-IRS respectively. How do we pass this information to Strata? We simply create a CSV file with exactly this information. The file is:
Group Name,Curve Type,Reference,Curve Name
GBP-DSCONOIS-L6IRS,Discount,GBP,GBP-DSCON-OIS
GBP-DSCONOIS-L6IRS,Forward,GBP-SONIA,GBP-DSCON-OIS
GBP-DSCONOIS-L6IRS,Forward,GBP-LIBOR-6M,GBP-LIBOR6M-IRS
Next, we want to describe how the curve should be interpolated. Should it be on the zero-rates or on the discounting factors, and which interpolator should be used? We simply create a file with this information:
Curve Name,Value Type,Day Count,Interpolator,Left Extrapolator,Right Extrapolator
GBP-DSCON-OIS,Zero,Act/365F,Linear,Flat,Flat
GBP-LIBOR6M-IRS,Zero,Act/365F,Linear,Flat,Flat
Finally, you want to describe each node of the curve in an easy way. This is where the built-in conventions will make your life very easy. A description of the curves could look like:
Curve Name,Label,Symbology,Ticker,Field Name,Type,Convention,Time,Spread
,,,,,,,,
GBP-DSCON-OIS,GBP-ON,OG-Ticker,GBP-ON,MarketValue,DEP,GBP-ShortDeposit-T0,1D,
GBP-DSCON-OIS,GBP-TN,OG-Ticker,GBP-TN,MarketValue,DEP,GBP-ShortDeposit-T1,1D,
GBP-DSCON-OIS,GBP-OIS-1M,OG-Ticker,GBP-OIS-1M,MarketValue,OIS,GBP-FIXED-1Y-SONIA-OIS,1M,
GBP-DSCON-OIS,GBP-OIS-2M,OG-Ticker,GBP-OIS-2M,MarketValue,OIS,GBP-FIXED-1Y-SONIA-OIS,2M,
GBP-DSCON-OIS,GBP-OIS-3M,OG-Ticker,GBP-OIS-3M,MarketValue,OIS,GBP-FIXED-1Y-SONIA-OIS,3M,
etc...
GBP-LIBOR6M-IRS,GBP-FIX-L6M,OG-Ticker,GBP-FIX-L6M,MarketValue,FIX,GBP-LIBOR-6M,,
GBP-LIBOR6M-IRS,GBP-FRA-3Mx9M,OG-Ticker,GBP-FRA-3Mx9M,MarketValue,FRA,GBP-LIBOR-6M,3Mx9M,
GBP-LIBOR6M-IRS,GBP-IRS6M-1Y,OG-Ticker,GBP-IRS6M-1Y,MarketValue,IRS,GBP-FIXED-6M-LIBOR-6M,1Y,
GBP-LIBOR6M-IRS,GBP-IRS6M-2Y,OG-Ticker,GBP-IRS6M-2Y,MarketValue,IRS,GBP-FIXED-6M-LIBOR-6M,2Y,
GBP-LIBOR6M-IRS,GBP-IRS6M-3Y,OG-Ticker,GBP-IRS6M-3Y,MarketValue,IRS,GBP-FIXED-6M-LIBOR-6M,3Y,
etc...
For each curve, there is a corresponding list of nodes. Each node has a name (for result display purposes) and a link to the data to be used. The data to be used is composed of a ‘Symbology’, a ‘Ticker’ and a ‘Field Name’. Here I have used ‘OG-Ticker’ (for OpenGamma, not ‘Olympic Games’), but these can be replaced with ‘Bloomberg-Ticker’ or ‘MyBankProprietaryName’ dependent on the user’s preference. The ‘Ticker’ itself could be ‘BPSW10’ or again your own internal naming convention. For the ‘Field Name’ I have used ‘MarketValue’, but you could choose something like ‘Bid’, ‘Ask’ or ‘LastQuote’. Next, you specify the type of instrument. Here we restrict ourselves to DEP (term deposit), OIS (fixed vs. overnight swap), FIX (Ibor fixing), FRA (Forward Rate Agreement) and IRS (fixed vs. Ibor swaps). Other possibilities include IFU (Futures), BAS (Basis swaps), ONI (Overnight vs. Ibor swaps), and these will be discussed in future instalments. The last two columns are the ‘convention’ and the ‘time’. The convention is one of the built-in or user-defined conventions; the type of convention depends on the specified instrument type. The ‘time’ is the tenor for the instruments used above. More complex times can be created to describe FRAs and futures.
The last ingredient for curve calibration is the actual data. In this example, we calibrate the curve as of 1 August 2016.
Valuation Date,Symbology,Ticker,Field Name,Value
,,,,
2016-08-01,OG-Ticker,GBP-ON,MarketValue,0.0042
2016-08-01,OG-Ticker,GBP-TN,MarketValue,0.005
2016-08-01,OG-Ticker,GBP-OIS-1M,MarketValue,0.0023
2016-08-01,OG-Ticker,GBP-OIS-2M,MarketValue,0.0021
2016-08-01,OG-Ticker,GBP-OIS-3M,MarketValue,0.002
etc...
2016-08-01,OG-Ticker,GBP-FIX-L6M,MarketValue,0.0057969
2016-08-01,OG-Ticker,GBP-FRA-3Mx9M,MarketValue,0.0045
2016-08-01,OG-Ticker,GBP-IRS6M-1Y,MarketValue,0.0051
2016-08-01,OG-Ticker,GBP-IRS6M-2Y,MarketValue,0.0048
2016-08-01,OG-Ticker,GBP-IRS6M-3Y,MarketValue,0.0049
etc...
I believe that the file names speak for themselves.
We have done the hard work by collecting the data and deciding which nodes we want to use in our curves. We are now four lines of code away from having the curves.
First, load the data from the configuration files:
Map<CurveGroupName, CurveGroupDefinition> configs = RatesCalibrationCsvLoader.load(GROUP_RESOURCE, SETTINGS_RESOURCE, NODES_RESOURCE);
Second, load the data:
Map<QuoteId, Double> MAP_MQ = QuotesCsvLoader.load(VALUATION_DATE, ResourceLocator.of(QUOTES_FILE));
Third, collect the data in the right format:
ImmutableMarketData MARKET_QUOTES = ImmutableMarketData.builder(VALUATION_DATE).values(MAP_MQ).build();
And finally, calibrate the curves:
RatesProvider multicurve = CALIBRATOR.calibrate(configs.get(CONFIG_NAME), MARKET_QUOTES, REF_DATA);
Of the four lines of code, only the last one, where the actual calibration take place, requires some explanation. I will not go through the theory of multi-curve and calibration; this is presented in other places. If I may, I would recommend Chapter 5 of my book [Henrard (2014)].
The only ingredient useful in this discussion is that in the calibration procedure, we solve a root-finding exercise to obtain parameters of the interpolated curves such that for all the instruments describing the nodes,
PV(Instrument) = 0.
This root-finding algorithm is run for all the curves simultaneously (footnote 1). For each PV to be 0, the parameters we have selected must be such that all the benchmark instruments reproduce exactly the market price using the calibrated curves. In the curve calibration process, not only are the curves themselves calibrated and stored but so are the Jacobians or transition matrices. I will describe what those matrices are and why we care about them below.
The first application of the calibrated curve that we can think of is to compute the present value of a swap that we have traded. From the rate of the benchmark swaps (and the interpolator) we want to infer the value of a non-benchmark instrument.
For that, we need first to create a swap. Here again, our OpenGamma conventions come in handy. We take a standard convention, specify the trade date, the period to start, tenor, side, notional and coupon, and we are done:
ResolvedSwapTrade swap = GBP_FIXED_6M_LIBOR_6M.createTrade(
VALUATION_DATE, SWAP_PERIOD_TO_START, Tenor.of(SWAP_TENOR), BuySell.BUY, SWAP_NOTIONAL, SWAP_COUPON, REF_DATA)
.resolve(REF_DATA);
We want to compute the present value of this swap using the multi-curve we have calibrated above:
MultiCurrencyAmount pv = PRICER_SWAP.presentValue(swap, multicurve);
The output is a MultiCurrencyAmount object to deal with the cross-currency swaps that we will discuss in a later instalment.
Immediately after the present value, the next thing that a trader or a risk manager will want is the bucketed PV01, also called bucketed delta, rate sensitivities, or key rate duration. Before talking about the code needed to obtain this, we have to define what we mean by ‘bucketed PV01’ as there are three versions of it available in Strata.
The three different sensitivities available are: point sensitivity, parameter sensitivity, and market quote sensitivities. The point sensitivity is the sensitivity, in the sense of the mathematical partial derivative, of the present value with respect to each zero rate of discounting curves and each forward rate of forward curves. By each zero-rate or forward rate, we mean that each single date on which there is a cash flow or a fixing take place is represented in the sensitivity; the sensitivities are not only to the curve nodes but to each single date in the instrument. The main use of this type of information is to view the daily fixing sensitivities and see if there are dates with large fixing impacts.
An example of point sensitivities for a one year GBP swap is displayed below. There are four cash flows (two on each leg) producing four zero rate sensitivities. There are also two forward Ibor rate sensitivities.
ZeroRateSensitivity{curveCurrency=GBP, yearFraction=0.5808219178082191, currency=GBP, sensitivity=71940.4415752365}
ZeroRateSensitivity{curveCurrency=GBP, yearFraction=1.084931506849315, currency=GBP, sensitivity=136526.2295146616}
IborRateSensitivity{observation=IborIndexObservation{index=GBP-LIBOR-6M, fixingDate=2016-09-01, effectiveDate=2016-09-01, maturityDate=2017-03-01, yearFraction=0.4958904109589041}, currency=GBP, sensitivity=4954388.900936099}
ZeroRateSensitivity{curveCurrency=GBP, yearFraction=0.5808219178082191, currency=GBP, sensitivity=-16317.31422092133}
IborRateSensitivity{observation=IborIndexObservation{index=GBP-LIBOR-6M, fixingDate=2017-03-01, effectiveDate=2017-03-01, maturityDate=2017-09-01, yearFraction=0.5041095890410959}, currency=GBP, sensitivity=5033542.805338534}
ZeroRateSensitivity{curveCurrency=GBP, yearFraction=1.084931506849315, currency=GBP, sensitivity=-23843.440872413255}
The parameter sensitivity is the sensitivity of the present value to the parameters used internally to represent the curves. The parameters are often the zero-coupon rates or discount factors at the nodes of an interpolated curve.
The market quote sensitivity, also called par rate sensitivity, is the sensitivity of the present value to the raw market quotes used in the curve calibration. Of the three sensitivities, this is the risk figure the most used by traders and risk managers.
An example of market quote sensitivities for a swap 3 months forward and with a 7-year tenors is provided below.
Each of those sensitivities can be obtained easily in one line of code. The code that was used to produce the results shown above is:
PointSensitivities pts = PRICER_SWAP.presentValueSensitivity(swap, multicurve);
CurrencyParameterSensitivities ps = multicurve.parameterSensitivity(pts);
CurrencyParameterSensitivities mqs = MQC.sensitivity(ps, multicurve);
It is now a good time to discuss the computation of Jacobian matrices in the curve calibration. These are the matrices used to transform a parameter sensitivity to a market quote sensitivity. They depend only on the curves and not on the instrument for which the sensitivity is computed. It thus makes sense to compute them only once and to do it when the curves are calibrated. This is what is done in Strata: when the curves are calibrated, it is possible to request the computation of the Jacobian matrices. If requested, these matrices will be computed and stored in the ‘metadata’ associated to the curve. They are then available for later use whenever they are required.
As we are discussing the computation of sensitivities, we should add that all sensitivities in Strata are computed using Algorithmic Differentiation (AD). The theory of this computer science technique is described in Naumann (2012). For this blog it is sufficient to know that the technique produces derivatives by analytical computation, and it is very efficient. Analytical computation means that it avoids numerical methods like finite difference, and produces sensitivities that are more precise while avoiding numerical instability. The best way to discuss its efficiency is through a couple of examples.
We first calibrate a set of curves and compute the present value of 100 swaps. The elapsed wall-clock time for this is recorded. In the example above, there are 29 data inputs for the curve calibration. If we were to use the standard bump-and-recompute technique we would redo this process 29 extra times with small changes in inputs, which would require 30 times more CPU time.
In my example, on standard desktop hardware and using only a single thread, the time taken for the multi-curve calibration and the computation of 100 PVs is 9.98 ms (footnote 2). Computing the market quote bucketed PV01 by finite difference would take 30×9.98ms = 299.4 ms (footnote 3). If we compute the (three versions of) sensitivities using AD, we have a computation time of 15.37 ms. This is roughly 20 times faster than a simple bump-and-recompute.
You might argue that the example with only 100 swaps is not realistic. Running the example instead with 2,000 swaps (tenors between 1Y and 20Y and 100 different coupons for each tenor) took 32.46 ms to calibrate the curves and calculate PV. Extending this to include sensitivities computed by AD took 162.88 ms, whereas obtaining the same values by finite difference would have taken 973.8 ms. In this example algorithmic differentiation is roughly 6 times faster than finite difference. We will show in forthcoming blogs that this improved performance is even better when there are more nodes on the curves.
This means any trader, portfolio manager or risk manager could compute the risk of this portfolio in near real-time using only his or her desktop computer.
We will increase the complexity of the portfolio in a later instalment of the blog.
Strata offers a very easy API to calibrate interest rate curves, create trades and compute risk measures. As Algorithmic Differentiation is implemented in the code, the calibration and computation of sensitivities is extremely efficient.
That’s all for today.
The code used for this blog is available in the Strata repository: strata-examples in the package ‘com.opengamma.strata.examples.blog.stratamulticurve1’
The numbers can also be obtained in Excel using the StrataExcel add-in. Don’t hesitate to contact us for a demo.
In the next instalment of this blog series, we will discuss the impact of the curve interpolator on the curve smoothness and on the bucketed PV01.
We have long experience in interest rate derivatives valuation, both from a financial engineering perspective, and from a technology perspective. We help banks, hedge funds, asset managers and clearing houses to quickly start or improve their risk management practice for swap trading.
Examples of engagements:
Client: Hedge fund
Issue: Specialized in futures trading, would like to extend the trading universe to IRS.
Solution: Create tools for their quant and risk managers to analyse pricing and hedging. Historical analysis of strategy P/L and hedging behavior.
Client: Clearing house
Issue: Clear single currency swap and would like to expend clearing offering to cross-currency swaps.
Solution: Build Excel-based tools to price and risk manage cross-currency swaps. Analyse the relevant regulation for bilateral margin which is a competitor to clearing. Compare with standard bilateral margin methodologies.
Client: Asset manager – pension fund
Issue: Trade assets in foreign currency and swap them to their base currency; need tools to value multi-currency swap books with collateral in base currency cash.
Solution: Create multi-currency swap valuation based on cross-currency swap between base currency and other currencies.
Client: Bank ALM
Issue: swap book. Multi-curve, collateral, VaR
Solution: Comparison of methodology, benchmarking of their VaR methodologies with alternative approach. Historical analysis of their full swap book. Based on existing trade booking system, with a thin layer of OpenGamma software; historical analysis running on quarterly basis.
Henrard, M. (2014). Interest rate modelling in the Multi-curve Framework: Foundation, Evolution and Implementation. Palgrave.
Naumann, U. (2012). The Art of Differentiating Computer Programs. An introduction to Algorithmic Differentiation. SIAM.
The post Strata and multi-curve: Curve calibration and bucketed PV01 appeared first on OpenGamma.
]]>The post CSA Changes: Do You Really Understand the Impact? appeared first on OpenGamma.
]]>Negotiating each agreement can be lengthy and, with timing a real and harsh constraint, dealers are keen to have clients sign new standardised CSAs so trading can carry on as usual. But making the right decision is no easy task for the buy-side; it is vital they do so as it can impact the value of portfolios by millions of pounds sterling.
There are three options:
The first step in the process is to compare the value of portfolios with the economic impact that amending collateral terms in a CSA will have. You may be shocked.
In our analysis, we’ve assumed that a typical book is made up of the following types of trades:
We valued them under various CSA terms (detailed later), using trades across the three main currencies: GBP, USD, EUR. So what were the key takeaways?
Now let’s get into the meat of the problem.
To quantify the impact that CSA terms have on a typical portfolio, we have made some additional assumptions: that exposures are directional, with trades having significant notionals.
We quantified the impact of collateral eligibility on PV, with 2 common CSA types:
Firstly, let’s take a look at a Vanilla Interest Rate Swap for example, a standard 100m 40Y USD Libor 3M IRS maturing in 30 years. The PVs for this swap under the various CSA terms described are given in Table 1. As you can see the terms of the CSA dictate the valuation of the swap:
CSA Type |
CSA1 Single Ccy |
CSA2 Multi Ccy |
Trade PV |
£85m |
£75m |
Table 1: Valuation of a 40Y USD LIBOR 3M IRS with 30Y remaining maturity under different CSA terms
If we assume that the current discounting method to date has been Libor discounting, the valuations differences to Libor discounting are:
CSA / Valuation Type |
Libor disc. |
CSA1 Single Ccy |
CSA2 Multi Ccy |
Trade PV |
£80m |
£5m |
£-5m |
Table 2: Valuation of a 40Y USD LIBOR 3M IRS with 30Y remaining maturity using Libor discounting and under different CSA terms
The difference in values between CSA1 and CSA2 is very interesting, as it quantifies the valuation impact of switching from a multi-currency cash CSA to a single-currency cash CSA (or vice-versa) – in our example, this difference is £10m, or 10% of the trade notional.
Why such a difference? It’s down to the fact that a multi-currency CSA will typically assume a ‘Cheapest-to-Deliver’ approach to collateral selection and therefore discounting. At current market levels, the trade cash flows are discounted using EUR EONIA, translated to the trade currency through cross-currency swaps.
Can the same be said for other OTC products? To answer this question, we turn to cross-currency swaps. Changing the CSA terms for a £100m 30Y GBP / USD cross-currency swap with 20 years remaining maturity yielded the following results:
CSA / Valuation Type |
CSA1 |
CSA2 CTD disc. |
Valuation |
Trade PV |
£-49m |
£-42m |
£-56m |
Table 3: Valuation of a 30Y GBP/USD CCS with 20Y remaining maturity under different CSA terms and valuation approaches
CSA1 and CSA2 valuations factor in the cross-currency basis – the impact of switching from a multi-currency cash CSA to a single-currency cash CSA (or vice-versa) is £7m, or 7% of the trade notional.
Under the valuation approach without the cross-currency basis, the OIS discounting for each of the legs has to be done independently, resulting in a significant PV difference (7% of notional). This is equivalent to a significant spread on the trade: 35 bps in this example.
So to answer the previous question, representative products found in a typical LDI portfolio are affected by changing the terms in a CSA. In particular, they are all significantly affected by switching from a multi-currency CSA to a single-currency CSA.
Correctly valuing cross-currency instruments is also critical: the reflection of the cross-currency basis can add up to a difference in mark-to-market in the tens of millions.
You may be sitting there thinking, “Well my CSAs are clean: mostly cash and some with gilts, so none of this applies to me.” Unfortunately, you would be wrong. As we showed earlier, differences in discounting between a single- and multi-curve framework have a significant impact on the valuation of the portfolio. This applies for future trades as well as current trades. Correctly valuing these instruments by factoring in the impact of collateral terms has the following benefits for asset managers:
OpenGamma’s independent valuation service is based on our award-winning analytics and can help value your portfolio based on client mandates and CSA terms, by assigning valuation methodologies to each fund and counterparty.
For more information about our solutions, please contact Maxime Jeanniard du Dot at max@opengamma.com.
The post CSA Changes: Do You Really Understand the Impact? appeared first on OpenGamma.
]]>The post Gain visibility to verify your Initial Margin requirement appeared first on OpenGamma.
]]>In the context of corporate governance and fiduciary responsibility, treasury managers feel obligated to have robust control around independent verification of the Initial Margin (IM) call on their cleared OTC derivatives portfolio, as they bear potential credit risk to their clearing brokers.
We have been working with a UK retail bank to provide this increasingly critical function. Its team is now in production using OpenGamma’s margin calculation capabilities within our partner CloudMargin’s collateral management workflow solution. Best of all, the client was able to access this new functionality through a simple configuration option in CloudMargin, rather than the often onerous task of new software deployment or updates.
With full visibility into the Initial Margin requirements on their OTC derivatives portfolio, the bank is now able to validate every Clearing Broker IM call against the actual Clearing House IM requirement – ensuring that costs resulting from clearing mandates are precisely understood.
Using the cloud-based solution offered by OpenGamma and CloudMargin, we have helped this bank increase control and transparency, meaning they never have to blindly agree on a margin call again.
To find out more about how we can help you analyse and assess your margin requirements, please contact us for a demo.
The post Gain visibility to verify your Initial Margin requirement appeared first on OpenGamma.
]]>The post The upcoming threat to the buy-side of CSA repapering appeared first on OpenGamma.
]]>Some dealers switched to discounting using the interest rate paid on the assets collateralising the trades. By using their more advanced multi-curve valuation models, they could more accurately price trades enabling them to identify opportunities to rebalance their exposures.
Why is this history relevant right now? With the VM regulation deadline of March 2017 looming, the OTC derivative market is about to go through a widespread CSA repapering process. Some estimates suggest that around 200,000 CSAs will need to be amended in order to comply with the bilateral margin rules set by BCBS/IOSCO, with many individual buy-side firms having many 100’s of CSAs in place.
Amending CSA terms on an existing agreement can have a significant impact on the value of a portfolio (just as voluntary clearing at a clearing house would do). Consequently, this triggers the need to agree on a potential payment between the dealer and client or vice versa for every individual CSA.
This all comes at a time when dealers are facing pressure on their ROEs due to regulatory changes such as leverage ratio and NSFR. They are increasingly keen for the buy-side to exchange cash collateral in the currency of the underlying exposures, on a daily basis. A key driver for the dealers is that only daily-exchanged cash-settled VM can provide them with capital relief.
On the other hand, many funds would like to keep their ability to post other assets. Pension funds, for instance, tend to be fully allocated and do not hold cash reserves within their funds. Contraction of repo liquidity (also impacted by regulation) has closed down the ability for buy-side firms to raise cash using the securities held in their funds. Many buy-side firms are worried that moving to single-currency cash CSAs might not be such a good idea. They are now faced with having to make some key strategic decisions with regards to the potential asset-allocation implications of needing to hold more cash in their funds to meet margin requirements in periods of market stress.
Many buy-side firms will be entering these discussions with their dealers without the ability to independently price the impact of the CSA changes on their book. It is therefore impossible to know the value of the CSA optionality that they may be giving up.
OpenGamma’s award-winning derivatives analytics are currently being used by our buy-side customers to allow them to independently price their derivative positions, for example using different CSA assumptions. We are seeing an increased level of interest in our solutions as firms prepare for their upcoming negotiations.
For more information about our solutions, please contact Maxime Jeanniard du Dot at max@opengamma.com.
The post The upcoming threat to the buy-side of CSA repapering appeared first on OpenGamma.
]]>The post Strata Wins Big at JavaOne 2016 appeared first on OpenGamma.
]]>
Award presented by Georges Saab, Vice President, Software Development, Java Platform Group at Oracle (Centre) and Sharat Chander, Director, Java Product Management & Developer Relations (Left)
It was great to be back at JavaOne after a three year gap, with the award as a real bonus. I also gave a talk on code generating mutable and immutable beans, with slides available. There was lots of talk about Java 9, modularity and future changes to the language for local variable type inference and data classes (potentially removing the need for code generators).
Now I’m back in the UK, it is time to finish up the loose ends and release v1.1 of Strata, with lots of enhancements. That way we can keep the award-winning momentum going for everyone who needs a transparent, high quality, easy-to-use library for valuation and market risk.
The post Strata Wins Big at JavaOne 2016 appeared first on OpenGamma.
]]>The post EMIR category 2 – OpenGamma provides analysis for optimal margin outcome appeared first on OpenGamma.
]]>Some of your clients may be firms unprepared for the EMIR Category 2 clearing deadline (coming into full effect on 21st December 2016) and will presumably have an urgent short-term need.
These firms will need to understand their margin requirement by 21st December, and ideally they will want to ‘cherry-pick’ trades for voluntary clearing from their pre-existing bilateral back-book for an optimal margin outcome.
The challenge will be in performing the necessary analysis in a timely and cost-efficient manner, given the fast approaching deadline and differing portfolio data formats. While you will have access to the cleared portion of the client’s portfolio in the clearing house format, it is expected that the bilateral back-book will only be available in the client’s own internal formats.
This implies significant manual effort to first map,run and then present the analysis in the format the client expects.
OpenGamma has built an analytical service specifically to help buyside firms assess the margin impact of EMIR Category 2. We can turn around margin analysis on a client portfolio typically in less than 24 hours, including mapping their custom portfolio formats. This will ensure that your client gets the value-add analysis that will differentiate the service you offer in comparison to other clearing brokers.
For more information or a demo please contact:
Alp Oergen
Email: alp@opengamma.com
Direct: +44 20 3725 3384 | Mobile: +44 7532 142 410
The post EMIR category 2 – OpenGamma provides analysis for optimal margin outcome appeared first on OpenGamma.
]]>The post OpenGamma and SIMM provide value to market participants appeared first on OpenGamma.
]]>If all financial institutions were using their own internal methodology for margin calculation, it would rapidly become a major problem as each firm would need to replicate all of their counterparties’ methodologies to validate margin calls. To reduce potential dispute issues arising from this situation, ISDA proposed SIMM™ (Standard Initial Margin Methodology) that could be used by all financial institutions impacted by the regulation. The methodology itself was developed by the ISDA WGMR and based on the standard Sensitivity Based Approach of the BCBS “Standards: Minimum capital requirements for market risk” (previously known as FRTB) .
Over the past few years, OpenGamma has been working with market participants on the calculation of Initial Margin requirements. Extending our offering to the bilateral space by implementing SIMM made a lot of sense. Since the publication of the first documents by ISDA, we have been keeping up-to-date with the changes to the methodology as it was being refined by the industry and have performed analysis on the impact for financial institutions .
In this blog, I would like to describe some of the SIMM-related initiatives OpenGamma have been involved in recently.
The library we have developed to implement SIMM is very lightweight (code is less than 300KB). It was designed to be integrated in other systems and with other libraries. For the projects below, we associated it with our open-source risk management library, Strata, for the computation of sensitivities.
We pride ourselves in our technology and derivatives expertise, and have been using both our open-source analytics (for the calculation of sensitivities) and SIMM implementation to deliver value to a variety of market participants:
I will be speaking about these initiatives and SIMM at the ISDA Annual Conference on September, 20th. Please come by and say hello during the lunch break.
For further information, please contact me (marc@opengamma.com).
Our open-source library, Strata, can be found here .
The post OpenGamma and SIMM provide value to market participants appeared first on OpenGamma.
]]>The post Strata – The open source library for market risk analytics appeared first on OpenGamma.
]]>Taking two years to develop, Strata provides a stable, lightweight and easy-to-use library for market risk, written entirely in Java. It has been developed to provide all the foundations necessary to build or enhance applications with standardised, off-the-shelf market risk functionality. Simply load your market data and portfolio, perhaps via the built in FpML/CSV support, and easily access high quality analytic measures such as present value, PV01 and greeks. Behind the scenes, Strata uses Adjoint Algorithmic Differentiation for the fastest and most efficient sensitivity calculations.
A big focus has been on making the library lightweight and easy-to-use. It is available in Maven Central, making it simple to get started, with external dependencies kept to a minimum. It does not impose any database, server or middleware requirements, and is designed to be used both in its entirety, as well as for its individual components. As a foundational library, it contains all the financial concepts necessary for pricing and risk, including indices, holidays, trade representations, market data structures, curve calibration in the multi-curve framework, and scenario evaluation.
Strata currently provides analytics for Interest Rate Swap, FRA, Swaption, CMS, Cap/Floor, DSF, STIR future/option, FX forward, FX NDF, FX swap, FX vanilla/barrier option, Bonds, Bond future/option, CDS and Term Deposit. See the product coveragedocumentation for more details.
Strata is released as open source software under the Apache v2 license and is available on GitHub. OpenGamma provides commercial support, warranty, indemnification and input to the roadmap. Commercial extensions include integration with Microsoft Excel and CCP margin calculations.
So, if you are a Java developer working for a hedge fund or bank looking for an easy-to-use library for valuation and risk calculations, and you want to work with a high quality codebase with full transparency and control over every aspect of the deployment, we think Strata could be just what you are looking for.
The post Strata – The open source library for market risk analytics appeared first on OpenGamma.
]]>The post Comparing SIMM vs. CCP margin delivers unexpected results appeared first on OpenGamma.
]]>The mandatory clearing for vanilla derivatives and the mandatory bilateral margin for all derivatives are part of the same regulatory push to try to overcome some of the banking system’s weaknesses evidenced by the crisis which started in 2007. The mandatory clearing is already effective in the US and was effective in Europe for some users a couple of days ago on 21 June 2016.
The mandatory clearing and bilateral margins are two faces of the same framework, so it makes sense to compare them. Moreover, in their supplementary information on the bilateral margin, the US regulator indicated that such a comparison is appropriate. More exactly in the document “Margin and Capital Requirements for Covered Swap Entities,” the US agencies indicate (on page 138) that:
“In light of the clear competitive forces that will exist between cleared and non-cleared swaps, the Agencies believe that it is appropriate to compare the initial margin requirements of non-cleared swaps to those of similar cleared swaps.”
At OpenGamma, we are ideally positioned to do this comparison. Our solutions allow us to compute Initial Margin (IM) for numerous CCP and bilateral methodologies, including ISDA SIMM (“SIMM”), of which we are an official licensee, using our award winning Margin calculation solution.
In this blog, I report some comparisons for single swap portfolios. I take this approach as it helps to identify features of the SIMM model that are not obvious when SIMM is discussed in the context of larger portfolios.
Comparing the current IM for simple portfolios should only be one step that any financial institution takes in deciding its strategy around derivatives. Many other factors should be taken into account, like the cost of becoming a member of a CCP or a clearing client, the netting effect of central clearing, the type of collateral accepted, the margining transparency, the liquidity difference between bilateral and cleared trades, etc.
By doing this comparison we found that the relation between cleared and bilateral margins is a lot more complex than the often mentioned ‘square root of 2’ ratio, which comes from the ratio between the margin period of risk (MPR) of 10 days for bilateral margins and 5 days for central clearing. We investigated the impact of currency, tenor and notional in order to highlight these complexities.
The first set of comparisons are related to a single swap. We compared different CCPs to SIMM:
The results for EUR are displayed in Figure 1. The SIMM IM numbers are above the CCP numbers even if only slightly above. The minimum requirement for bilateral margins are a Margin Period of Risk (MPR) of 10 days and a 99% VaR. For CCPs, the MPR for swaps is 5 days, but the CCPs use different methodologies, like Expected Shortfall 99.75% with 10 years of historical data, VaR at 99% with 3 years historical data and stress period, or VaR at 99.7% with more than 5 years of historical data. In each of the cases the CCPs use add-ons on top of the base IM. Depending on the historical data and the add-ons, there is not a clear order between SIMM and CCPs even if SIMM tends to be above CCP figures. The relation between SIMM and CCPs also change through time.
Figure 1: Comparison of IM between two CCP and SIMM for EUR IRS and OIS with different tenors.
The results for USD are displayed in Figure 2. In general, the SIMM IM numbers are above or in line with the CCP numbers. The results are not as clear as in the EUR case. The reason for this is probably due to the SIMM methodology. In SIMM, the same risk weights multiplier to basis point sensitivities are used for all main currencies. The EUR rates are lower and thus the sensitivity for one basis point are higher for the same notional. This explains why the SIMM numbers for USD are below the numbers for EUR.
Also note that for long-term swaps, the schedule based approach provides numbers below both SIMM or CCPs. However, this is largely irrelevant for larger banks; using the schedule has been ruled out for their interbank exposure as it does not offer any netting benefits between trades.
Figure 2: Comparison of IM between some CCPs and SIMM for USD IRS and OIS with different tenors.
In the second set of comparisons, we look at 10Y swaps with different fixed rates. The results are displayed in Figure 3. The ATM swaps have a PV and thus a currency exposure of 0. Due to the different way the CCPs treat currency exposure, the profiles, which represent swaps with non-zero currency exposure, can be quite different. For SIMM, the profile depends on the base currency; here we have selected EUR. The currency risk is taken into account for the IM computation. Here we selected JPY for the swap because it is not the base currency for any of the IM methodologies analysed.
Figure 3: Comparison of IM between some CCPs and SIMM for JPY IRS and OIS with different fixed rates.
In general, the IM for JPY swap is lower than the one for USD and EUR. This is due to lower volatility for JPY historical data used by CCPs and is recognised by SIMM which has a special low risk weight for JPY. The interesting feature of that graph is the shape of the profiles. The ‘blue’ CCP does not include the currency exposure of the trade in the IM computation; the IM graph is roughly shaped like a line. The graph for SIMM looks more like a ‘smile’. This is due to the interaction/correlation between the interest risk and the currency risk. As the ‘green’ CCP and our SIMM implementation have base currencies different from the CCP base currency and take the currency exposure into account, the graph shapes are different, but both of them are convex curves and not lines.
In the last comparison for this blog, we take a 10Y ATM swap in USD and check the IM for different notionals. As a first approximation, we can think that the IM is linear in the notional and this comparison does not bring more information than the one presented in the first test. But all CCP methodologies have some kind of add-on which are not linear in the size; the IM increases faster than the notional. This is particularly true for the ‘liquidity add-ons’. It is interesting to check from which size the CCPs are becoming more expensive in terms of margin than a bilateral IM. Note that SIMM has some provision for a “concentration risk” (CR) which would make SIMM also not linear in the size, but for the moment the CR threshold is undefined and the method is still linear in the size. The results are presented in Figure 4.
Figure 4: Comparison of IM between some CCPs and SIMM for USD IRS and OIS with different notionals.
Figure 4 presents the results with a log-scale for the notional and a linear scale for the ratio between CCP and SIMM. For all CCPs, above a certain notional, the IM is larger than SIMM. For this example with only one 10Y USD swap, the notional where the non-linearity kicks in is around 10 billions. The ratio can be above 2 for large amounts. For more complex portfolios, especially when the overall risk is small and there are large offsets between different maturities, the ratio can be even larger.
The comparison between CCP’s IM and bilateral IM (represented here by SIMM) for swaps is not a straightforward task. Even for a single swap, there is a diversity of results depending on side, currency, rate, notional and the date the analysis is run. In most cases, SIMM is above CCP figures, but this is not always the case. Portfolio effects and add-on bring even more complexity to the process, but this will be the subject of another blog.
The detailed analysis of these issues requires not only the tool to run the computation for the different CCPs and bilateral margining in parallel but also a continuous monitoring of the data used.
Please contact us for more details on the results presented in this study or information on our margin calculation offering, which was used for this study and is used by market participants to perform similar analyses.
The post Comparing SIMM vs. CCP margin delivers unexpected results appeared first on OpenGamma.
]]>