ImpliedVolatilityGrid: Grid Based Integration to Provide On Demand
Financial Risk Analyisis
Brian Conlon, Jonny Press,
Felix Lungu
Gordon Macleod, Paul Donachy,
Terence J. Harmer, Ron H.
Perrott
Belfast e-Science Centre,
Queen’s University of Belfast
{g.macleod,p.donachy,
t.harmer,r.perrott}@qub.ac.uk
Abstract
Implied volatility is a calculation used within the financial
sector. It is highly computationally expensive both in
terms of calculations and required data. This paper
discusses the grid enabled proof of concept Implied
Volatility Grid project. An overview of the architecture
will be presented; Sun Grid Engine, JGrid and the Globus
Toolkit (version 3) combine to form the backbone of the
system.
In addition, this paper will detail the
performance gains from grid enabling the implied
volatility calculation. It shall conclude by discussing the
future direction of the grid application, in particular the
transformation from Globus Toolkit version 3 to version
4.
1.
Introduction
Within the stock market, stock and stock options can be
purchased. Stock signifies an ownership position within a
corporation. Options represent an option to buy or sell a
set amount of stock from/to a third party at a set price in
the future. An option is purchased from a third party and
if it is profitable on the maturity date (for example, the
strike price of a call option is less than the current value
of the stock, allowing the holder of the option to buy the
stock more cheaply than would otherwise be possible) it
will be exercised – otherwise it will be left to expire.
When the stock market is open, stock and option prices
are constantly being updated. Stock options are normally
priced using the Black Scholes [1] model. This equation
contains a volatility parameter which cannot be observed
in practice. There is a one-to-one relationship between
the theoretical price of a stock option and its volatility.
Unfortunately there is no closed form solution for
implying the volatility from the stock option price. If the
volatility is known, trades can be executed to take
advantage of volatility spikes. The implied volatility
First Derivatives plc,
{bconlon, jpress,
flungu}@firstderivatives.com
must be calculated using a numerical method; a NewtonRaphson [2] iterative process is normally used, which is
computationally expensive.
Figure 1. The implied volatility formula
The financial sector currently depends heavily on such
calculation and data intensive computations to deliver
competitive advantage.
The calculation of implied
volatility is an example of this, as are risk management
calculations (analysing the risk of a portfolio of stocks,
bonds). Such applications command high peak data rates
for fast access to market data sources and high availability
is essential for trading and pricing. Non-availability
means absence from the market. The quantity of
available market data is vast and response times are
required to be as fast as possible as time is critical in
financial applications. At present such tasks are largely
performed onsite within a closed network.
ImpliedVolatilityGrid is a proof of concept project,
developed at the Belfast e-Science Centre, Queen’s
University Belfast, in conjunction with First Derivatives,
a recognised service provider in the capital markets
technology sector, who are based in Newry, Northern
Ireland.
The project focuses on grid enabling a
calculation used in the financial sector, namely implied
volatility. Implied volatility is an extremely apt grid
example as it captures the computationally and data
intensive (but inherently parallelisable) nature of many
financial calculations.
2.
ImpliedVolatilityGrid Architecture
ImpliedVolatilityGrid is a three-tier architecture with five
of the main components being found in the grid
middleware and cluster tiers. These five components,
namely IVGrid Service, IVGrid RMI Server, IV
Implementation, JGrid RMI Server and the Sun Grid
Engine Node will be discussed individually in more detail
below.
2.1
IVGrid Service
The ImpliedVolatiltyGrid service is deployed in Globus
(version 3). This accepts the HTTP service calls from the
client and passes these onto the IVGrid implementation,
via the IV RMI server, as a KJob. The KJob contains the
options configured by the client for the job and also status
information that is sent back from the IV implementation.
Initially, this status information contains the start time of
the entire job.
2.3
IV Implementation
The ImpliedVolatilityGrid implementation primarily
consists of a KJob class. When the IVGrid RMI server is
requested by the service to process the job, firstly the data
for the tasks is retrieved from the Kdb [3] database, using
the K java based interface. According to the number of
tasks to be run, the data is split evenly among these tasks,
which are then created with the data retrieved. Each task
is then added to the pool of tasks for that job.
When the job is run, a thread for each task in the pool, in
the Kjob instance, is created in succession. The task
thread then connects to the JGrid RMI server and submits
the task to be run to the JGrid implementation and hence
the grid itself. The JGrid RMI server is polled every
500ms, in the thread, to check the status of the task. Once
the status of the task is complete, the results of the task
are retrieved via a K_IO object and the status (JobStatus
instance) of the KJob is updated accordingly, notifying
completion of a task for that job.
2.4
JGrid RMI Server
The JGrid component allows jobs to be submitted to Sun
Grid Engine via native Java calls. It enables live Java
objects to be submitted to the grid and live objects to be
received in response. JGrid has 3 main components:
Figure 2. ImpliedVolatilityGrid Architecture
2.2
IVGrid RMI Server
The IVGrid RMI Server accepts ImpliedVolatility calls
from the service and allows the service to query the status
of running jobs for notification to the client. The IVGrid
RMI server consists of a ComputeInterface interface and a
ComputeImpl class. When the service has been run, it
makes the connection to the IVGrid RMI server and
passes the Kjob it created. It then calls methods on the
remote interface (ComputeInterface) to initiate the
creation of the tasks, start the job as a separate thread, and
subsequently retrieve the status of the job and its
associated tasks. Once all tasks are complete, the service
retrieves the completed KJob.
•
The Java Compute Server, that uses smart RMI
proxies to intercept RMI calls, in this case from
the ImpliedVolatility implementation, and feed
them through the grid.
•
The Native Peer, a native binary (in C) that
connects to the agent and requests the
ImpliedVolatility task (a Ktasklet instance) to be
run.
•
The Agent, a Java server that runs on each
execution host (grid node). The Native Peer
contacts the agent via a custom protocol (JCEP:
Java Compute Engine Protocol) and sends the
task request. The agent then executes the
requested task and returns the results to the
server via RMI. The server can then return those
results to the client (the ImpliedVolatility
implementation).
Whenever the task has finished completion on the node,
the results are serialised and sent back to the JGrid RMI
server.
2.5
Sun Grid Engine Node
Once the ImpliedVolatility task (KTasklet object) has
been sent to the grid node for execution, it is executed via
the compute method implemented from the JGrid
interface. The JGrid component specifically looks for this
method in the object it has been passed and initiates
execution in this way. The KTasklet then connects to the
locally installed K daemon (using the GetKInstance class)
via a specified port number and using the Java-based
interface to K, sends it the command and data to execute.
If the K daemon is already running, an attempt is made to
connect to the existing instance. Once the K daemon is
finished executing, the results are returned to the
KTasklet instance and hence back to the JGrid RMI
server for notification to the ImpliedVolatility service and
finally the client.
3.
will be achieved through the use of Globus Toolkit
version 4.
An “intelligent” middleware will be created that will
include several components (see Figure 4). A registry
will allow for services and resources to be managed,
monitored and discovered, with support for Multi-Cluster
Grids. The ability to provide replication of the registry
and grid services will provide a more robust middleware.
Administration of middleware components will be
facilitated through the utilisation of a grid portal. This
will also serve as a central access point for all users of the
application.
Results
Preliminary results gathered from running the
ImpliedVolatilityGrid application can be viewed in
Figure 3. The results found are unsurprising, due to the
inherently parallelisable nature of the calculation used.
Figure 4. Revised ImpliedVolatilityGrid
Architecture
4.2
Figure 3. Running times for various node
configurations
More in depth results will be readily available at the All
Hands 2005 conference.
4.
Future Direction
4.1
Framework Enhancements
Although ImpliedVolatilityGrid focuses specifically on
implied volatility calculations, it is a vision for the future
that many types of different services will be provided.
Initially the focus will be on implied volatility
calculations, data feeds (for example, from Reuters,
Bloomberg) and data storage. It will be possible to add
new services, providing access to different kinds of
financial calculations.
It is planned to migrate from OGSA to WSRF based grid
services. The current implementation has been achieved
using Globus Toolkit version 3.0.2. WSRF compliance
Business Uses
ImpliedVolatilityGrid has great potential within the
financial sector. While it was designed and developed as
a proof-of-concept project, future enhancements will
enable it to evolve into a marketable real world business
solution.
Within merchant banks, traders, analysts and risk
managers are a few of the people who could make use of
an Implied Volatility service. The service could be
supplied in a variety of formats:
1.
2.
3.
The service has access to market data (which can
itself be exposed as a service). This could be
supplied from a provider such as Reuters or
Bloomberg. As the market data changes the
service sends updates to the client, providing
real-time implied volatilities.
The service accepts stock and option data from
the client. It calculates the implied volatilities
and returns the results to the client.
The service has access to its own market data. It
accepts queries from clients in the form of an
option ticker. The service itself would most
likely maintain the implied volatilities as up-todate as possible, so this would merely be a
database lookup. The client supplies a query; the
service does a lookup and returns the implied
volatility.
As a marketable service, the first service would probably
be the most likely due to the reduced latency. Merchant
banks already receive observable market data from
external feeds, so calculated data is a possibility.
There is also the issue of how the users of a service will
pay for its use. In the case of the first option, a
subscription service may be viable. The subscription
would either cover a certain time period or the number of
times the service could be accessed (before requiring a
new subscription). With regards to services 2 and 3, a
pay per use system would be more appropriate.
4.3
Use Cases
Several use cases have been identified as a starting point
to the refinement of the application. The use cases
outlined below have been written at a high level so as not
to refer to any particular finance grid service.
4.3.1 Publish Service
A financial service wishes to expose itself to potential
customers by being published in a registry. The registry
publishes the service based on service descriptors
provided by an administrator. Potential descriptors will
vary depending upon the services to be contained within
the registry.
4.3.2 Discover Service
A client wishes to locate a financial service that has been
published within the registry. The invoker provides
parameters in order to determine the type of service it
wishes to discover. The Registry performs a lookup on
services based on parameters and returns a list of
matching services to client.
4.3.3 Subscribe to Service
Invoker contacts the registry, providing usage and/or
subscription type. The registry contacts the authentication
resource to determine if the invoker should be allowed to
access the requested service. A payment resource service
is contacted in order to process usage/subscription charge.
The registry contacts a subscription resource in order to
register invoker’s interest in the service. Finally, service
connection details are sent to the invoker.
4.3.4 Invoke Service
A client wishes to invoke a service and retrieve an output
from the service. The invoker passes any required
parameters. The service validates any inputs, processes
the job and returns results to the invoker.
4.3.5 Registry Service Check
The registry has to maintain connections to all the
services which have registered. Each service is ‘pinged’,
to determine whether it is still ‘alive’. If a service does not
respond then its details can be removed from the registry.
4.3.6 Registry Backup
A replicated registry needs to subscribe to the main
registry in order to maintain an up-to-date set of service
data. It should then maintain a connection to the registry.
5.
Conclusions
The ImpliedVolatilityGrid proof of concept project has
successfully demonstrated the appropriateness of utilising
a grid infrastructure within the financial sector in order to
process computationally and data intensive calculations.
Results observed through this project are encouraging.
The
planned
future
enhancements
to
ImpliedVolatilityGrid will serve to further justify the
appropriateness of the grid in the financial sector.
References
[1] Black, Fischer and Myron S. Scholes (1973), “The pricing
of options and corporate liabilities”, Journal of Political
Economy, 81 (3), 637-654.
[2] Eric W. Weisstein. "Newton's Method." From MathWorld-A Wolfram Web Resource.
http://mathworld.wolfram.com/NewtonsMethod.html
[3] http://www.kx.com