\documentstyle[art10,epsf,npac_proto,palatino]{article}
\newcommand{\postscript}[2]
 {\setlength{\epsfxsize}{#2\hsize}
  \centerline{\epsfbox{#1}}}
\begin{document}
%\makeNPACtitle\newpage
\begin{project}
\begin{titlepage}
	\projtitle{Maui}
	\doctitle{
         Technical Specification
              of the \\
         Prototype Parallel Server\\
               for\\
      Valuation of Derivative Financial Instruments \\
                 }
		\author{Miloje S. Makivic}
		\date{April 6, 1996}
		\version{0.3}
		\summary{Third draft, exotic, American, term structure }
	\id{Maui}
	\docauthor{M~S~Makivic}
	\security{Commercial in Confidence}
\maketitle
%\approval{G. C. Fox, G. Woodcock}
\vfill
	\begin{history}
		\release{
			\author{Miloje S. Makivic}
			\date{April 2, 1996}
			\version{0.1}
			\summary{Initial draft}
			}
                \release{
                        \author{Miloje S. Makivic}
                        \date{April 6, 1996}
                        \version{0.2}
                        \summary{Second draft}
                        }


	\end{history}
\end{titlepage}

\pagenumbering{roman}\setcounter{page}{1}
\begin{abstract}

This document contains the technical and functional specification of the 
prototype software system for delivery of on-line real-time valuation of
derivative instruments using massively parallel supercomputers and computer
networks.
The document also 
supplies an estimate of resources required
for timely delivery of the prototype and outlines a set of milestones
for progress monitoring.
{\bf Keywords:} Parallel computing, distributed computing,
Monte Carlo simulations, hedging, options, risk management, 
time series analysis,
network-centric computing.

\end{abstract}

{\parskip=0pt   % hack to patch format of \tableofcontents
\tableofcontents
%\newpage
\medskip\hspace{2.0cm}\hrulefill\hspace{2.0cm}\bigskip
}

\pagenumbering{arabic}\setcounter{page}{1}

%=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
\section{Introduction}
High-performance computing and communications, and, in  particular,
cooperative, distributed and parallel
computing, will play an increasingly important role in trading, financial
engineering, and all aspects of investment and commercial banking, 
due to a convergence of the following factors:
\begin{itemize}

\item Increased volatility due to globalization of financial markets
\item Global distribution of data sources
\item Increase in complexity of derivatives and other risk management vehicles
\item Increased demand for real-time investment and asset allocation 
      decision support
\item Increased volume of raw data and need to process large databases
\item Increased volume on the retail side of the spectrum mainly 
      due to on-line technologies (Internet and WWW)

\end{itemize}

High-performance computing technologies are becoming 
indispensable in the application
domains such as:
\begin{itemize}
   \item Derivative valuation, particularly over-the-counter products
   \item Portfolio optimization and asset allocation
   \item Hedging of portfolios in real time
   \item Arbitrage trading
   \item Risk analysis simulations
\end{itemize}
Traditionally, these applications supported the wholesale end of the
financial services spectrum and the supply side.
An enormous new opportunity domain for HPCC is being created by the
emergence of global computer networks as the new delivery channel and
economic force.
For example, the Internet is already creating 
a shift among financial services providers
towards the retail end of the spectrum. At the same time, there is
increased demand on the buy side, particularly among corporate
treasurers, for more structured and more complex
financial instruments to manage risk with more flexibility.
The demand is going to grow with the trend towards globalization, which
wiil be reflected in increased short term volatility and risk exposure
for {\em all} market participants.
Investors at all levels of endowment are becoming more self-reliant 
for investment decisions and
more comfortable with technology. This trend will be
reinforced by the wealth of information offered on the public as well as
value-added networks.
Finally, there is increased pressure from regulators to enact sophisticated
risk management strategies for institutional investors, given the well
publicized events such as Orange County fiasco and Barings Bank.
These factors will contribute to the increased demand for on-line
services in two areas:
\begin{itemize}
\item Resources for risk management support
\item Resources for investment decision support
\end{itemize}
These trends will lead to pervasive deployment of {\em scalable} 
high performance architectures to support market demands.

Given these developments, it seems natural to build
a one-stop full-service Quantitative Analysis Resource Center (QUARC).
The most valuable component of this service would be
sophisticated quantitative
analysis capability, implemented on a massively parallel machine, and
delivered to clients anytime, anywhere, on any computer platform using
stat-of-the-art network technology. At present, 
all but the largest market participants are forced to use
simple techniques for quantitative analysis, because of
prohibitively expensive software and hardware. In addition to
cost, investors must learn how to install, use and maintain
proprietary software and frequently must purchase different software
for different
investment or risk management tasks.

As a first step to a comprehensive QUARC, we will develop an on-line
option pricing service. At the core of the service will be a 
Monte Carlo simulation algorithm. The algorithm is among the most flexible
in existence today and is capable of pricing any kind
of option. The algorithm has a unique feature that it can compute
{\em all} the parameter sensitivities of an option price in a single
simulation without resorting to numerical differentiation. Accurate
determination of price sensitivities is a must for any practical
trading or hedging strategy. The algorithm
can also accept any kind of stochastic process for the underlying
assets. Furthermore, option values and sensitivities can be computed
for multiple values of parameters in a single simulation, which is a feature
that no other method can replicate. This is extremely useful for
risk managment purposes where multiple scenarios may be superimposed
on top of option valuation to establish best/worst case exposures and
other risk assesment tasks  mandated by internal policies or regulators.
The algorithm is also a valuable tool for sell side firms where it can
be used as a flexible engine for valuation of exotic one-of-a-kind
derivative instruments. From implementation point of view, the algorithm
scales efficiently even on massively parallel processors, so it can
take full advantage of the processing power of the machine.

\section{Functional Specification}

Development of a comprehensive derivative valuation service is a challenging
task. We are constrained by the following parameters: 
the horizon for the development of the prototype is set to eight
months and the human resources are assumed to consist of four full time
experienced developers. However, we know from
communications with Quantitative
Analysis managers on Wall Street that development of a full fledged
interest rate derivative system typically requires about {\em 100 man-years}.
Major costs arise from the need to develop the term structure models (i.e. models
of temoral dynamics of forward interest rates of all maturities) which provide
inputs for valuation software.
The focus of the prototype is to demonstrate the capabilities of the
valuation engine.
For this reason, we have decided to include only a single example of interest 
rate derivatives, which is most likely going to be a bond option.
We will implement a basic term structure model to be able to price the bond 
option. 
A sophisticated term structure model must be built for the
commercial product though.
The prototype will include options on equities, indices and futures, as well as
exotic options with path-dependent payoffs and many-dimensional underlying instruments, 
where the advantages of the algorithm
and the parallel implementation will be apparent.

The prototype will be able to price:
\begin{itemize}
\item Options on common stock (American)
\item Equity index options  (specifically S\&P 500 and S\& P 100)
\item Options on financial and commodity futures
\item A small set of exotic options (Asian with fixed and floating strike, 
      look-backs, range options)
\item Bond options (American and European)
\end{itemize}
This selection covers mostly those classes of options which are not dependant on the
term structure of interest rates and the bond options, which are term structure
derivatives.

The prototype will be able to compute the following derivative price sensitivities:
\begin{itemize}
\item Delta (sensitivity to changes in the underlying price)
\item Vega (sensitivity to changes in the underlying volatility)
\item Rho (sensitivity to changes in the money market rate)
\item Theta (sensitivity to the passage of time)
\item Phi (sensitivity to the dividend yield for stock options)
\item All additional parameters for exotic option payoffs
\end{itemize}
This selection demonstrates that the system provides complete information about an option
without resorting to numerical differencing which entails errors and requires at least one 
extra simulation for each sensitivity if conventional algorithms are used.
For some of the exotic options, numerical differentiaition is unstable because the
greeks blow-up. Our method does not suffer from any numerical instabilities.

The prototype will implement the following stochastic processes for the underlying:
\begin{itemize}
\item Gaussian
\item Cauchy
\item Poisson jump
\item Gaussian and Poisson jump combined 
\item Cauchy and Poisson jump combined 
\item Histogram of historical returns
\end{itemize}
These choices are sufficient to show that the algorithm can accept virtually any
model for the underlying dynamics.

The prototype will be able to perform statistical analysis of historical data:
\begin{itemize}
\item Histograms
\item Correlations
\item Calculation of moments
\item Moment substitution estimation
\item Weighted historical volatility estimation
\item Robust statistics 
\end{itemize}
The goal is to provide minimal statistical tools necessary for analysis of many-dimensional
stochastic processes and support for option pricing. The capabilities of this module must be
significantly enhanced for the commercial product.

The prototype will be able to compute implied volatility using the Black-Scholes model
and current market prices. The clients will be able to mix historical and implied
volatility to obtain estimates of future volatility. They will also be able to experiment
with volatility in a much more sophisticated fashion, since, in addition to the
constant historical, implied or mixed volatility estimate, the prototype will implement 
the following possibilities for volatility dynamics assuming
Gaussian and Cauchy processes:
\begin{itemize}
\item geometric random walk stochastic volatility
\item deterministic time dependent volatility scenarios
\item deterministic volatility defined as a function of the underlying price
\end{itemize}
 
The prototype will be able to let the clients specify standard option strategies such
as spreads, butterflies and straddles, using a simple menu driven graphical user interface.
For each strategy, the client will obtain expected payoffs and their uncertainties.

The prototype will implement default choices whenever feasible, so that a person with
very limited knowledge of options can obtain sensible and useful answers with minimal
inputs. 

The prototype will provide two distinct functionalities:
\begin{itemize}
\item Calibration Engine
\item Valuation Engine
\end{itemize}
The {\it Calibration Engine} will enable experimentation with the data in the
{\it Long Term Database} (see below). Its purpose is to let the client develop estimates
of parameters using historical market data. These estimates can be combined or replaced with
other choices specified by the user, such as implied volatilities etc.
The {\it Valuation Engine} will provide functions to examine and price presently traded contracts,
using the {\it Short Term Database }and the parameter
information supplied by the {\it Calibration Engine}.
The results of the analysis can be displayed in graphical as well as tabular fashion and
will be stored in the {\it Long Term Database} if requested by the client for future reference.

The front end (user interface) will be designed to support both standalone mode or through
a Web browser. It will be written in Java for portability, robustness and security features.

The prototype will implement basic security features such as server and client authentication
without data encryption. A more comprehensive security model will be implemented for the commercial
release, using the then prevailing standards (this is a rapidly developing field). If the
server is operating behind a firewall, then the basic security features will suffice.

The prototype will not implement any logging or accounting, which will have
to be developed or purchased from a third party vendor later on.

The design goal for the prototype is to show that what we will eventually
offer is the most flexible option pricing {\it environment} available today, which is enabled
by algorithmic features, parallel computer resources and portable network-friendly implementation.
For a practitioner, of particular importance are speed and 
the ``What-If'' scenario generation and testing capability. In practice, theoretical pricing
models are used as market benchmarks. Traders use the models to obtain implied volatilities
from current market prices. They may combine implied parameters with historical analysis.
Then, they use the model with these
parameters to construct hedges with respect to various parameters and to
predict option price movements as the stock prices move in the short run. The models are
also used to consistently price new options with respect to actively traded ones.
This can be done quickly only using analytical methods, but the analytical methods are
very restrictive and even outright wrong in their assumptions about how the markets work.
Numerical methods are much more flexible but much slower, particularly when sensitivities
and multiple scenarios must be evaluated. 

Our prototype purports to demonstrate that we have the most flexible numerical method
while at the same time providing {\it real time support} for pricing, hedging and strategy
development.
These capabilities stem from the parallel implementation and the ability of the algorithm to produce
the complete information set about an option in a single simulation. 

\section{Architectural Specification}
\begin{figure}[htp]
\postscript{server.eps}{0.80}
\caption{The Architecture of the Parallel Derivative Valuation Server}
\label{fig:arch}
\end{figure}

\begin{itemize}
\item {\bf Request Broker} The Parallel Derivative Valuation Server consists 
of a number of servers which are
listening to the {\it Request Broker}. The {\it Request Broker} coordinates the tasks
of individual servers and acts as both a client and a server. It is the only module
that communicates directly with the {\it Front End} and the only module which ``knows''
about the other servers. All other servers only listen to the {\it Request Broker} and respond
to its requests. For the prototype all servers and the {\it Request Broker} will have one
instance. In the commercial product, the {\it Request Broker} will be able to spawn
copies of itself as well as other servers if necessary.
The {\it Request Broker} is responsible for formatting the data sets and generating 
plots and graphs as directed by user requests.
\item {\bf Parallel Valuation Engine} is responsible for computation of derivative prices
      and hedge parameters using Monte Carlo simulation. This is the only component that
      will be parallelized at the prototype stage. It is hosted by the SP-2. 
\item {\bf Calibration Engine} is responsible for processing historical data sets
      according to the directives of the {\it Request Broker}. It will rely mostly on
      data stored in the {\it Long Term Database}.
\item {\bf Long Term Database} Stores massive amounts of historical data which are required
      by the {\it Calibration Engine} to generate estimates of model parameters for the
      {\it Valuation Engine}. It is likely that it will generate a lot of network traffic
      to and from the {\it Request Broker} and the {\it Calibration Engine}. Therefore, 
      it is imperative
      that the {\it Request Broker} is multithreaded in the commercial product but not for
      the prototype.
\item {\bf Short Term Database} Stores recent market information about currently traded
      contracts and their market prices. Unlike the {\it Long Term Database} most of the time it will
      provide raw data for plotting and charting. Since it will require frequent updates
      and higher transaction frequency than the {\it Long Term Database} optimization
      considerations require that the two be separate entities.
\item {\bf Front End} Supplies the graphical user interface for obtaining user requests
      and displaying database queries, calibration and valuation results. Most likely will
      be written in Java to ensure portability. It will be decided during the development of
      the prototype whether some and how much of the {\it Request Broker} functionality 
      will be off-loaded
      to the Java clients on the {\it Front End} to improve performance.
\end{itemize}

\section{Human Resources}
Prototype development will require about $32$ man-months. It is expected that four full-time
experienced developers will be working on the prototype for eight months each. One person
will be assigned to the database development. One person will develop parallel modules for
option valuation on the SP-2. One person will be in charge of development of calibration engine.
It is to be decided whether it is worth parallelizing this module for the commercial server,
but it is unlikely that its parallelization can be accomplished on the time scale for the
prototype.
One person will help with development of interfaces between servers, system integration
and will be in charge of graphical user interface. 
All four will contribute to the development of the Request Broker,
which is the master process linking all other servers.

\section{Hardware and Software Resources}
The hardware and software resources will be specified during the first 2-4 weeks of development.
At present, it is known that core hardware resource will be the MHPCC SP-2. However, most of
the development will be performed locally at NPAC's SP-2, due to network limitations. Editing
and debugging across the continent is very slow and frustrating. Parallel software will be
implemented in C and MPI to ensure portability across virtually any parallel platform.
The database server will most
likely be Oracle.
Calibration will be done on one of the nodes of SP-2 in a sequentail fashion (for the prototype).
Special hardware and software might be needed to supply real-time or delayed data feeds from financial
data vendors such as Knight-Ridder, Telerate, Bloomberg, Dow etc. Data vendors will be evaluated
and selected within the first few weeks of the project.
It is likely that GUI builder toolkits will have to purchased to facilitate the development of the
front end.  It is also possible that certain libraries for financial modeling will have to be 
purchased. Apart from Oracle software, it is unlikely that software purchases will require
significant funds. Data feeds may be quite expensive depending on the quantity or timeliness of
data. For prototype development it should suffice to obtain delayed or even end-of-day data, which
should be relatively cheap.

\section{Milestones}
Milestones are measured in weeks from the beginning of project, which is
assumed to be May 1st. There are 4 logical phases of the project with
some overlap between them.
\subsection{Phase I}
\begin{itemize}
\item {\bf (0-2 weeks)} Coarse grain architecture specification
\item {\bf (0-2 weeks)} Selection of implementation environment including: 
   \begin{itemize}
      \item languages
      \item hardware
      \item supporting software toolkits and libraries
      \item selection of database server 
   \end{itemize}
\item {\bf (0-2 weeks)} Selection of financial data vendors. 
\item {\bf (2-4 weeks)} Specification of Database Server Architecture.
\item {\bf (2-4 weeks)} Specification of Simulation Server Architecture.
\item {\bf (2-4 weeks)} Specification of Calibration Server Architecture.
\item {\bf (2-6 weeks)} Installation of data feeds.
\item {\bf (4-6 weeks)} Specification of Network Architecture.
\item {\bf (4-6 weeks)} Specification of graphical user interface (GUI).
\item {\bf (0-8 weeks)} Development of pricing modules for Asian and range options, including
                        parameter sensitivities.
\item {\bf (6-8 weeks)} Incorporation of Asian and range options into the present demo.
\item {\bf (4-8 weeks)} Inititiate work on American options and implement parallel algorithm 
                        for American option critical asset boundary
\end{itemize}
The deliverable of Phase I will be the demo which includes ordinary and exotic path-dependent
European
options. The demo will use the present HTML form-based
interface.

\subsection{Phase II}
\begin{itemize}
\item {\bf (6-9 weeks)} Implementation of data clean-up and preprocessing, i.e. interface
                        between the data feeds and databases.
\item {\bf (6-9 weeks)} Creation of Long Term Database Server tables and views
\item {\bf (9-12 weeks)} Creation of Short Term Database Server tables and views
\item {\bf (6-10 weeks)} Implementation of stochastic processes for the underlying as a part of
   the Simulation Engine.  
   \begin{itemize}
      \item Gaussian
      \item Cauchy
      \item Poisson jump
      \item Gaussian and Poisson jump combined
      \item Cauchy and Poisson jump combined
      \item Histogram of historical returns
   \end{itemize}
\item {\bf (6-12 weeks)} Implementation of the American option valuation modules, given the
      critical asset boundary. 
\item {\bf (12 -16 weeks)} Integration of American option modules into the demo using the
      present HTML form-based interface.
\item {\bf (8-16 weeks)} Implementation of European option pricing modules for futures and
      equity indices,
      including all parameter sensitivities, for constant volatility.
\item {\bf (6-7 weeks)} Implement calculation of Black-Scholes implied volatility from market prices
\item {\bf (6 - 12 weeks)} Develop graphical user interface for Calibration
\item {\bf (12 - 16 weeks)} Develop parts of the graphical user interface for
      single option Simulation (without scenarios and option strategies editor)

\end{itemize}
The deliverable of Phase II will be the demo which includes all of the European options plus
American stock options using the available components of the graphical user interface.


\subsection{Phase III}
\begin{itemize}
\item {\bf (12-18 weeks)} Implementation of the Calibration Engine modules for the above
      stochastic processes:
   \begin{itemize}
   \item Histograms
      \item Correlations
      \item Calculation of moments
      \item Moment substitution estimation
      \item Weighted historical volatility estimation
   \end{itemize}
\item {\bf (12 -14 weeks)} Implementation of a scheme to enable users to create
      deterministic scenarios for volatility.
\item {\bf (12 - 18 weeks)} Build Long Term Database including protocols for
      the interface with the Request Broker
\item {\bf (12 - 18 weeks)} Build Short Term Database including protocols for
      the interface with the Request Broker
\item {\bf (12 - 18 weeks)} Build simple term structure model to enable bond option pricing
\item {\bf (18 - 24 weeks)} Build American bond option pricing module.
\item {\bf (12 - 24 weeks)}  Develop graphical editors for scenario generation and
      option strategies builder
\end{itemize}

The deliverable of Phase III will be the prototype which includes all of the European and American
options on single underlying. Major parts of the graphical user interface are completed. 

\subsection{Phase IV}
\begin{itemize}
\item {\bf (24 - 32 weeks)} Develop simulator for volatility processes:
  \begin{itemize}
  \item geometric random walk stochastic volatility
  \item deterministic volatility defined as a polynomial function of underlying price
  \end{itemize}
      and integrate with
      underlying process simulator. This is the final component of the Simulation Engine.
\item {\bf (28 - 32 weeks)} Implement add-on pricing module for basket options. Use large
      portfolios to demonstrate the speed of the parallel server.
\item {\bf (24 - 32 weeks)} Implement the Request Broker. Each of the modules such as
      Simulation Engine, Calibration Engine etc. will already have specified their interface to the
      Request Broker. The role of the Request Broker is to translate user requests for
      database access, valuation and calibration into data streams to be delivered to the
      appropriate server. The output data streams from the servers are formatted and forwarded to the
      front end for display. Initially, the Request Broker will be implemented without
      sophisticated queueing, scheduling and load balancing features, but that must be
      improved upon in the commercial product. Security features will most likely reside 
      on the Request Broker. The prototype version will implement only user authentication.
\item {\bf (26 - 32 weeks)} Testing and final system integration
\end{itemize}
The deliverable of Phase IV is the complete prototype with database access capabilities, friendly
graphical user interface and full pricing and hedging capability for the specified 
European and American options.

\end{project}
\end{document}


