Historical VAR Calculation for Derivatives Portfolio (Excel-based)
To illustrate the ease with which Zircon software technology can be integrated into existing applications, we chose to demonstrate a zEnabled Microsoft Excel-based calculation of the historical Value-at-Risk for a large portfolio of American-type options on multiple underlying securities. This particular test also showcases the innovative zCashe technology that generically solves the problem of sharing data among multiple parallel computations.
The setup: familiar to any risk manager
We begin with a portfolio containing derivatives on 31 underlyings (DJ30 and all constituents) as well as positions in the underlying securities themselves. In this particular case, we use a snapshot of market prices from 10 AM on October 2, 2006. The options in the portfolio have maturities between October and the following January and are in the [93, 107] moneyness range for individual options and in the [98, 102] moneyness range for index options.
In total, 381 options, 30 stocks, and 1 index tracking fund (DIAMONDS Trust, Series I) qualify for our portfolio. The portfolio weights are allocated randomly from both the positive and negative domains, so that both long and short positions are possible for all instruments. A sample of the portfolio composition is shown in the table below.
To begin, we collect the history of daily stock returns for 2 years preceding the VAR estimation date in an Excel spreadsheet dedicated to historical simulations. Then, we create 1000 distinct scenarios by randomly drawing 1000 sets of returns (for all 30 stocks from one day to get a real correlation structure) and calculating the underlyings' prices for 1 day. These preliminary operations are carried out in Excel as they are relatively lightweight. Next, we make a set of zFunction invocations and engage the zNet to handle the bulk of the computational load of this test.
After each zFunction, running in parallel with other zFunctions on the distributed zEngines, calculates the value of a given portfolio for a given scenario, it returns this value to the Excel spreadsheet and enters it in the cell that made the invocation. The values are collected in this way as the zFunctions complete, and when all the data is available, we proceed with the normal procedure for the VAR calculation. Excel sorts the simulated portfolio values and retrieves the VAR with a specified confidence level. In this way, Zircon software can boost a typical user application that is widely found throughout the finance industry.
zCashe and Excel-Zircon Software integration
An important feature of this test is the need for multiple parallel computations to share data, a situation that is expected to arise frequently in many cases where non-parallel code (that often relies on data normally available to it in a single process) is rapidly separated out into a module to be managed by Zircon software. The packaged zCashe technology allows us to share data between the zEngines in an optimized manner, without wastefully duplicating the shared data with each remote request. Thus, in the Excel-Zircon software link, information from Excel spreadsheet cells can be seamlessly propagated to be used in the remote computations that need them, with the zCashe feature organizing the actual sharing of this information as it is demanded by the zEngines and requiring no additional work on the user's part.
We can accelerate the computations in this test by parallelizing them in two dimensions: we can estimate the portfolio value for multiple scenarios in parallel, and we can also split the portfolio value computation itself into a set of independent tasks. The decision concerning how thoroughly we should exploit the concurrency latent in the algorithms we use depends largely on the relationship between the execution times of the lowest-level indivisible code blocks and those directly composed of the lowest-level blocks. In our case, parallelization on a finer scale makes little sense because the test requires computing 1000 scenarios, each with 400 instruments, while using only a handful of processors. Going beyond distributing the scenarios among parallel processors to further parallelize the calculations for each instrument within a scenario would gain us little in terms of performance.
On the other hand, there are certainly realistic applications that would benefit from several levels of parallelization, and Zircon software supports this in the form of zFunction clustering. In this idiom, a zFunction running on multiple zEngines can itself serve as a Zircon software client, with each instance of the zFunction making a number of parallel requests that are handled in parallel by the same zNet®. While applications for more than two levels of clustering are probably exotic, the Zircon software architecture supports this fully.
