WebCab Options and Futures v3€¦ · management techniques for European, Asian, American,...

WebCab Options and Futures v3.0

http://www.webcabcomponents.com

Preface

This documentation accompanies the WebCab Options and Futures J2EE Application.The purpose of this documentation is to provide a clear and concise description of all as-pects that are likely to be encountered in real life applications by developers and users ofthis enterprise Application. This EJB Component allows the use of quantitative and riskmanagement techniques for European, Asian, American, Lookback, Bermuda and BinaryOptions; we also cover futures and forward contracts. We apply the Black-Scholes-MertonOptions pricing model using Analytic, Monte Carlo and Finite Difference techniques. Wealso offer estimates of implied and historical volatility, futures account management andmarket risk monitoring techniques.

The first chapter of this documentation contains a brief introduction to the most im-portant implemented features and related system requirements. In chapter two we let thedeveloper quickly get started with deploying the component by detailing deployment tech-niques on the most widely used application servers. We also detail how the functionalityof this component can be tested through connecting to online web service demos hosted atWebCabComponents.com. The third, fourth and fifth chapters contains the financial andmathematical documentation, which represents the theoretical background of this Appli-cations implemented features. Chapters six and seven contains the programmer’s guide,giving a road map for developers to take advantage of every feature and capability. Inchapter eight we provide some examples to illustrate how features detailed within the pro-grammer’s guide can be applied in practice. Finally, in chapter ten we introduce WebCabComponents, its philosophy and approach to serving the JavaTM development communitywith robust and powerful J2EE Applications.

If you have any questions or queries concerning the use of this component then pleasefeel free to contact us via our support forum at:

http://www.webcabcomponents.com/support/index.php

Good luck with your project and thank you for your interest in our components.

The WebCab Components Team

i



Contents

Preface i

1 Introduction 11.1 Product Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Prerequisites and Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Where do I Start? 72.1 Self-Deploy Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Deploying this Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Deploying on IBM WebSphere V4.0 and V5.0 . . . . . . . . . . . . 82.4 BEA WebLogic Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 BEA WebLogic Server 6.1 . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 BEA WebLogic Server 7.0 (J2EE 1.3 compliant) . . . . . . . . . . . 11

2.5 Oracle9i Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.1 Oracle9i v9.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.2 Oracle9i v9.0.3 (J2EE1.3 certified) . . . . . . . . . . . . . . . . . . 14

2.6 Sun ONE AppServer 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7 Borland Enterprise AppServer 5 . . . . . . . . . . . . . . . . . . . . . . . . 152.8 Sybase EAServer 3.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 Ironflare Orion Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.9.1 Orion 1.5.2 (and Orion 1.5.4) . . . . . . . . . . . . . . . . . . . . . 172.9.2 Orion 1.6 (EJB2.0 compliant) . . . . . . . . . . . . . . . . . . . . . 18

2.10 JBoss Open Source Application Server . . . . . . . . . . . . . . . . . . . . 192.10.1 JBoss 2.4.4 (and JBoss 2.4.3) . . . . . . . . . . . . . . . . . . . . . 192.10.2 JBoss 3.0.0 (EJB2.0 compliant) . . . . . . . . . . . . . . . . . . . . 19

3 Options Documentation 203.1 European and Binary Options . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Payoff functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ii

CONTENTS CONTENTS

3.1.2 Put-Call Parity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Trading Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Spreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Volatility and how to estimate it . . . . . . . . . . . . . . . . . . . . . . . . 223.3.1 Standard Historical Estimate . . . . . . . . . . . . . . . . . . . . . 233.3.2 ARCH, EWMA and GARCH models . . . . . . . . . . . . . . . . . 243.3.3 GARCH(1,1) Model . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 Black-Scholes Model for European Options . . . . . . . . . . . . . . . . . . 253.4.1 Options on Indexes, Currencies and Futures . . . . . . . . . . . . . 26

3.5 Greeks for European Options . . . . . . . . . . . . . . . . . . . . . . . . . 263.5.1 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5.2 Delta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5.3 Theta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5.4 Gamma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.5 Vega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.6 Rho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Implied volatility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Futures Documentation 304.1 Futures Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1.1 Forward Contract Pay Off . . . . . . . . . . . . . . . . . . . . . . . 304.2 Using Futures contracts to hedge . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1 Hedging a portfolio using index futures . . . . . . . . . . . . . . . . 304.2.2 Optimal Hedge Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Interest Bearing Investments . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4 Pricing of Futures Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.1 Assumptions underlying the pricing model . . . . . . . . . . . . . . 314.4.2 Futures and Forwards on Stocks, Bonds and Indexes . . . . . . . . 32

4.5 Futures on Commodities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.6 Market Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Exotic Options Documentation 355.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Types of Option Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2.1 Contracts with different Payoff Functions . . . . . . . . . . . . . . . 355.2.2 Weak Path Dependence and American Options . . . . . . . . . . . 365.2.3 Strong Path Dependence - Asian and Lookback Options . . . . . . 375.2.4 Time dependence - Bermudan options . . . . . . . . . . . . . . . . 37

5.3 The Black-Scholes Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 General Methods of Pricing Options in the Black-Scholes World . . . . . . 38

5.4.1 The Black-Scholes Equation . . . . . . . . . . . . . . . . . . . . . . 385.4.2 Boundary and initial / final conditions . . . . . . . . . . . . . . . . 395.4.3 Methods of solving Black-Scholes PDE . . . . . . . . . . . . . . . . 39

iii

CONTENTS CONTENTS

5.5 Finite Differencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5.1 Single-Asset Options . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5.2 Multi-Asset Options . . . . . . . . . . . . . . . . . . . . . . . . . . 425.5.3 Modifications for American Options . . . . . . . . . . . . . . . . . . 435.5.4 Modifications for Strongly Path Dependent Options . . . . . . . . . 44

5.6 Monte Carlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6.1 Random walks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6.2 Generating normal variables . . . . . . . . . . . . . . . . . . . . . . 475.6.3 Options on many underlying assets: Higher dimensions . . . . . . . 475.6.4 Advantages of Monte Carlo simulations . . . . . . . . . . . . . . . . 48

5.7 Sources of Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.7.1 Errors determined by algorithm instability . . . . . . . . . . . . . . 495.7.2 Monte Carlo errors due to number of simulations used . . . . . . . 505.7.3 Finite Differencing errors due to wrong boundary conditions . . . . 505.7.4 Finite Differencing errors due to the size of the price step . . . . . . 515.7.5 Errors due to the size of the time step . . . . . . . . . . . . . . . . 51

5.8 Greeks of Exotic Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.8.1 Finding Greeks of Exotic Options using Monte-Carlo . . . . . . . . 53

5.9 Employee Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.9.1 Details and Assumptions of the Enhanced FASB 123 Model . . . . 545.9.2 Brenchmark Results . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.10 Scenario Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.10.1 Scenario Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.10.2 Scenario Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6 Programmer’s Guide for Options and Futures Module 616.1 Options Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.1.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.1.2 Methods and parameters description . . . . . . . . . . . . . . . . . 62

6.2 Client-Side Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2.1 Client Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2.2 A Client Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.2.3 The create() Methods . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3 Futures Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.3.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4 Client-Side Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 676.4.1 Client Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.4.2 A Client Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.4.3 The create() Methods . . . . . . . . . . . . . . . . . . . . . . . . 69

7 Programmer’s Guide for the Exotic Options Module 707.1 Introducing the Exotic Options Module . . . . . . . . . . . . . . . . . . . . 707.2 Client-Side Implementation Procedure . . . . . . . . . . . . . . . . . . . . 707.3 Specifying Contract Details . . . . . . . . . . . . . . . . . . . . . . . . . . 72

iv

CONTENTS CONTENTS

7.3.1 Payoff Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.3.2 Boundary conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.4 Class Delivery Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.4.1 Remote Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.4.2 Local Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.5 Using JDBC Mediator with our EJBs . . . . . . . . . . . . . . . . . . . . . 787.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.5.2 Connecting to your Database Server . . . . . . . . . . . . . . . . . 797.5.3 JDBC Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.6 Support for Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.6.1 Compilation and Custom Modification of Source Code . . . . . . . 837.6.2 Online Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8 Examples 858.1 Question and Answer (QA) Client Examples . . . . . . . . . . . . . . . . . 85

8.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858.1.2 Structure of QA Examples Directory . . . . . . . . . . . . . . . . . 858.1.3 Top Four levels of the QA Directory Structure . . . . . . . . . . . . 868.1.4 Bottom Two levels of the QA Directory Structure . . . . . . . . . . 868.1.5 Quick Start Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . 868.1.6 Explanation of the QA Directory Structure and its files . . . . . . . 878.1.7 Database Example with JDBC Mediator . . . . . . . . . . . . . . . 88

8.2 Exotic Options Custom Examples . . . . . . . . . . . . . . . . . . . . . . . 898.2.1 About the examples . . . . . . . . . . . . . . . . . . . . . . . . . . 908.2.2 Testing procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908.2.3 Example 1 - European vanilla options . . . . . . . . . . . . . . . . . 908.2.4 Example 2 - Supplying your own payoff function and boundaries . . 918.2.5 Example 3 - Supplying your own payoff function for multi-asset

boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.2.6 Example 4 - Thorough comparison between finite differencing and

Monte Carlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938.2.7 Example 5 - American options . . . . . . . . . . . . . . . . . . . . . 938.2.8 Example 6 - American multi-asset options . . . . . . . . . . . . . . 948.2.9 Example 7 - Example of Bermudan options . . . . . . . . . . . . . . 958.2.10 Example 8 - Example of Binary options . . . . . . . . . . . . . . . . 968.2.11 Example 9 - Example of Asian options . . . . . . . . . . . . . . . . 968.2.12 Example 10 - Example of Lookback options . . . . . . . . . . . . . 978.2.13 Example 11 - Example of Monte Carlo with error control . . . . . . 97

9 Guide to WebCab Components 999.1 The Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999.2 Presentation of Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999.3 Supported Clients, IDEs, Containers and DBMSs . . . . . . . . . . . . . . 999.4 Transparent Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

v

CONTENTS CONTENTS

9.5 Code Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009.6 Company Culture and Activity . . . . . . . . . . . . . . . . . . . . . . . . 1009.7 Product Life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009.8 Support, Warranty and Upgrades . . . . . . . . . . . . . . . . . . . . . . . 101

vi

Chapter 1

Introduction

1.1 Product Description

1.1.1 Overview

Price a broad range of option and futures contracts using a range of price/vol/interest ratemodels. Includes in addition to the general pricing framework a detailed Black-Scholes-MertonModel API for European, Asian, American, Lookback, Bermuda and Binary Options usingAnalytic, Monte Carlo and Finite Difference techniques. We also offer a flexible implementationof a binomial and trinomial trees based pricing engine for the evaluation of employee options inaccordance within the Enhanced FASB 123 model.

1.1.2 Details

WebCab Options and Future implements the following functionality:

General Equity Derivatives Pricing Framework

General Pricing Framework offers the following predefined Models and Contracts:

� Contracts: Asian Option, Binary Option, Cap, Coupon Bond, Floor, Forward Startstock option, Lookback Option, Ladder Option, Vanilla Swap, Vanilla Stock Option,Zero Coupon Bond, Barrier Option, Parisian Option, Parasian Option, Forward andFuture.

� Interest Rate Models: Constant Spot Rate, Constant (in time) Yield curve,One factor stochastic models (Vasicek, Black-Derman-Toty (BDT), Ho & Lee, Hulland White), Two factor stochastic models (Breman & Schwartz, Fong & Vasicek,Longstaff & Schwartz), Cox-Ingersoll-Ross Equilibrium model, Spot rate model withautomatic yield (Ho & Lee, Hull & White), Heath-Jarrow-Morton forward rate model,Brace-Gatarek-Musiela (BGM) LIBOR market model.

� Price Models: Constant price model, General deterministic price model, Lognormalprice model, Poisson price model.

1

Introduction Chapter 1

� Volatility Models: Constant Volatility Models, General Deterministic Volatilitymodel, Hull & White Stochastic model of the Variance, Hoston Stochastic Volatilitymodel.

Once the contract and the price/interest/vol model combination has been set you able torun the Monte Carlo Pricing Engine which allows:

� Evaluate Price: Evaluate price estimate accordance to number of iterations ormaximum expected error

� Estimate Error: Evaluate the standard deviation of the price estimate, and theminimum/maximum expected price for a given confidence level.

Exotic Options Module

The Exotic Options module implements the following functionality:

� Types of Options - Within this module we show explicitly how-to and offer prac-tical advice on the valuation of Asian, American (single and multi-asset), Lookback,Bermuda, European (single and multi asset) and binary options using the MonteCarlo and Finite Difference techniques.

� Finite Difference Methods - powerful method for finding solutions of the Black-Scholes Equations.

– Single Asset Options - We provide an explicit and fully implicit algorithmsincluding a framework in which to measure stability issues under differing sce-narios.

– Crank-Nicholson - is a fast and stable method for evaluating single assetoption contracts.

– Multi-Asset - Implement a general multidimensional finite-difference algo-rithm.

– American, Bermuda Options Modification - we apply the ‘SuccessiveOver-relaxation’ technique in order to value American and Bermuda options.

– Asian and Lookback - examples of how strongly path dependent options canbe evaluated using Finite Difference methods is given.

– Implied Volatility - Evaluate the implied volatility of a number of Exoticoptions including American, Asian, Lookback and Binary in accordance withthe Black-Scholes model.

� Monte Carlo - can be effectively applied to value a large range of option contracts.

– Flow implementation - including generation of normal variables and the sim-ulation of the random walk and corresponding cash flows ensures that our imple-mentation of this technique can be applied to value almost any option contract.

2


– Options on many underlying assets - Generate correlation random variableusing Cholesky factorization in order to value options contract of European typewhich depend on many underlying assets.

– Control Structure - the user has full control over the number of simulationsand/or the required precision.

Trees Module

The Trees module implements the following functionality:

� Employee Options - A binomial and trinomial trees based pricing engine for theevaluation of employee options in accordance within the Enhanced FASB 123 modelas detailed within the paper, ’How to value Employee Stock Options’, by John Hulland Alan White (September 2002).

� Volatility models - Constant volatility model, and determinist volatility modelsprovided by using interpolation points or user define function of time.

� Interest Rate Models - Constant interest rate model or Yield Curve Model deducedfrom bond prices, forward rates, zero rates, forward rate curve can be used.

Options Module

The Options module offers the following functionality:

� European and Binary Options - The (Analytic) Black-Scholes model is fullyimplemented for European and Binary Options on stocks, currencies and indexes.We also include the Black-76 model for the evaluation of options on futures contracts.

� ‘The Greeks’ - We offer methods for the evaluation of ‘the Greeks’ (delta, gamma,rho, theta, vega) for European options on stocks, indexes and currencies accordingto the Black-Scholes model.

� Volatility Estimates - the volatility may to estimated directly from historical valuesor from one of the following models:

– ARCH - Autoregressive Conditional Heteroscedasticity model.

– EWMA - Exponentially Weighted Moving Average model.

– GARCH(1,1) - Generalized Autoregressive Heteroscedasticity model.

� Implied Volatility - Calculates the implied volatility for dividend and non-dividendpaying stocks from the Black-Scholes formulae.

� Payoff Functions - Pay off functions at expiry for European and Binary Optionsare implemented.

� Put - Call Parity relations

3


– Put - call parity relations for European options on an asset with no yield ora continuous yield.

– Put - call parity relations for Binary options on an asset with no yield.

– Implied risk-free interest - the implied risk free interest rate is calculatedwhen either the prices of put/call European or put/pull Binary option is known.

� Trading Strategies - the following pay-off functions for the following option tradingstrategies are implemented.

– Spread Option Strategies - Bull Spreads, Bear Spreads and Butterfly Spreads.

– Combination Option Strategies - Straddles and Strangles.

Futures Module

The Futures module implements the following methods and procedures:

� Pricing on investment and consumption assets - Pricing of futures contractson stocks, bonds, indexes, currencies and commodities.

– Futures on stocks, bonds, indexes - evaluation for assets with or withoutincome, effective gearing.

– Futures on commodities - cost of carry, utility yield.

� Hedging - Portfolio hedging using index futures, optimal hedge ratio.

– Portfolio Hedging - delta hedge a portfolio using the beta coefficient.

– Optimal Hedge Ratio - the optimal ratio of the size of the position taken infutures contracts and the size of the exposure.

� Future Account management - margin, daily P&L, total equity, excess margin.

� Interest calculations - return, compound interest, compounding periods conver-sion.

The Risk Management functionality included within this Component:

� Delta Limit Monitoring - For a portfolio (which may include Futures, Options,etc) the delta limit can be assigned and checked.

� Scenario Analysis - Allows for an asset or portfolio to be stressed and for theresulting behavior to be analyzed. We offer methods which stress the asset in anyone or two of the underlying market variables.

4


Technology Aspects

This product also contains the following features:

� GUI Bundle - we bundle a suite of graphical user interface JavaBean components(with 1, 2, 4 or site-wide license) allowing the developer to plug-in a wide range ofGUI functionality (including charts/graphs) into their client applications

� EAR Files - we provide individual customized EAR files for the most widely usedapplication servers including IBM WebSphere 4.0/5.0, BEA WebLogic 6.1/7.0, Oracle9iAS, Sun ONE AppServer 7, Ironflare Orion 1.5.2/1.6.0, Borland AppServer 5.0,Sybase EAServer 3.6 and JBoss 2.4.4/3.0.0

� Self-Deploy - the relevant servers EAR file will be self-deployed onto supported localapplication servers during the installation of the self-install package. The supportedapplication servers include IBM WebSphere 4.0/5.0, BEA WebLogic 6.1/7.0, Oracle9iAS, Borland AppServer 5.0, Ironflare Orion 1.5.2/1.6.0 and JBoss 2.4.4/3.0.0

� JDBC Mediator - A server side EJB component which mediates between an EJBcomponent, clients and DBMS. The mediator moves most of a clients JDBC calls tothe server and hence greatly increases the speed of JDBC client applications.

� Web Application Example - A JSP interactive HTML interface which enables you totest every component method directly from your browser.

� Synthetic JDBC - we use a JSP component to perform EJB calculations on SQLdatabase columns from a remote DBMS. We apply an EJB function to certain rowsfrom the database and list the output in HTML format. This is a powerful featuresince it allows you to perform calculations in a JDBC manner without having tocode the EJB-to-JDBC transaction yourself as it is all done by the JSP within theApplication Server.

1.2 Prerequisites and Compatibility

1.2.1 System Requirements

� An Operating System running JavaTM

� Pentiumr

III 733 MHz

� 256MB RAM

� A J2EE1.3 (EJB 2.0) compatible Application Server

5


1.2.2 Compatibility

Operating System for Deployment

� Windows 2003, XP, 2000, NT

� Sun Solaris

� Linux

� IBM AIX

� HP-UX

Component Type

� Enterprise JavaBeansTM

Built Using

� JavaTM 2 SDK Standard Edition 1.4.2

� JavaTM 2 SDK Enterprise Edition 1.3

Compatible Application Servers

� IBM WebSphere Application Server V4.0/V5.0

� BEA WebLogicr

Server 6.1/7.0

� Oracler

9i Application Server

� Sun One Application Server 7

� Borland Enterprise AppServer 5.0

� Ironflare Orion Server 1.5.2/1.6.0

� Sybase EAServer 3.6

� JBoss 2.4.4/3.0.0

6

Chapter 2

Where do I Start?

Start using the Options and Futures v3.0 J2EE Application right away by following the fewquick and simple steps described in this chapter. We provide support for most Java compatibleoperating systems, such as Windows, Linux, IBM AIX, HP-UX and Solaris. Along with the mostwidely used Application Servers including IBM WebSphere, BEA WebLogic, Oracle9i, Sun ONEAppServer, Borland AppServer, Sybase EAServer, Ironflare Orion, and JBoss. If you requireadditional information regarding the use of this J2EE Application, then please don’t hesitate tocontact us via our support forum at: http://www.webcabcomponents.com/support/index.php.

2.1 Self-Deploy Installer

If you are locally using one of the following application servers:

� IBM WebSphere V4.0/V5.0

� BEA WebLogic 6.1/7.0

� Oracle9i v9.0.2/v9.0.3

� Borland Enterprise AppServer 5

� Ironflare Orion 1.5.2/1.6.0

� JBoss 2.4.4/3.0.0

During the installation of this Application, you were prompted to follow the deploymentprocedure of your application server. In this case the Application should already be de-ployed on your application server and you can start using it immediately.

If the Application is not installed on your local application server or you wish to deployon a remote application server then you should follow the relevant steps below.

7


Where do I Start? Chapter 2

2.2 Deploying this Component

Depending on the Enterprise platform you have chosen for distributing your businesscomponents, you will follow different procedures when starting off. Within this chap-ter we describe individual Application Server deployment procedures. Please feel free toskip to the section that refers to the Application Server you are planning to use.

In case your Application Server is not listed in this chapter or the installation of yourApplication fails, please send us an email to [email protected] attachingany logs or error messages.

2.3 IBM WebSphere Application Server

The deployment procedures for IBM WebSphere V4.0 and V5.0 are the same. The onlydifference is that on WebSphere V4.0 you will be deploying the EJB1.1 version of Optionsand Futures, whereas on WebSphere V5.0 you will be able to install the EJB2.0 version aswell.

2.3.1 Deploying on IBM WebSphere V4.0 and V5.0

Starting the Server

The WebSphere Application Server (WAS) requires to be up and running at deploymenttime. Start the server under Windows by selecting Programs→IBM WebSphere→ApplicationServer V4.0 (resp. V5.0). Alternatively, the server can be started by running the startServer.batscript from the installation path. Under Linux log in as root, change to the ${WAS HOME}/bindirectory, where ${WAS HOME} is the WebSphere installation path, and type the follow-ing line at command prompt1:

./startServer.sh

Connecting to the Administration Console

Connect to the WAS Administrative Console, by opening a browser and typing in thefollowing URL address:

http://localhost:9090/admin

where localhost can be replaced by the hostname of the computer running WebSpherewhen connecting from a client machine. The browser will bring up a login page and askyou to fill in a name in order to track user-specific changes to configuration data. You mayleave the field blank and press the Submit button. If an Alert page is displayed, press theCancel button and continue.

1${WAS HOME} usually defaults to /opt/WebSphere/AppServer under Unix.

8

mailto:[email protected]


Deployment

The Administrative console manages the Application Server into nodes and each noderuns its own Enterprise Applications. You will be deploying inside one of the existingnodes which you can select from the left panel by expanding the Nodes folder. Ex-pand the name of the installation node and select the Enterprise Applications item. Thebrowser will bring up in the central frame a list of all currently installed Enterprise Ap-plications. Click the Install button, browse the Options.ear file, as installed under the[ROOT DIR]/Options/Deployment/IBM WebSphere V4.x2 directory and click Next3.

IBM WebSphere V4.0/V5.0 Application Installation Wizard Page.

Click again Next through every screen until you reach the Mapping Resource References toJNDI Names screen. You will be required to map certain resource references to WebSphereDataSource JNDI names4. Keep clicking Next in every screen and press Finish to completethe deployment.

2If this is the V5.0 version of WebSphere, consider browsing from [ROOT DIR]/Options/DeploymentEjb2.0/WebSphere V5.0.

3[ROOT DIR] represents the Options and Futures installation directory.4Read the IBM WebSphere documentation for information about how to define DataSources.

9


After waiting for a few minutes, the Administrative Console will display a page whereOptions and Futures v3.0 will be listed among the currently installed Enterprise Applica-tions.

Restarting the server

When installing Options and Futures v3.0 for the first time inside WebSphere, you will berequired to restart the IBM server before running it. You will also need to save the currentconfiguration before doing so. Click on the Configuration needs to be saved link located atthe top of the page and confirm the save by pressing OK.

In order to stop the server, click the Application Servers folder from the left pane un-der the current node and press the Stop button. In the next page click OK and wait for theconsole to confirm a successful shutdown. The next time you start the WebSphere serverthe Options and Futures Application will be installed and made available to all clients.

2.4 BEA WebLogic Server

2.4.1 BEA WebLogic Server 6.1

Enterprise JavaBeanTM components and J2EE Application are deployed inside a runningWebLogic 6.1 server through a web browser interface. On this server you will be installingthe EJB1.1 version of Options and Futures.

Starting the server

Start BEA WebLogic 6.1 under Windows from the Programs→BEA WebLogic E-BusinessPlatform→WebLogic Server 6.1→Start Default Server icon in the Start Menu. If you’rerunning WebLogic 6.1 under Linux, change the current directory to /home/user/bea/wlserver6.1/config/mydomain, where user is your Unix account and mydomain points tothe default domain name. Within this folder type the following line at command prompt:

./startWebLogic.sh

If asked for, enter the login password and wait a few seconds until the server to initializes.

Connecting to the WebLogic Console

When the WebLogic Server is up and running, open an Internet browser and type in thefollowing address:

http://localhost:7001/console

where localhost can be replaced by the hostname of your server running WebLogic, whenconnecting from another client machine. At the login screen enter the user name (“system”

10


by default) and type in the login password. The browser will bring up the BEA WebLogicServer support interface.

Deployment

You will see in the left side of the screen your domain’s name and a list of currently deployedEnterprise Applications. Click on the Applications item under the Deployments folder, thenclick the Install a new Application... link in the right panel.

WebLogic Server 6.1 Upload and Install Screen.

Browse the Options.ear archive from [ROOT DIR]/Options/Deployment/BEA WebLogic6.1 directory and click the Upload button5. The J2EE Application will be uploaded anddeployed inside the WebLogic Server 6.1.

2.4.2 BEA WebLogic Server 7.0 (J2EE 1.3 compliant)

Enterprise JavaBeanTM components are deployed inside a running WebLogic 7.0 serverthrough a web browser interface. Since WebLogic Server 7.0 is J2EE1.3 compatible, youwill be installing the EJB2.0 version of Options and Futures.

Starting the server

Start BEA WebLogic 7.0 under Windows from the Programs→BEA WebLogic Platform7.0→User Projects→mydomain folder in the Start Menu, by clicking the “Start WebLogic

5[ROOT DIR] is the Options and Futures installation directory, as specified at installation time.

11


Server” icon. Alternatively, you may start the server by running the startWLS.cmd scriptinside the C:\bea\weblogic700\server\bin folder.

If you’re running WebLogic 7.0 under a Linux platform, change the current directoryto [WEBLOGIC HOME]/weblogic700/server/bin, where [WEBLOGIC HOME] points tothe BEA home directory, as installed under Linux, for example /home/user/bea. In thisfolder type the following line at command prompt:

./startWLS.sh

If asked for, enter the login password and wait a few seconds until the server initializes.

Connecting to the WebLogic Server Console

When the BEA WebLogic Server is up and running, open an Internet browser and type inthe following address:

http://localhost:7001/console

where localhost can be replaced by the hostname of the server running WebLogic, whenconnecting from another client machine. In the login field, enter your user name (“system”by default) and type in the login password. The browser will bring up the BEA WebLogicServer 7.0 Console.

Uploading the Application

You will see in the left side of the screen your domain name and a list of currently de-ployed Enterprise Applications under the Deployments/Applications tree. Click on the Ap-plications item under the Deployments folder, and press Configure a new Application... inthe right panel. Click the link that says “upload it through your browser” and browsethe Options.ear archive from [ROOT DIR]/Options/Deployment Ejb2.0/WebLogic 7.0directory and click the Upload button6.

Deployment

After the upload is complete the page will display at the bottom of the screen the nameof the uploaded file, Options.ear. Click the “[select]” link at its left.

6[ROOT DIR] is the Options and Futures installation directory, as specified at installation time.

12


WebLogic Server 7.0 Deployment Page.

In the Step 3. section choose an available server and add it to the Target Servers box bypressing the right arrow. As a final step, press the Configure and Deploy button in the Step5. section.

The next page will guarantee a successful deployment if the Status at the bottom of thescreen displays a message that says “Running”.

2.5 Oracle9i Application Server

We support installation under Oracle9i v9.0.2 and v9.0.3 Application Servers. The deploy-ment procedures for Oracle9i 9.0.2 and 9.0.3 are quite similar. The major difference isthat on Oracle9i 9.0.2 you will be deploying the EJB1.1 version of Options and Futures,whereas on Oracle9i 9.0.3 you will be able to install the EJB2.0 version as well.

2.5.1 Oracle9i v9.0.2

In order to deploy the EJB1.1 version of Options and Futures on your Oracle9i 9.0.2Application Server, follow these three simple steps:

1. Change current directory to the Oracle9i Application Server installationpath. Usually it is located in the j2ee/home subfolder of your Oracle9i DBMS home

13


directory. You can identify this folder by looking for a file named oc4j.jar (OracleContainers for J2EE).

2. Start Oracle9i v9.0.2. In a command prompt window, type the following line:

java -jar oc4j.jar

3. Deploy Options and Futures. In another command prompt window, type thefollowing two lines:

Line 1java -jar admin.jar ormi://localhost admin "password" -deploy -file

"[ROOT DIR]/Options/Deployment/Oracle9i/Options.ear”-deploymentName "Options"

Line 2java -jar admin.jar ormi://localhost admin "password"-bindWebApp Options Options http-web-site Options

Note that password is your administration password and [ROOT DIR] is the in-stallation directory of Options and Futures.

2.5.2 Oracle9i v9.0.3 (J2EE1.3 certified)

In order to deploy the EJB2.0 version of Options and Futures on your Oracle9i 9.0.3Application Server, follow these three simple steps:

1. Change current directory to the Oracle9i Application Server installationpath. Usually it is located in the j2ee/home subfolder of your Oracle9i DBMS homedirectory. You can identify this folder by looking for a file named oc4j.jar (OracleContainers for J2EE).

2. Start Oracle9i v9.0.3. In a command prompt window, type the following line:

java -jar oc4j.jar



"[ROOT DIR]/Options/Deployment Ejb2.0/Oracle9i v9.0.3/Options.ear”-deploymentName "Options"

14


Line 2java -jar admin.jar ormi://localhost admin "password"-bindWebApp Options Options http-web-site Options


2.6 Sun ONE AppServer 7

Starting the Application Server

On Windows, click the Windows Start button, then choose Programs→Sun ONE Applica-tion Server 7→Start Application Server. If you are working under Unix, change the currentdirectory to $SUN HOME/bin, where $SUN HOME is the Sun ONE installation path andtype the following line at command prompt:

asadmin start-appserv

Starting the Administration Console

After the Sun ONE server initializes, open an Internet browser and type in the followingaddress:

http://localhost:4848/admin

where localhost can be replaced by the hostname of your server running Sun ONE, ifyou are connecting from a different machine. At the login screen enter the administratoruser name (“admin” by default) and type in the login password. The browser will bringup the Sun ONE Administration Console.

Deployment

Choose Applications→Enterprise Apps in the left-hand panel and click the Deploy... but-ton in the page on the right. Browse the [ROOT DIR]/Options/Deployment Ejb2.0/SunONE/Options.ear file where [ROOT DIR] is the Options and Futures installation directoryand click OK. Press again OK in the next screen and allow a couple of minutes to completethe deployment process.

2.7 Borland Enterprise AppServer 5

In order to deploy this Application inside Borland AppServer 5.0, you will need to performthe following tasks in the following order:

1. Start the Borland Enterprise ServerUnder Windows you will click the Borland Enterprise Server→Server icon from the

15


Start menu and wait a couple of seconds for the server to initialize. Under Unixtype: bin/ias at the command prompt from the installation directory.

2. Open the Administration ConsoleYou can open the Borland Enterprise Administration Console by clicking the BorlandEnterprise Server→Console icon from the Start menu, if you are running under theWindows operating system. A login dialog will pop up, where you can click the Loginbutton without making any modifications at all. Under Unix type: bin/console

from the installation directory.

3. Deploy Your J2EE ModulesSelect Tasks→Deployment→Deploy J2EE modules to a partition... to open the J2EEDeployment Wizard. Click the Add button and select the Options.ear archive fromthe [ROOT DIR]/Options/Deployment Ejb2.0/Borland AppServer 5 folder, where[ROOT DIR] is the root directory where Options and Futures was installed.

Borland AppServer 5 Deployment Dialog.

At the bottom of this dialog, turn on the Generate Stubs option and click Next. Thedeployment process will scroll inside a text area. When it completes, press the OKbutton.

16


2.8 Sybase EAServer 3.6

Deployment inside EAServer 3.6 is performed using the Jaguar Manager inside a runningJaguar Server.

1. Start you Jaguar ServerUnder Windows, open Explorer, navigate to the EAServer installation folder and runthe serverstart jdk12.bat file by double-clicking it. If you are running the JaguarServer under Unix, change your current directory to the EAServer installation pathand type in the following line at command prompt:

./srvstart jdk12

2. Deploy to your Jaguar RepositoryOpen the Jaguar Manager and connect to the previously started Jaguar server. Right-click with your mouse the Packages folder under Sybase Central Java Edition→JaguarManager and select Deploy→EJB 1.1 Jar from the popup menu. In the Deploy Wizarddialog, browse the [ROOT DIR]/Options/Deployment/Sybase/Options.ear file7 andclick Next. Wait for a few seconds in order to allow the deployment to take place andpress the Close button when done.

3. Deploy Inside your Jaguar ServerFrom the Jaguar Manager, right-click the Installed Packages folder from the left paneland select Install Package... in order to bring up the Package Wizard dialog. Click onthe Install an Existing Package button and select Options from the list. Press OK tocomplete deployment inside EAServer.

2.9 Ironflare Orion Server

We support installation under Ironflare Orion 1.5.2, 1.5.4 and 1.6 Servers. The deploymentprocedures for Orion 1.5.2 and 1.6 are quite similar. The major difference is that on Orion1.5.2. you will be deploying the EJB1.1 version of Options and Futures, whereas on Orion1.6 you will be able to install the EJB2.0 version as well.

2.9.1 Orion 1.5.2 (and Orion 1.5.4)

In order to deploy the EJB1.1 version of Options and Futures on your Orion 1.5.2 Server,follow these three simple steps:

1. Change current directory to the Orion Server installation directory. Youcan identify it knowing it contains a file named orion.jar.

2. Start Orion Server 1.5.2 In a command prompt window, type the following line:

7[ROOT DIR] is the root directory where Options and Futures was installed.

17


java -jar orion.jar



"[ROOT DIR]/Options/Deployment/Ironflare Orion 1.5.x/Options.ear”-deploymentName "Options"

Line 2java -jar admin.jar ormi://localhost admin "password"-bindWebApp Options Options default-web-site Options


2.9.2 Orion 1.6 (EJB2.0 compliant)

In order to deploy the EJB2.0 version of Options and Futures on your Orion 1.6 Server,follow these three simple steps:

1. Change current directory to the Orion 1.6 Server installation path. Youcan identify this folder by looking for a file named orion.jar.

2. Start Orion Server 1.6 In a command prompt window, type the following line:

java -jar orion.jar



"[ROOT DIR]/Options/Deployment Ejb2.0/Orion 1.6/Options.ear”-deploymentName "Options"

Line 2java -jar admin.jar ormi://localhost admin "password"-bindWebApp Options Options default-web-site Options


18


2.10 JBoss Open Source Application Server

We provide deployment instructions and resources for JBoss 2.4.4 (with TomCat 4.0.1) and3.0.0 (with TomCat 4.0.3). Under JBoss 3.0.0 or later you will be deploying the EJB2.0version of Options and Futures. All previous JBoss versions will only support the EJB1.1Application.

2.10.1 JBoss 2.4.4 (and JBoss 2.4.3)

Start the JBoss Server by changing the current directory to [JBOSS HOME]/jboss/bin,where [JBOSS HOME] is the installation path for your JBoss 2.4.4 release. Under Win-dows, type at command prompt:

run.bat

If you are running JBoss under Linux, you will type in the following:

./run.sh

and wait for a few seconds until the JBoss server is up and running.

In order to deploy Options and Futures, you will need to make a copy of the Options.ear

Enterprise archive located inside the [ROOT DIR]/Options/Deployment/JBoss directoryinto the [JBOSS HOME]/jboss/deploy folder8.

2.10.2 JBoss 3.0.0 (EJB2.0 compliant)

Start the JBoss Server by changing the current directory to [JBOSS HOME]/bin, where[JBOSS HOME] is the installation path for your JBoss 3.0.0 release. Under Windows, typeat command prompt:

run.bat

If you are running JBoss 3.0.0 under Linux, you will type in the following:

./run.sh

and wait for a few seconds until the JBoss server is up and running.

In order to deploy Options and Futures, you will need to make a copy of the Options.ear

Enterprise archive located inside the [ROOT DIR]/Options/Deployment Ejb2.0/JBoss 3.0.0directory into the [JBOSS HOME]/server/default/deploy folder9.

8[ROOT DIR] is the root directory where you installed Options and Futures.9[ROOT DIR] is the root directory where you installed Options and Futures.

19

Chapter 3

Options Documentation

An option is the right to trade a particular asset at some time or interval in the futureat an agreed price. The mechanism for determining the agreed price and the variety withwhich the option can be exercised leads to the large range of options which exist withinfinancial markets.

Within Options theory there are a number of terms which are repeated used. Belowwe define the use of these terms once and for all so that they can be used within the restof this documentation and within the JavaDocs without confusion.

� Premium - the amount paid for the option contract

� Underlying (asset) - the financial instrument which the options depends upon, de-noted by S

� Strike (or exercise) price - the amount with which the underlying can be brought(call) or sold (put) during the period when the option can be exercised, denoted byEc, Ep, respectively

� Expiration date - the date of expiry of the option contract, denoted by T

� Intrinsic value - the payoff that would be received if the underlying is at its currentlevel when the option expires

� Time value - the value in excess of the intrinsic value

3.1 European and Binary Options

A European (or Vanilla) option is one of the following two types:

� Call option: a call option is the right to buy an asset Sc, at an agreed price Ec, at afixed time Tc

� Put option: a put option is the right to sell an asset Sp, at an agreed price Ep, at afixed time Tp

20

Options Documentation Chapter 3

We will also consider binary options (or digitals) which are contracts which have a payoffat expiry which is discontinuous in the underlying asset price. We consider a binary calloption which has a given fixed payoff if the underlying asset is greater or equal to thestrike price at expiry. The binary put option is similarly defined to have a fixed payout ifthe underlying asset is less than the strike price at expiry.

3.1.1 Payoff functions

The payoff function of an option contract is the cash (or equivalent) settlement which theinvestor receives at expiry. The payoff functions for an European option at expiry are givenby:

Call Option payoff function = max(Sc − Ec, 0)

Put Option payoff function = max(Ep − Sp, 0)

respectively.

We also provide the payoff functions for put and call Binary options.

3.1.2 Put-Call Parity

By arbitrage arguments one is able to derive what is generally referred to as put-call parityrelations. This allows for example the European call option price to be derived from theEuropean put option price when the two options act on the same underlying asset with thesame strike and expiry date. Similarly the European put option price can also be derivedfrom the European call option. The case when the underlying assets pay no dividend andpays a continuous dividend are treated for European options. In a similar fashion we alsooffer parity relations for binary options on assets which do not pay a dividend during thelife of the option.

In order to derive the call (or put) options value for a put (respectively call) option withthe use of parity relations we need to know the (fixed or average) risk free interest rateduring the life of the option contract. Within our component we allow the user to derivethe implied risk-free interest rate when the put and call option values are known in thefollowing instances:

� European options on an asset with zero yield

� European options on an asset with continuous yield

� Binary options on an asset with zero yield

3.2 Trading Strategies

An option trading strategy generally involves the use of more than one option which dis-plays a preferred payoff function characteristic from the investors stand point. Here we

21


discuss a number of trading strategies which have become widely used within various fi-nancial markets.

3.2.1 Spreads

A spread trading strategy involves taking a position in two or more options on the sameunderlying asset and with the same expiry date. Procedures for the evaluation of the payoff functions at maturity of the following spreads are given:

� Bull Spreads - Buying a call option with strike x1, and selling a call option on thesame asset but with a strike x2, where x1 ≤ x2. The individual entering into thiscontract will gain if the underlying asset rises in value.

� Bear Spread - Buying a call option with strike x1, and selling a call option on thesame asset but with a strike x2, where x1 ≥ x2. The individual entering into thiscontract will gain if the underlying asset falls in value.

� Butterfly Spread - This trading strategy involves the use of three options with dif-ferent strikes. To construct the spread the investor must buy a call option with arelatively high strike x1, and a relatively low strike price x2, and sell two options witha strike midway i.e. at (x1 + x2)/2. Generally, the butterfly spread is constructedwith the midpoint close to the present market value. In this case the investor willgain if the price at expiry is close to its present price and will take a small loss if theprice moves significantly in either direction.

3.2.2 Combinations

A combination is an option trading strategy which involves taking positions in both putand call options on the same underlying asset. Methods for the evaluation of the payoff ofthe following strategies an given:

� Straddle Combination - involves taking a long position in a call option and a longposition in a put option with the same strike price and expiration date.

� Strangle Combination - consists of a long position in a call option and a put optionwith different strike prices and the same expiry date.

3.3 Volatility and how to estimate it

The volatility is a measure of the degree to which a given quantity fluctuates, which is in asense the amount of randomness of that parameter. The volatility is most commonly firstencountered in the context of the volatility of an assets price in order to be applied to thepricing of European options in the context of the Black-Scholes model (see below). Evenin the context of European options and the Black-Scholes model that is the (constant)volatility of the underlying asset price there are a number of senses in which the volatilitywill be referred to, namely:

22


� Historical Volatility - Measure of the past fluctuations of the underlying assetprice. Below we describe the most common historical measure of the volatility usedwhich is the standard deviation of the log of the price returns.

� Implied Volatility - The volatility implied from the price of the European option inaccordance with the Black-Scholes model. However, in general the implied volatilitycould be deduced from any option price in accordance with any (volatility based)option pricing model.

� Forecast Volatility - An estimate of the future volatility of the underlying assetprice over some period. This is a required parameter within option pricing models.

It is important to point out that there is no one true measure of volatility. Moreover,the measure should be tailored to take into account its application. For example, withinthe Black-Scholes model we which to know as a model parameter the average volatilityover a given period, whereas when evaluating value-at-risk (VaR) or performed portfoliooptimization (CAPM) we are interested in the present value of the volatility of the assetswithin the portfolio.

3.3.1 Standard Historical Estimate

The historical volatility (as mentioned above) is most commonly estimated as the standarddeviation of the log of the asset returns. That is, if

� Si = the asset price at the end of the ith day

� Di = the interest payment (or dividend) from the asset on the ith day

� n = the number of days over which the historical data is taken

Then the log of the return on the ith day is given by:

ui = ln

(Si + Di

Si

)for i = 1, 2, . . . , n, and the historical daily volatility estimate, using the past n daysobservations of the asset price is given by:

Daily Volatility =

√√√√ 1

n− 1

n∑i=1

(ui − u)2 (3.3.1)

where u is the arithmetic average of the returns ui’s, over the n days.

Remarks If we had considered the returns on the underlying asset over the past nmonths then the corresponding formula for (3.3.1) would express the historical volatilityper month. Similar remarks hold if other time periods are used.

23


We are able to express the historical volatility derived from the n asset prices with re-spect to another time period. In particular, we are able to derive the annual volatility.

The standard error per annum of the (annual) volatility historical volatility estimate isgiven by:

s∗√2n

where s∗ is the annual volatility.

Our Implementation

This estimation procedure has been implemented within the EJB Component as the fol-lowing two methods:

� Volatility.historicalEstimate - Estimates the historical volatility of an asset whichdoes not pay dividends or interest payments.

� Volatility.historicalEstimateWithDividends - Estimates the historical volatility of anasset which does pay dividends or interest payments.

The volatility evaluated by the historical procedure can be rescaled by the procedures:

� Volatility.yearDaysRescaling - Rescaling annual volatility to volatility over a givennumber of days.

� Volatility.daysYearRescaling - Rescaling the volatility over a number of days to theannual volatility.

We also provide to following error estimate:

� Volatility.historicalEstimateStandardError - The standard error of the historical an-nual volatility estimate.

3.3.2 ARCH, EWMA and GARCH models

These models where introduced to produce more accurate estimates of the present volatil-ity from historical data. With these more refined models more weight is give to recentmeasurements and an aspect of reversion to mean is incorporated which is displayed byvolatility in real world situations is incorporated within the models.

Within the volatility class we implement all of these models offering more refined meansby which to estimate and predict the volatility. The full names for these models are:

� ARCH - autoregressive conditional Heteroscedasticity

� EWMA - exponentially weighted moving average

� GARCH - generalized autoregression conditional heteroscedasticity

24


ARCH Model

The ARCH model was first suggested by R.Engle, see ‘Autoregressive Conditional Het-eroscedasticity with Estimates of the Variance of UK Inflation,’ Econometrica, 50 (1982),987-1008. This estimate is based on the long term volatility (v) and historical observations(si).

EWMA Model

This model is a special case of the ARCH model. The weights assigned to the historical val-ues decrease exponentially. J.P.Morgan uses the EWMA model for updating daily volatilityestimates in its RiskMetrics database. In particular, if the weights are {αi : i ∈ 1, . . . , n},then the relation between the weights is given by αi+1 = λαi, where λ is a constant be-tween zero and one. J.P.Morgan found that across a range of market variable, by takingλ = 0.94, the forecasts of the volatility rate came closest to the realized volatility.

3.3.3 GARCH(1,1) Model

The GARCH(1,1) model was introduced by Bollerslev in 1986, see ‘Generalized Autore-gressive Conditional Heteroscedasticity’, Journal of Econometrics, 31(1986),307-27. TheEWMA model is a special case of the GARCH(1,1) model. The GARCH model exhibitsmean reversion whereas the EWMA model does not and hence the GARCH model istheoretically more appealing than the EWMA model.

3.4 Black-Scholes Model for European Options

We consider the Black-Scholes model for the evaluation of European put and call optionsat time zero on assets with or without interest payments. In particular, for the Europeanput (denoted by ‘p’) and call (denoted by ‘c’) options there exists closed formulae givenby:

c = S0N(d1)−Xe−rT N(d2)

p = Xe−rT N(−d2)− S0N(−d1)

where

d1 =ln(S0/X) + (r + σ2/2)T

σ√

T

d2 = d1 − σ√

T

and N(x) is the normal probability distribution with zero mean and standard deviation of1. The constant S0 is the stock price at time zero, X is the strike of the options, r is thecontinuously compounded risk free interest rate, σ is the volatility and T is the time tomaturity of the option.

The case when there exists dividends is handled by assuming that the stock price con-sists of a riskless component of the known dividend payments during the option period

25


and a risky component which accounts for the remainder of the option price. By discount-ing the dividend payments by the risk free interest rate we can deduce the present valueof the option taking into account the effect of dividend payments which will decrease thevalue of the underlying asset. Strictly speaking the volatility used for this method shouldbe the volatility of the stock price net the present value of the assets dividend.

3.4.1 Options on Indexes, Currencies and Futures

European options on indexes, currencies and futures contracts are also traded on exchangesand within the over-the-counter market. By extending the classical Black-Scholes modelfor stocks we are able to evaluate options on this wider range of underlying assets.

These methods cover the evaluation of the following contracts:

� Index options on the S&P100 and S&P500 which are traded on the Chicago BoardOptions Exchange

� Currency Options trading on the Philadelphia exchange including Dollar-Yen calland put with have expiration dates in the nearest three months

� Futures options of Brent Crude Futures traded on the International Petroleum Ex-change (IPE)

3.5 Greeks for European Options

The Greeks describe the rate of change of the option price with respect to various marketvariables. These include the underlying stock price (delta), time (theta), rate of changeof the delta with respect to the underlying stock price (gamma), volatility (vega) and theinterest rate (rho). We will consider the Greeks for European options where the underlyingasset may yield a continuous dividend. We use the Black-Scholes model for the derivationof all the Greeks which is based upon following assumptions:

� An asset price follows a Markov stochastic process known as geometric Brownianmotion

� The short selling of securities with full use of proceeds is permitted

� There are no transaction costs or taxes. All securities are perfectly divisible

� There are no riskless arbitrage opportunities

� Security trading is continuous

� The risk-free interest rate is constant and the same for all maturities

Remark The Black - Scholes model can be extended in a number of directions by weak-ening these assumptions. In particular, we will consider the case when the asset has acontinuous yield.

26


3.5.1 Risk Management

The Greeks provide a convenient mechanism for financial institutions to monitor and con-trol the risk they are exposed to from outstanding options contracts. Options can alsobe an important tool for the hedging of risk associated with stock (or other types of)portfolios. One of the most popular techniques is known as Delta hedging which involvestaking an options position with a delta which is the negation of the portfolios delta. Thenthe collection of assets consisting of the portfolio and the options will have zero delta or adelta-neutral position. The delta function is a linear functional which mean that the deltaof a portfolio is the sum and the deltas of the individual components. In particular, if anoptions portfolio has a delta of ∆, and consists of the wi options αi, for i = 1, . . . , n, then:

∆ =n∑

i=1

wi∆i

where ∆i, is the delta of the option αi.

Once a portfolio has been made delta neutral, the next stage is to consider its gammaand by taking an off setting position try to attain gamma neutrality. In a similar way atrader may wish to hedge a portfolio against volatility changes and may taken an optionposition which create an overall vega neutral position. In practice, options traders usuallyrebalance their portfolios at least once a day to maintain delta neutrality. It is usually notfeasible to maintain gamma and vega neutrality on a regular basis due to the trading costswhich would be incurred. Typically, a trader monitors these measures, and if they get toolarge, either some of this excess is hedged away or trading is curtailed.

3.5.2 Delta

Within our component we offer methods for the calculation of the delta of a European calland put option on an asset with or without a continuous yield. These methods can notonly be applied to the calculation of the delta of options on stocks but also to options onindexes, currencies and futures. We offer methods for each of these situations.

3.5.3 Theta

The theta of a portfolio or asset is the rate of change of its value with respect to the de-crease in the time to maturity. We calculate theta in time measured in years. Usually, whentheta is quoted time is measure in days. Theta can be converted to a per day measure-ment from a per year measurement by dividend by 252 the number of trading days in a year.

We consider the theta of a stock which may or may not pay of continuous dividend. Wealso provide methods for the evaluation of the theta of a European option on currencies,indexes and futures contracts.

27


3.5.4 Gamma

The gamma of an portfolio of derivatives on an underlying asset is the rate of change ofthe portfolios delta with respect to the price of the underlying asset. In short, it is thesecond derivative of the portfolio value with respect to the asset price. Gamma is usefulfor determining the sensitivity of delta to changes in the underlying asset and hence therelative frequency in which the portfolio will need to be rebalanced in order to stay ap-proximately delta neutral.

We provide methods for calculating the gamma of options on stocks, indexes, currenciesand futures.

3.5.5 Vega

Vega is a measure of the sensitivity of the portfolio to changes in the volatility. If mayseem strange to use the Black - Scholes model to calculate vega since within this modelthe volatility is assumed to be constant. Ideally it would be better to develop a modelwhere the volatility is assumed to follow a stochastic process. However, it turns out thatthe vega calculated form a stochastic volatility model is very similar to the Black - Scholesvega so the practice of calculating vega from a model where volatility is constant worksreasonably well.

3.5.6 Rho

The Rho of a portfolio of derivatives is the rate of change of the portfolio value withrespect to the risk free interest rate. In the case of options on currencies where there aretwo interest rates there are two ‘rho’s’, one for the base currency interest rate and theother for the foreign currencies interest rate.

3.6 Implied volatility

The one parameter within the Black-Scholes pricing formulae that cannot be directly ob-served is the volatility of an asset. We showed above how the volatility can be estimatedfrom an assets historical price data. An alternative approach is to derive the volatilityof an asset from the market value of options on that given asset. The estimate for thevolatility derived by this method is referred to as the implied volatility.

Unfortunately, it is not possible to invert the Black-Scholes equations so that σ is ex-pressed as a function of S0, X, r, T and c. However an iterative search procedure can beused to find the implied σ. In our component we use Ridders method (see our componentWebCab Equation Solver for more details) in order to find the implied volatility with aprecision to six decimal places (i.e. 10e− 6).

28


Implied volatilities can be used to monitor the market’s aggregate view of the volatil-ity of a particular quoted asset. Analysts will often calculate implied volatilities fromactively traded options on a given asset and use these results to calculate the price of lessactively traded options on the same underlying asset.

It is important to note that the prices of deep-in-the-money and deep-out-of-the-moneyoptions are relatively insensitive to volatility. Therefore the implied volatility calculatedfrom these options tends to be unreliable.

29

Chapter 4

Futures Documentation

Within is chapter we detail the type and nature of the implemented models within theFutures module. We will deal with quantitative and risk management techniques withfutures and forward contracts on stocks, indexes, commodities and currencies.

4.1 Futures Contracts

A futures contract is an agreement to buy or sell an asset at a certain future time for anfixed price. Futures contracts are usually traded through an exchange with the profit orloss from the futures contract held through a broker calculated every day and the accordingcash flows paid from one party (or account) to the other.

Futures contracts have become standardized for different markets. We will consider withinthe section futures contracts on stocks, bonds, commodities, currencies and indexes.

4.1.1 Forward Contract Pay Off

A forward contract is closely related to a futures contract the main difference being thatno money changes hands between the parties until the expiry date. We provide the payofffunction which calculates the cash flow between the parties on the expiry date.

4.2 Using Futures contracts to hedge

All methods related to the use of futures contracts to hedge positions can be found withinthe bean FuturesHedgingBean.

4.2.1 Hedging a portfolio using index futures

Stock index futures can be used to hedge the risk in a well diversified stock portfolio. Sinceby the Capital Asset Pricing model we know that the relationship between the expectedreturn on a well diversified portfolio of stocks and the return on the stock market as a

30

Futures Documentation Chapter 4

whole is described by the parameter β (beta). The beta is the slope of the line of best fitwhen the excess return of the portfolio is regressed against the excess return on the marketover the risk free rate. That is, when β = 1, the returns from the portfolio tend to matchthe return from the index. If β = n ∈ (0, +∞), then the returns from the portfolio tendto be n times the return from the index.

Within this component we include methods which allow the beta of a portfolio to beestimated and the calculation of the number of index futures contracts necessary to hedgea well diversified portfolio. We also offer a method which returns the number of indexfutures contracts which need to be brought or sold in order for the β, of the portfolioconstructed portfolio to be modified to any value we choose.

4.2.2 Optimal Hedge Ratio

The optimal hedge ratio is the ratio of the size of the position taken in futures contractsto the size of the exposure in order to have a perfectly hedged portfolio. Practically itmay not be possible to perfectly hedge a physical position with futures contracts since theexposure may not be equal to an integer multiple of the contract size. A method whichcalculates the number of futures contracts which offers the best hedge is given.

4.3 Interest Bearing Investments

The evaluation of futures contract is closely related to the analysis of interest bearinginvestments. For this reason we include basic methods related to fixed interest payingdeposits with compound and continuously compounded interest.

Later we will consider more delicate interest rate models which allows the interest ratecurve to be non-constant.

4.4 Pricing of Futures Contracts

With the pricing of futures contracts it is important to distinguish between futures oninvestment assets and futures on consumption assets. This distinction is necessary be-cause the holder of consumption asset utility may depend mainly on issues completelyindependent from the actually profit and loss realized from holding the contracts. For thisreason for consumption assets a non-arbitrage argument cannot be used in order to derivea pricing methodology.

4.4.1 Assumptions underlying the pricing model

In order to construct a pricing model we need to assume that there exists some marketparticipants for which the following is true:

� These market participants are not subject to transaction costs when they trade

31


� These market participants are subject to the same tax rate on all net trading profits

� The market participants can borrow money at the same risk-free rate of interest asthey can lend money

� The market participants take advantage of arbitrage opportunities as they occur

These assumptions are not so unreasonable since their exists the set of large investmentbanks which broadly speaking satisfy these requirements. In particular, investment bankswill often have in-house arbitrage trading desks or specialists covering all the markets inwhich they have significant customer flow. Hence since these investment banks will takeadvantage of these arbitrage opportunities almost as soon as they arise means that inpractice arbitrage opportunities disappear almost as soon as they arise. An implicationof these assumptions is therefore that market prices are such that there is no arbitrageopportunities.

4.4.2 Futures and Forwards on Stocks, Bonds and Indexes

We provide the following methods for the evaluation of future contracts on stocks andbonds:

� futurePriceNoIncome - this method returns the value of a futures contract on anunderlying asset which does not pay an income

� futurePriceWithIncome - evaluates the futures price today on an asset which pays aknown income during the life of the contract. This could be a futures contract on abond or dividend paying stock.

� futuresPricesWithDividend - evaluates the future price today on an asset which hasa continuous yield.

� shortForward (longForward) - evaluates the value of an short (respectively long)forward contracts residual value

� futureOnIndex - returns the price today of a futures contract on an index

� futureOnCurrencies - returns the price today of a futures contract on currencies

� gearing - we also include a method which calculates the effective gearing of a futuresposition

� costOfCarry - we calculate the cost of carry for an investment asset

Because an exchange traded futures contract is marked to market on a daily basis it cannotaccrue a residual value.

Within an environment of constant interest rates the value of a futures contract and thevalue of a forward contract are the same. When interest rates are allowed to vary as happenin the real world these to contract will generally have different values.

32


4.5 Futures on Commodities

Futures on commodities have a number of different features. These features are related tothe fact that a holder of a futures contract of a commodity may not hold the contract forinvestment purposes. That is, certain individuals may wish to continue to hold a futurescontract (or the underlying commodity) even if there are arbitration opportunities. If thereis not a significantly large number of market participants who will arbitrate then arbitragearguments to evaluate these futures will produce misleading results.

With futures on commodities the settlement of the contract is generally in the under-lying physical asset and hence the seller of a futures should hold the physical commodityin order to be certain that they can settle the contract at expiry. Hence storage costs ofthe underlying commodity, and its availability will effect the futures prices.

We consider commodities which are held primarily for investment purposes for examplegold and commodities which are held mainly because of these consumption value for exam-ple oil. We assume that for commodities of investment type that a section of the holders(for example investment banks) of the futures contracts and underlying assets will alwaysarbitrage if the opportunity arises. We also assume that these investors have the followingproperties:

� These market participants are not subject to transaction costs when they trade

� These market participants are subject to the same tax rate on all net trading profits

� The market participants can borrow money at the same risk-free rate of interest asthey can lend money

We refer to commodities which do not satisfy these conditions as consumption commodi-ties. Though large investment banks still operate within these markets it may not bepossible to short the underlying assets and go long on a futures contract. This is becauseholders of the underlying commodity hold the asset for reasons of consumption and may bereluctant to sell the commodity and buy futures contracts because futures contracts cannotbe consumed. Alternatively, if an investment bank holds the underlying commodity theycan always sell this asset and buy futures contracts.

We will also use the two related notions of convenience yield and cost of carry. Theconvenience yield measures to markets implied benefit from holding the physical commod-ity. The convenience yield can be viewed as the yield over the risk free interest rate whichthe market is prepared of pay for the convenience of holding the physical commodity. Thecost of carry measures the storage cost plus the interest that is paid to finance the assetless the income earned on the asset.

We provide methods which return a value of a futures contract on an investment com-modity and give an inequality which the price of a future on a consumption commodity

33


must satisfy. We also provide methods for the calculation of the cost of carry and conve-nience yield for investments and consumption commodities. Further, for an consumptioncommodity we offer methods which relate the cost of carry and the convenience yield.

Remark With most commodity markets the notion of the spot price does not reallyexist because the delivery of the physical commodity always takes some time, usually anumber of weeks. Hence within our methods what we are really doing is deriving relation-ships between two futures prices. In particular, within our methods I refer to the rathervague notion of “commodity price” rather than the spot price of the commodity so thatno confusion arises and we do not give a force impression of the way in which commoditymarkets work.

4.6 Market Risk Management

Within this component we introduce market risk procedures of limit monitoring. In futurereleases we will extend this functionality to include limits check for all ‘the greeks’ but atpresent we only offer this functionality for the delta limit.

Below we detail the elements within our general approach to limit monitoring:

� Limit Table - The limits (in particular the delta limit) are stored within a databasetable and read using a query. The limit table contains the limit structure for thevarious portfolios. The limit structure for each portfolio (or book) details the mandatewhich the various trading parties have for the management of that book.

� Calculating the Portfolio Delta - Since the delta function is additive we can sumthe delta’s of a portfolios assets in order to find the delta of the portfolio.

� Monitoring the limit - a user requests the limit check through a client and theresult will be returned.

34

Chapter 5

Exotic Options Documentation

5.1 Introduction

Within this chapter we discuss firstly the definition of various exotic options and then showhow one can go about pricing and analyzing such option contracts. We cover American,Bermuda, Asian, Loopback and multi-asset options using Finite Differencing and Monte-Carlo techniques.

5.2 Types of Option Contract

An option is a contract between two parties in which one party buys the option contractwhich the other party creates (also known as writing an option contract). The option itselfis the right to obtain a pay-off as defined within the option contract at a single or rangeof future dates.

Example: The first and simplest type of options introduced is known as a European(Vanilla) Option which gives the holder the (optional) right to trade (either buy or sell)an asset at an agreed future time at an agreed price (known as the exercise price or strikeprice). The issuer of the European Option has the obligation to take the other side of thetrade (to the holder of the option) on the asset at the agreed price, when the holder decidesto exercise the option.

Options are traded on exchanges and regulated OTC markets throughout the world. Todate option contracts have been written on stocks, stock indices, currencies, debt instru-ments, commodities, futures contracts and even options on options.

5.2.1 Contracts with different Payoff Functions

Within this subsection we give three examples of types of option contracts which differonly in there payoff function.

35

Exotic Options Documentation Chapter 5

Vanilla or European Options

The payoff function on a Vanilla option is given by:

� Vanilla call option payoff: max(asset price at expiry − strike price, 0)

� Vanilla put option payoff: max(strike price− asset price at expiry, 0)

Binary or digital Options

An increasingly important type of option is the binary or digital options. These contractshave a payoff that is discontinuous in the underlying asset price.

Option strategies

Standard combinations are option contracts are traded, and are known as option strategies.Commonly used strategies include:

� Spread is an option strategy consisting of a long position and a short position.

� Bull spread is a spread where the long position has a smaller strike price than theshort position. It benefits from a rising (bull) market.

� Bear spread is a spread where the long position has a greater strike price than theshort position. It benefits from a falling (bear) market.

� Strangle is an option strategy consisting of one call and one put option.

� Straddle is a special kind of strangle, where the strike prices for the call and the putare equal.

5.2.2 Weak Path Dependence and American Options

As mentioned before an option contract can have the property that it can only be exercisedon a given date or a range of dates. Option which can only be exercised on a given dateare known as European whereas options which can be exercised on a range of dates areknown as American options. American options allow the holder the option of choosingto exercise the options early before the final expiry date.

American type options will depend on the path of the underlying asset and this dependencyis known as weak. This refers to the fact that the partial differential equation derived fromthe Black-Scholes model has the same independent variables as the corresponding Euro-pean contract. That is, there are no more variables which depend on the path taken bythe underlying asset.

36


5.2.3 Strong Path Dependence - Asian and Lookback Options

Strongly path dependent options such as Asian and Loopback options have a payoff functionwhich explicitly uses a new path dependent variable. For example the payoff in the caseof Asian options is the dependent on the average of the underlying asset over a certainperiod. In this cases the following new path dependent variable will be introduced:

I =1

T

∫ T

0

Sdτ (5.2.1)

where T is the time to expiry and τ is the time from inception. And the payoff functionwill take the following form:

payoff = P (S, I) (5.2.2)

where P is some function of the underlying asset price S and the introduced variable I.

Options with a payoff dependent on the average of the asset price are called Asian op-tions. Options where the payoff function is dependent on the maximum or minimumreached by the underlying asset price are called Lookback options.

Remark A characteristic of strongly path dependent options is that the partial dif-ferential equations resulting from the Black-Scholes model can only be solved with theintroduction of a new independent variable corresponding to a path dependent value.

5.2.4 Time dependence - Bermudan options

Another variation of an option contract is when the payoff of the contract can vary withtime. A typical example of such an option is a Bermudan option. A Bermuda optioncontract permits early exercise (as in American options) but it restricts this possibility tocertain dates or certain periods.

Such options are strongly path dependent and there payoff function will take the followingform:

payoff = P (S, I, t) (5.2.3)

where P is some function of the underlying asset price S, I is the introduced variabledepending on the path of the asset (see prior subsection) and t is the time.

5.3 The Black-Scholes Model

The payoff function is the value of the option at expiry whereas we require to know theoption value now, that is, the value before expiry. Clearly any option pricing model willneed to make assumptions concerning the future evolution of the price. The Black-Scholesmodel assumes that price evolve in accordance with the following Brownian motion knowas a lognormal random walk:

dS = µSdt + σSdX (5.3.4)

37


where dS is the ‘infinitesimal’ change in the underlying assets price, µ is the known as thedrift of the asset, dt is the time variation, σ is the volatility of the underlying asset anddX is a random variable drawn from a Normal distribution with mean zero and variance dt.

Simply knowing that the price has a lognormal evolution is not sufficient in being ableto value option contracts. In order to be able to achieve this we need to introduce afurther assumption which allow us to assign a fair value to any option contract (at leastin principle). This principle is known as the ‘principle of no arbitrage’ and said thefollowing:

In the absence of arbitrage opportunities (which is assumed to be the casewithin efficient markets), the return from a risk free portfolio must be the riskfree interest rate.

5.4 General Methods of Pricing Options in the Black-

Scholes World

5.4.1 The Black-Scholes Equation

If we assume the validity of the two principles:

� lognormal evolution

� no arbitrage

then it follows that the price evolution must obey the following partial differential equation(PDE):

∂V

∂t+

1

2σ2S2∂2V

∂S2+ rS

∂V

∂S− rV = 0, (5.4.5)

where σ is the volatility, r is the risk-free interest rate and S is the asset price.

The linear parabolic PDE (5.4.5) is known as the Black-Scholes Equation and is the basisfrom which we will price option contracts. To price an option contract involves finding thesolution of this equation for some given initial conditions.

Remark The unknown within the equation is not a value, but a function: V (S, t) whichstands for the value of the option at a time t, with the current asset price being S.

The Black-Scholes equation knows nothing about what kind of option we are valuing,whether it is a call or a put, American or Asian, nor what strike price is. These pointsare dealt with by the following final condition which with boundary conditions (see below)will ensures that we have one and only one solution to the corresponding Black-Scholesequations:

38


We must specify the option value V as a function of the underlying at theexpiry date: final(S) = V (S, 0).

This function is of course the payoff function which as mentioned above is the one thingwhich specifies many different types of option contracts.

5.4.2 Boundary and initial / final conditions

Knowing the Black-Scholes equation and the payoff function is generally not enough infor-mation to determine the price of an option contract. In order to select the unique pricingfunction we must prescribe boundary conditions and an initial or final condition of theBlack-Scholes Equation.

The boundary conditions which are required in order to select the pricing function usingthe Black-Scholes Equations will naturally be the functions which describe the (expected)behavior of the pricing function. The only problem is to select boundary conditions of thepricing function which are sufficient to uniquely determine the pricing function and yetones which we are confident will not select the ‘wrong’ function from the solution set.

Using Extreme Values to provide boundary conditions

The asset values at which the pricing function is estimated from which we are able toprovide boundary conditions are usually ‘extreme values’ with respect to the option con-tract. That is, the pricing function is estimated when the underlying asset price is eithersignificantly above the strike price (for a call option this is referred to as being deep inthe money) or is significantly below the strike price (for a call option this is referred to asbeing deep out of the money).

At ‘extreme values’ the pricing function will either be approximately zero in the caseof deep out of the money, or approximately the difference between the price and the strikecompounded at the risk free rate until maturity in the case of deep in the money. Since inthe case of deep out of the money the option is very unlikely to be exercised whereas deepin the money options are very unlikely to expiry worthless.

In particular, within financial applications it is usually possible to specify the behaviorof the pricing function (or solution) at S = 0 and as S → ∞. We must also describe theinitial conditions (i.e. when t = 0) that is the price for which the equation evolves. Ifthe final condition is required then the payoff function at expiry for differing values of theunderlying asset can be evaluated. By specifying these boundary conditions we will insurethat the Black-Scholes equation yield a unique solution which will be the pricing function.

5.4.3 Methods of solving Black-Scholes PDE

We now have a well posed PDE problem for which there exists a unique solution. Theproblem now is to find this solution.

39


The Black-Scholes PDE is a parabolic partial differential equation (also referred to asequations of heat or diffusion type). Though there exist approaches which attempt to solvethe Black-Scholes equations analytically, such as1:

� Transformation to Constant Coefficient Diffusion Equation

� Use of Green’s Functions

� Series Solution

� Fourier Transform

� Laplace Transform

For most option contracts the resulting Black-Scholes equation does not exhibit an analyticsolution. In these cases you are forced to use numerical techniques in order to find thepricing function.

The two most widely used and successful numerical approaches to finding solutions of theBlack-Scholes equations are Finite Differencing and Monte-Carlo techniques which wedescribe in the following sections.

5.5 Finite Differencing

The finite difference algorithm essentially relies on a discretization of the continuous PDE.The difference equations resulted from this process are used to generate a mesh or a gridwhich contains the discrete version of the solution. You are then able to interpolate the(discrete) solution at the grid nodes in order to find a solution over the whole region.

5.5.1 Single-Asset Options

The Explicit Algorithm

When there is only one asset involved, the Black-Scholes PDE has exactly the form pre-sented in the section above. This can be immediately translated into a finite differenceequation:

V n+1j − V n

j

∆t+ rj∆S

V n+1j+1 − V n+1

j−1

2∆S+

1

2σ2j2∆S2

V n+1j+1 − 2V n+1

j + V n+1j−1

∆S2= rV n+1

j (5.5.6)

where ∆t is the time step, ∆S is the asset price step and where V αβ ’s denote the function

values at points of the grid, where the superscripts indices α = n, n + 1, denotes the cor-responding time axis value and the subscripts β = j − 1, j, j + 1, denote the grid point onthe asset price axis.

1A detailed presentation of these methods can be found in Cranck, JC: Mathematics of Diffusion,Oxford, 1989; or Carslaw, HS & Jaeger, JC: Conduction of Heat in Solids, Oxford, 1989

40


Remark The grid in this case is bidimensional. Where one axis represents the timeand the other axis represents the underlying asset price.

We still have the final condition which we can use since we already know V time stepsj for

all 1 ≤ j ≤ asset price steps. From the equation we can immediately find the value ofV time steps−1

j for all 2 ≤ j ≤ asset price steps−1, the values V time steps−11 and V time steps−1

asset price steps

being known from the boundary conditions. In the same manner we can compute the valuesfor time step− 2, then for time step− 3 and so on, until the whole grid is evaluated.

General stability issues

The problem with the explicit algorithm approach is that it tends to amplify errors, that isit tends to be unstable. Very small and unavoidable errors caused by the limited precisionof the floating point format can become exponentially larger in subsequent iterations andcompletely compromise the results.

It can be deduced that in order to endure the stability of the explicit algorithm, thefollowing relationship between the time step and the asset price step must hold:

∆t ≤ ∆S2

2a(5.5.7)

where a is some constant.

Moreover, this relationship is tight meaning that if this inequality is not satisfied thenthe algorithm is unstable. A consequence of this relationship is that if we want to im-prove the accuracy by halving the asset step size within the grid, then we must reduce thetime step by a factor of four. Resulting in the computation time required to complete thecomputation being increased by a factor of eight. The improvement in accuracy we wouldget from such a reduction in step sizes is a factor of four since the explicit finite-differencemethod is accurate to O(∆t, ∆S2).

Remark There is also a lower bound for the asset price step, but this usually doesnot make much difference in practice unless the volatility is very small.

To conclude, the explicit algorithm is unstable if the value of ∆t is too large in relationwith the value of ∆S, and if ∆S itself is too small.

Fully implicit

The implicit algorithm which we will cover in this section solves the problem of stabilitywhich effected the explicit algorithm above. The fully implicit algorithm, uses the followingdifference equation (equivalent with the first in the sense that they both can be used to

41


represent the Black-Scholes PDE):

V n+1j − V n

j

∆t+ rj∆S

V nj+1 − V n

j−1

2∆S+

1

2σ2j2∆S2

V nj+1 − 2V n

j + V nj−1

∆S2= rV n

j (5.5.8)

using the notation defined above.

Unlike the explicit case, the solution here is not so straightforward. We cannot simplysolve one equation at each iteration, starting from the final condition to complete the grid.Here we must solve a full set of asset price steps equations, which can be computationallyintensive. But the implicit algorithm also has the advantage that it is unconditionallystable. This allows us the apply the algorithm without any restriction on the time step.For example, the asset price step can be small and the time step large without the methodrunning into stability problems.

Cranck-Nicholson

The main advantage of the explicit method (see above) is that it’s fast, but it also hasthe disadvantage that it can be unstable. In the case of the implicit method (see abovesection), its main advantage is that it is stable, but with the drawback that is can beslow. The Crank-Nicholson method is a hybrid of these two approaches and actuallymanages to combine the speed of the explicit method whilst keep the stability of theimplicit algorithm. In fact, the Cranck-Nicholson algorithm is stable and yet it is alsofaster than the fully implicit method. Key extra ingredient is in the way it takes the finitedifference approximation of the partial derivatives: which can be viewed as the averagebetween the explicit approximation and the implicit one. The finite difference equation forCranck-Nicholson is given by:

V n+1j −V n

j

∆t+ 1

2rj∆S

V n+1j+1 −V n+1

j−1

2∆S+ 1

2rj∆S

V nj+1−V n

j−1

2∆S+

+12σ2j2∆S2 V n+1

j+1 −2V n+1j +V n+1

j−1

∆S2 + 12σ2j2∆S2 V n

j+1−2V nj +V n

j−1

∆S2 = rV n+1j

(5.5.9)

using the notation defined above.

Which results in the Cranck-Nicholson method having an accuracy of O(∆t2, ∆S2). Forfurther details concerning the Crank-Nicholson method we refer the interested reader to:

Cranck, J. & Nicholson, P.: A practical method for numerical evaluationof solutions of partial differential equations of the heat conduction type. Pro-ceedings of the Cambridge Philosophical Society 43 50-67, 1947.

5.5.2 Multi-Asset Options

If the option contract involves more than one asset, then the original single asset Black-Scholes theory is modified with the use of concept of correlated lognormal random walks :

dSi = µiSidt + σiSidX (5.5.10)

42


where Si is the price of the i-th asset, 1 ≤ i ≤ n assets, µi and σi are the drift and volatilityof that asset respectively and dXi is a random number drawn from a Normal distributionwith mean 0 and variance dt. From the definition of the Normal distribution we knownthat:

E[dXi] = 0 and E[dX2i ] = dt (5.5.11)

where E is the expectation. An extra parameter (which is in fact a matrix) in the multi-asset case is the correlation matrix between the underlying assets which the option dependson.

Correlation Matrix

The correlation matrix can be constructed from the set of pairs of historical times seriesof the underlying assets. This can be expressed by stating that the random numbers dXi

and dXj are correlated. Hence:

E[dXidXj] = ρijdt (5.5.12)

where ρij is the correlation coefficient between the i-th and the j-th random walks. Thesymmetric matrix defined by the entries ρij, which represent the entry in the i-th row andj-th column is called the correlation matrix.

Black-Scholes Equation for Multi-asset options

In this case the Black-Scholes equation for multi-asset options is give by:

∂V

∂t+

1

2

n assets∑i=1

n assets∑j=1

σiσjρijSiSj∂2V

∂Si∂Sj

+n assets∑

i=1

(r −Di)Si∂V

∂Si

− rV = 0 (5.5.13)

How these equations are solved?

The numerical algorithm used to solve such an equation is a generalization of the explicitmethod presented above. The difference is that now the grid is not bidimensional butmultidimensional. So the storage space required and the computational power neededgrows correspondingly. In practice the multidimensional finite-difference algorithm cannotbe used for more than three assets. In cases with more than three assets you shoulduse instead Monte-Carlo methods which are much faster when the number of assets (i.e.dimensions) is higher than three.

5.5.3 Modifications for American Options

Finding the price of an American option, that is an option which allows early expiry, viathe Black-Scholes equations is an example of what is known as a free boundary problem.With free boundary problems we are required to solve partial differential equations wherethe value of the solution at the boundary is not fixed by a boundary condition.

43


With American options price evaluation we can assume that both the options value andits delta (∂V

∂S) are continuous with respect to the payoff function, this is the called smooth

pasting principle2. Since the smooth pasting condition is satisfied whatever pricing mech-anisms of American Option we use, it must be satisfied by the finite-differencing approach.Therefore, when applying finite differencing techniques to American options we modify theformula that generates the next line of the pricing grid in the explicit algorithm so thatit guarantees the solution will be continuous with respect to the payoff and moreover thatthe continuous delta constraint will also be satisfied and so on...

Note: American options should only be priced using finite-difference methods, sinceMonte-Carlo techniques are inappropriate for this type of option.

5.5.4 Modifications for Strongly Path Dependent Options

Since an asset’s path cannot be continuously measured, resulting option contracts whichare strongly path dependent only require measurement of path dependent quantities atdiscrete time intervals. In particular, there is a minimum time step between sampling ofpath dependent quantities such as the price.

After each time step, the path dependent value must be updated to reflect the changesin the state of the asset’s price path. The path dependent quantity is updated at eachsampling date ti and takes the value Ii for ti ≤ t ≤ ti+1, where:

Ii = F (S(ti, Ii−1, i)) (5.5.14)

This updating rule can be generalized as the new value of I, is determined by only theold value of I, the value of the underlying at the sampling date and the date itself. If weconsider for example Asian options using an arithmetic average, the updating formula willbecome:

Ii =1

iS(ti) +

i− 1

iIi−1 (5.5.15)

For max-type lookback options the updating formula will be:

Ii = max(S(ti), Ii−1) (5.5.16)

As we said in the definition of strongly path dependent options, the option value V (S, I, t);is now a function of three variables:

V (S, I, t) (5.5.17)

where S is the value in the underlying asset, I is the value of path dependent variable andt is the time.

2This principle states that the value of an American Option is maximized by an exercise strategy thatmakes the option pricing function and and its derivative with respect to the price (i.e. the option delta)continuous.

44


Remarks

1. The stochastic differential equation for I is degenerate (i.e. dI = 0) at t 6= ti forany i, because it is only updated on the discrete set of dates ti. Therefore, providedwe are not on a sampling date, the quantity I is constant and the pricing equationis simply the basic Black-Scholes equation. Though the pricing function V (S, I, t),is still a function of three variables, the I variable can be effectively treated as aparameter.

2. Since the options value across a sampling date is continuous we impose at each ti,the following condition:

V (S, Ii−1, t−i ) = V (S, Ii, t

+i ) (5.5.18)

where the left hand side of the expression represents the limit of V (S, Ii−1, t), ast approaches ti, from below; and the right hand side of the expression representsthe limit of V (S, Ii, t), as t approaches ti, from above. This condition is known asthe jump condition, and roughly saids that V cannot have discontinuities in the ‘t’direction at the grid points.

5.6 Monte Carlo

The Monte Carlo technique can be effectively and easily applied to model a large rangeof derivative contracts. The generality and easy of use results from the fact that in orderto specuify a given contract we are only require to supply the contracts payoff. Therfore,we are able applied this technique to standard exotic options contracts is means that thisapproach certainly applies

readily carries over to exotic and path dependent option contracts (e.g. Asian, Americanand Loopback Options). The Monte Carlo method applied to the pricing of an optioncontract will need to make the following steps:

� Simulate the random walk and the corresponding cash flows

� Estimate the average payoff and calculate its present value

5.6.1 Random walks

The fair value of an option in the Black-Scholes world is the present value of the expectedpayoff at expiry under a risk-neutral random walk of the underlying asset.

dS = rSdt + σSdX (5.6.19)

where r is the drift rate, S is the stock price, t is a time variable, σ is the volatility and Xis the random variable with respect to the standard normal distribution.

We can therefore write:

OptionValue = exp(−r(T − t))E[payoff(S)] (5.6.20)

45


where r is the drift rate (as before), T is the time to expiry of the option, t is the presenttime, E is the expectation with respect to the risk-neutral random walk of a given payoff(i.e. payoff(S)) being achieved at the expiry of the option contract.

Hence, we can estimate the value of an option contract by the following steps:

1. Simulate the risk-neutral random walk as discussed below, starting at today’s valueof the asset S0, over the required time horizon. This time period starts today andcontinues until the expiry of the option. This gives one realization of the underlyingprice path.

2. For this realization calculate the option payoff.

3. Perform many more such realizations over the time horizon.

4. Calculate the average payoff over all realizations.

5. Take the present value of this average which gives the option value.

The initial part of the algorithm requires first of all the generation of random numbersfrom a standardized Normal distribution. This will be discussed in the next section. Thenone has to update the asset price at each time step using these random increments.

For the lognormal random walk we have the following simple and exact time-steppingalgorithm. We write down the risk-neutral stochastic differential equation for S in theform:

d (logS) =

(r − 1

2σ2

)dt + σdX (5.6.21)

When by integrating this equation we find:

S(t) = S(0) exp

((r − 1

2σ2

)t + σ

∫ t

0

dX

)(5.6.22)

So over the time step δt, we have:

S(t + δt) = S(t) + δS = S(0) exp

((r − 1

2σ2

)δt + σ

√δtφ

)(5.6.23)

The critical issue in this approach in that we can approximate cases where the optionspayoff function depends on the historical price of the underlying asset and possibly otherparameters. This is because in such cases for a small δt, the above ‘equality’ approximatelyholds and so we can split the time interval in to small periods and generate estimates ofthe options contract price.

In the case when the option only depends on the data at expiry then the payoff func-tion will not depend on the time and other variables and the above expression will hold forall δt. In such cases we can simulate the final asset price in one giant leap to expiry, usingthe time step T . European options are such an instance and if we apply the Monte Carlomethod then we will obtain estimates which will converge to the corresponding value givenby the Black-Scholes formulae as the number of approximations is increased.

46


5.6.2 Generating normal variables

Most programming languages (including Java and C#) incorporate routines for samplingrandom numbers between zero and one. An approximate sample from a univariate stan-dardized normal distribution φ(0, 1), can be obtained using the formula:

ε =12∑i=1

Ri − 6 (5.6.24)

where the Ri are independent random numbers between zero and one where ε is the requiredsample from φ(0, 1). This approximation is satisfactory for most purposes since it has amean of zero, a standard deviation of one, and a third moment of zero.

5.6.3 Options on many underlying assets: Higher dimensions

Monte Carlo is a natural method for the pricing of European-style contracts that dependon many underlying assets. Supposing that we have an option with a payoff functionwhich depends on the prices of several underlying assets S1, S2, . . . , Sd. Instead of usingthe Black-Scholes methods which require us to solve a PDE in d+1 variables we could usethe simulation methods provided by Monte Carlo procedures. In order to use Monte Carloall we need to do is simulate:

Si(t + δt) = Si(0) exp

((r − 1

2σ2

i

)δt + σi

√δtφi

)(5.6.25)

The catch is that the φi are correlated, that is:

E[φiφj] = ρij (5.6.26)

Generating correlated random variables

Let us suppose that we can generate d uncorrelated Normally distributed variables ε1, ε2,. . . ,εd. We can use these variables to get correlated variables with the transformation

φ = Mε (5.6.27)

where φ and ε are the column vectors with φi and εi in the i-th row. The matrix M isspecial and must satisfy:

MMT = Σ (5.6.28)

with Σ being the correlation matrix.

The decomposition of the correlation matrix into the product of two matrices is not unique.One solution is the Cholesky factorization which produces a matrix M that is lowertriangular.

47


5.6.4 Advantages of Monte Carlo simulations

The Monte Carlo technique is very powerful and general. All you need to do is to simulatethe random walk and the corresponding cash flows, estimate the average payoff and takeits present value.

However this method has also disadvantages. One of them is that it is slower compared withthe finite-differencing solution of a partial differential equation. Generally speaking this istrue for problems up to three or four dimensions. When there are four or more stochasticor path dependent variables the Monte Carlo method becomes relatively more efficient. An-other disadvantage is that it is time consuming to apply this method to American options.

Because Monte Carlo simulation is based on the generation of a finite number of real-izations using series of random numbers, the value of an option derived in this way willvary each time the simulations are run. If the standard deviation in the option using asingle simulation is ε then the standard deviation of the error after N simulations is ε/

√N .

In other words to improve the accuracy by a factor of 10 we must perform 100 times asmany simulations.

5.7 Sources of Error

All numerical algorithms including the ones used here (i.e. Monte-Carlo, Finite Differenc-ing, Binomial Trees) produce by definition an approximation of the real “correct” result.In practice, we are forced to apply a numerical procedure to a class of problems where theaccuracy of the procedure used within this class will vary from case to case. Therefore,when we speak about the accuracy of an algorithm, we are actually talking about theconfidence level that we can have in an algorithm when it is applied to a class of prob-lems. For example, we could say that for a given amount of computational resources weare more confident in the accuracy of the pricing of Asian options carried out with theFinite-Differencing approach than when Monte Carlo is applied.

More precisely, when we refer to the accuracy of an algorithm it should be understoodin the following sense:

Two algorithms have the same accuracy if, having the parameters adjustedso that they run at equal speeds, produce results characterized by the sameuncertainty interval.

Thus an algorithm is characterized by the degree of confidence (or certainty) in the ap-proximations produced. That is, it can be characterized by the degree of confidence wehave in its accuracy. The accuracy which an algorithm may have can vary from very high(for example, when we apply analytical formulae), to very low (for example, for unstablefinite differencing algorithms).

The error within an algorithm is said to be controllable if we are able to eliminate (or

48


at least minimize) the error of an algorithm by carefully adjusting this parameters. Inmost instances errors are controllable, so the algorithms parameters can be adjusted inorder to produce better results.

In some cases, the interval of uncertainty for a given confidence level can be explicitlyestimated for a large class of problems (for example Monte Carlo pricing of option con-tracts). But in other cases the uncertainty interval could depend on either the parameterused or the particular problem considered (for example, in the case the finite differencingthe accuracy of the result will depend on the payoff function, or equivalently the particularoption contract considered).

Remark In many cases the speed of an algorithm is directly related to the accuracyof the algorithm. Within the Monte-Carlo and Finite Differencing as applied to optionstheory if the error of the algorithm is controllable then the accuracy of the algorithm isequivalent to the speed of the algorithm.

In the subsections below we describe in order of importance several factors related to ourimplementation of options pricing algorithms3 which can produce errors in the analysis ofderivative securities.

5.7.1 Errors determined by algorithm instability

An algorithm is said to be unstable if it amplifies any other error source, for examplefloating point errors. Iterative algorithms are the most susceptible to instability as verysmall errors can grow at an exponential rate.

Finite Differencing

In Finite Differencing algorithms this error appears when the time step is too large relativeto the price step. Instability errors are usually easily detectable as they tend to be verylarge, compared with other sources of errors. Each algorithm has its own threshold whereit becomes unstable, in the case of finite differencing this is the ratio between time andprice step. The explicit finite differencing algorithm is the most vulnerable to instability.The fully-implicit algorithm is much more robust but is not as accurate. Cranck-Nicholsonis a compromise between robustness and accuracy.

Monte Carlo and Analytic Formulae

The best general algorithm when we refer to stability is, by far, Monte Carlo which isalso the slowest. Even better is the analytical derivative pricing as applied opt the evalu-ation of European Vanilla options.

3There also exists a number of errors which can result from general computing issues such as roundingerrors.

49


Remark Within the application of Finite Differencing and Monte Carlo to options theoryit is almost always possible to eliminate instability by increasing the number of time steps.

5.7.2 Monte Carlo errors due to number of simulations used

Ideally in Monte Carlo you should perform an arbitrarily large number of simulations.Which we result in a confidence interval which is arbitrarily small. For a finite numberof simulation the confidence level will have a definite positive size. Moreover, the confi-dence level generally will be larger than the correspond confidence interval for the finitedifferencing and analytic formulae. And hence the Monte Carlo procedure is slower (orless accurate) than either finite differencing or analytic formulae.

A significant advantage of the Monte Carlo procedure is that is does admit an explicit esti-mate of the error, or equivalently the confidence interval. For a confidence level 0 ≤ c ≤ 1,the confidence interval is:

µ− erf(c)ω√N

< x < µ− erf(c)ω√N

(5.7.29)

where,

� µ - is the average of all simulation results, or the returned value of the algorithm

� ω - is the standard deviation of the simulation results

� N - is the number of simulations

� erf - the error function

See the Monte Carlo section for further detail concerning the Monte Carlo procedure.

5.7.3 Finite Differencing errors due to wrong boundary condi-tions

In order to use finite differencing techniques to price derivative contracts you must setappropriate boundary conditions. As below in the section on boundary conditions withinfinite differencing, first you should try the general boundary condition, implemented bythe SecondOrderBoundaries class. Even if this works for a large class of contracts, thereis no guarantee that it will work in every situation. In fact, it always introduces a certainerror in the final result.

Usually this error is small but there are circumstances when it can be significant. Youcan identify such an error by comparing the result of a finite differencing method withMonte Carlo (which does not require any boundary conditions, therefore is not affected bysuch an error).

50


The only way of eliminating such errors is by implementing the correct Dirichlet-typeboundary conditions for the specific option contract you are pricing.

Remark In most cases boundary errors grow when the maturity time increases, so theycan be spotted more easily by using contract with a long time until expiry, for example 5or 10 years.

5.7.4 Finite Differencing errors due to the size of the price step

Solving a PDE numerically will always mean that some approximations will be used. Inparticular, the partial derivative of a function will be replaced by an approximation of it,using differences computed over the grid considered. Ideally the number of points withinthis grid should be arbitrarily large, or equivalently the grid should be arbitrarily dense. Inreality though only a small number of points can be used due to computational restrictions.Again, comparison with Monte-Carlo can aid in identifying such errors.

Identify the step size error

In practice it can be quite difficult to discern between step size errors and errors resultingfrom the choice of boundary conditions. One difference between the two is that in manycases the former causes a shift of the prices for all maturities in one direction (while theboundary error is larger when the time to maturity increase). Hence, the algorithm willtend to underprice or overprice a given contract, no matter what maturity is used.

Controlling the Step size error

Fortunately the step size error is controllable. It can be minimized by increasing thenumber of points used to tabulate the price axis. If this number is too high comparedto the number of time steps, the algorithms can become unstable. In particular, as thenumber of price steps increase the various implementations of the finite differencing willbecame unstable in the following order: explicit, Crank-Nicholson, fully implicit. There-fore, you may have to increase the number of time steps in order to maintain an algorithmsstability.

5.7.5 Errors due to the size of the time step

This error is unlikely to generate a significant error in comparison to the stability errorswhen the finite differencing algorithms are applied. In the case of Monte Carlo which isvery robust and hence in most cases stable, this error can have a significant influence.Saying this, such an error if it where to occur can be minimized by increasing the numberof timesteps.

51


5.8 Greeks of Exotic Options

Recall that the Greeks describe the rate of change of an option’s price with respect tovarious market variables. The Greeks can also be thought of as corresponding to variouscoefficients of the Taylor expansion of the price function with regard to the various marketvariables which it depends on. In short, the Greeks measure the sensitivity of an option(or portfolio of options) to various market variables in the following ways:

� Delta (∆) - The rate of change of the option price to changes in the underlying assetprice.

� Theta (Θ) - The rate of change of the option price to changes in the time remaininguntil the expiry of the option.

� Gamma (Γ) - The rate of change of the option delta, or equivalently the rate ofchange of the rate of change of the option price.

� Vega - The rate of change of the option price to changes in the volatility. Naturally,Vega will be measured with respect to the measure used within the option modelunder consideration.

� Rho - The rate of change of the option price to changes in the interest rates, inparticular the risk free interest rate.

The definition of the Greeks in the case of Vanilla Options which where treated earlier andExotic Options is identical. The differences lie in the way in which the Greeks in thesetwo cases can be evaluated. In the case of Vanilla options via the Black-Scholes modelwe are able to derive analytic formulae for the price function and the Greeks (i.e. thederivative of the price function). In the case of Exotic options since the Black-Scholesmodel does not exhibit an analytic solution we are forced to use numerical procedures inorder to estimate the price function and its corresponding derivatives (a.k.a. the Greeks).Within the previous sections to have discussed how the price function in accordance withthe Black-Scholes model may be evaluated at a given point using one of the followinggeneric approaches:

� Finite Differencing Techniques

� Monte-Carlo

Each of these pricing mechanisms can be used to estimate the Greeks of an Exotic Op-tion and the correspond values given for the Greeks may naturally differ. In the followingsections we detail how we may estimate the value of the Greeks using these pricing mech-anisms.

52


5.8.1 Finding Greeks of Exotic Options using Monte-Carlo

Evaluating one of the Greeks (excluding Gamma) is the equivalent to evaluating the deriva-tive of the price function which respect to one of its variables. In the case of the Delta thisvariable is the underlying asset price, for vega the variable is the volatility and so on... Inorder to evaluate a given Greek which depends on the rate of change with respect to thevariable η (say), at a given point in time t = T , we evaluate the price function:

f(T, η, . . .),

using Monte-Carlo approximation at the point t = T , η = η(T ), where . . . corresponds tothe other variables. We also evaluate the price function at the same point in time but wherethe η variable has been perturbed. That is, we set η = η(T )+, where ε is a small positivenumber of modulus δη, and evaluate the function f(T, η + ε, . . .), using the Monte-Carloapproach. Then ‘the Greek’ with represents the rate of change with respect to the variableη, can be estimate by:

f(T, η(T ), . . .)− f(T, η(T ) + ε, . . .)

δη

Remarks

� If in the above procedure η, is taken to be the underlying asset price then we willevaluate the Delta of the option, if η is taken to be the volatility then we will evaluateVega, and so on...

� In order to minimize standard errors the number of trials used for the evaluation ofthe price function and its perturbation should be the same.

Evaluating the Gamma using Monte-Carlo

In order to evaluate the Gamma of an option using Monte-Carlo, you will need to evaluatethe Delta using the above procedure at the evaluation point (i.e. ∆(T, α(T ), . . .)), and foranother point where the underlying asset’s price has been perturbed (i.e. ∆(T, α(T )+ε, . . .).Then Gamma at the point (T, α(T ), . . .), is given by:

∆(T, α(T ), . . .)− f(T, α(T ) + ε, . . .)

δx

where δx is the modulus of the perturbation ε.

5.9 Employee Options

Within the Tree module we offer the pricing of employee options in accordance with theEnhanced FASB 123 model. That is, we provide a binomial and trinomial trees basedpricing engine for the evaluation of employee options in accordance with the EnhancedFASB 123 model as detailed within the paper, ’How to value Employee Stock Options’, byJohn Hull and Alan White (September 2002). This fair-based approach is in accordance

53


with the advice laid out within the publication, ’Accounting for Stock Based Compensa-tion’ (October 1995), which first details the FASB 123 model. For a formal statementon the FASB 123 Accounting Standard we refer the reader to Summary of StatementNo. 123 (revised 2004), Financial Accounting Standards Board which is available athttp://www.fasb.org/st/summary/stsum123r.shtml.

5.9.1 Details and Assumptions of the Enhanced FASB 123 Model

Employee stock options are issued to employees of a company of the stock of that company.Therefore, these options can be viewed as a component of renumeration and hence it isbecoming increasing accepted that these options should be reflected on a companies in-come statement. However, due to the special features of these options (as described below)standard pricing models as applied to traded products cannot be applied in this case. Herewe provide a custom binomial and trinomial trees pricing engine based as suggested withinthe article of Hull and White which presents a theoretically sound approach to the pricingof such options.

The FASB 123 model takes into account the following special features of an employeeStock Option:

� Non-traded: The employee option cannot be traded and moreover can only beexercised during the period of employment.

� Vesting Period: Often the option will stipulate a period before which it can beexercise. If the employee leaves the company before the end of the vesting periodthen the options for forfeited. If the employee leaves after the vesting period thenthe option are exercised if they are in the money, otherwise they are forfeited.

� Dilution: When the option are exercised they are settled with shares held in Trea-sury, hence new shares are issued and dilution of the share capital takes place.

The Enhanced FASB 123 model dealt with differs from the basic FASB 123 model inthat:

� Employee Exit Rate: Explicitly includes to possibility that the employee leave thecompany during or after the vesting period. This allows the company to use actualemployee turnover rates with the pricing model.

� Early Exercise Policy: Allows the employee in incorporate an pre-determinedpolicy towards to early exercise of the options. That is, it allows the employee tospecify the level as a multiple of the exercise price which the underlying stock mustreach when the employee will exercise the option.

5.9.2 Brenchmark Results

Here we compare the results which can be found using our implementation of the Hull/Whitemodel (2004) with the results which can be those found using John Hull’s implementation

54


which can be downloaded from http://www.rotman.utoronto.ca/ hull/esops/. The sourcecode for these examples are provided as a QA example which can be found within the/client directory of the installation directory.

Key for the Results Table

� pr. = Stock Price

� ex. = Execise Price

� life = Total Life

� time = Time to Vest

� pre = Employee Exit Rate pre-vesting

� post = Employee Exit Rate post-vesting

� multi = Exercise Multiple

� vol = Expected Volatility

� rate = Risk-free rate

� yield = Dividend yield

� WC Bin = WebCab Binomial model results

� WC Tri = WebCab Trinomial model results

Selection of Benchmark Results

In the following table we provide the results from four examples corresponding to each ofthe four rows. Within each row we define an Employee Option pricing problem and providethe results of the Employee Option Evaluation in accordance with the FASB 123 modelusing our Binomial and Trinomial implementations and the implementation of John Hull.

pr. ex. life time pre post multi vol rate yield WC Bin WC Tri Hull50 50 10 5 5% 5% 1.0 30% 7.5% 2.5% 12.35 12.27 12.2350 50 10 3 6% 6% 1.0 20% 7.5% 2.5% 8.116 8.0597 8.0312 12 4 2 4% 4% 1.9 35% 10% 12% 1.9675 1.9603 1.9614 15 15 10 6% 6% 2 20% 8% 3% 2.6981 2.654 2.65

Conclusions: As you can see from the table above the results using our implementationare almost exactly the same as the results which are returned by John Hull’s implementa-tion.

55


5.10 Scenario Analysis

Scenario analysis allows for an asset (or portfolio of assets) to be stressed and for the result-ing behavior to be analyzed. Such analysis is necessary within a Greek/VaR based marketrisk methodology to capture the risks due to outsized market moves. Though the standardGreek/VAR4 methodology is adequate for the majority of market dynamics it generallywill fail to reflect market risks due to shocks such as major geopolitical elements or marketcrashes. Examples of outsized market moves include the October 1987 stock market crashor the swings in the Treasury bond market in 1998 after the Russian government effectivelydefaulted on its national debt.

Applications to Risk Management and Trading

The major reason why the Greek/VaR methodology is insufficient lies in the fact thatit under estimates the probability of outsized market moves. In theory such major out-sized moves (for example of 3 standard deviation move in one day) will occur a few timesevery thousand years but in practice such outsized market moves have been observed totake place every ten years or so. That is, the historical distribution of assets prices has“fatter” tails than the tail implied from the normal distribution of asset prices which isone of the assumptions in the Black-Scholes model.

Though Scenario Analysis forms an important ingredient within most risk frameworksit is also a useful trading tool. Whether you wish to flatten out the exposure of a portfolioor take directional positions with particular characteristics a scenario grid representationwill quickly communicate the directional exposure of the portfolio with respect to the mar-ket variables being considered. Moreover, if you wish to analyze the particular risk/rewardprofile of a particular trade before entering the position you can carrying out ScenarioTesting on a number of scenario which you anticipate occurring. It this way you will knowa prior the profit and loss implications of various differing scenario playing out. In thisway you are will be able to construct an optimal trading approach according from yourinterpretation of the possible scenarios and there estimated probabilities.

What we will cover

Within this section we will consider the following two approaches to Scenario Analysis:

� Scenario Grid - The Profit/Loss of a portfolio after various shifts of two marketvariables from there present values. This gives a complete picture of the implicationsin terms of valuation (and hence profit and loss) of various market scenarios takingplace.

4The Value at Risk (or VaR) is a framework for producing a global risk parameter of a portfolio ofassets. In particular, the n-day m% VaR of a portfolio of assets is the maximum expected lose with m% ofconfidence over a period of n days. The 5-day 95% VaR is the greatest loss expected over a 5-day periodwhen the worst 5% of cases are excluded.

56


� Scenario Testing - The Profit or Loss resulting from the a one off shift of all themarket variables. Using this type of analysis you can analyze the effect on a portfolioif it underwent a similar major market shift to one which occurred in the past.

Remarks

� The VaR measure only captures information concerning the 99% (or 95%) leastvolatile days (at least in terms of the profit and loss). Hence, the VaR metric does nottake into account the days which result in the most volatile portfolio value swings.

� The Greeks can be viewed as the leading coefficients of the Taylor expansion withrespect to the market variables (price, interest rates, volatility, time etc) of the pricingfunction of the underlying asset. For small shifts in the market variables the leadingterms of the Taylor expansion will offer a good approximation to the pricing functionitself shifted. But as the shifts become larger to lower order terms will become lessinsignificant and sum of the leading terms of the Taylor expansion (i.e. the Greeks)will diverge from the pricing function itself. On the other hand, scenario analysiscan cope equally well with large shifts in the underlying market variables since thepricing function (i.e. the entire Taylor expansion) is re-evaluated after the shift inthe market variables has taken place.

5.10.1 Scenario Grids

A Scenario Grid with respect to two market variables either displayed as a grid of numericalvalues, or as a surface plot representing the values of a portfolio (or the resulting profit orloss) after each (scenario) shift, offers a quick and effective means to assess the type anddegree of risk which a portfolio of assets is carrying.

Evaluation of the Absolute Scenario Grid

A scenario grid is a grid of numerical values, say with α × β elements where the (a, b)entry is defined to represent the market value of the portfolio evaluated with the referencemarket variables. This value in practice is usually taken to be today’s portfolio and marketvariables values.

Remark If we are considering the profit and loss resulting from various market movesthen the value at a reference point (a, b), will be zero.

The remaining points of the scenario grid are populated in the following fashion. Once thetwo market variables which are to be shifted and the degree to which each of these shiftswill be (including whether the shift is a percentage or an absolute value) is decided theremaining scenario grid members can be evaluated as follow. The (x, y) element which isp, shifts in the first variable and q, shifts in the second variable is given by:

price(x + qs, y + pf)

57


where s (respectively f) are the number of shifts in the first (respectively second) marketvariable and price represents the re-evaluation of the portfolio after the shifts to the twomarket variables whilst keeping the other market variables fixed. That is, the scenariogrid will display the absolute value of the portfolio under various shifts of the two mar-ket variables with respect to a reference value associated with a reference market condition.

Example of Absolute Scenario Grid

Below we give an example of a absolute Scenario grid where the initial value of the port-folio is 256, 488, as stated in the grid element D4. The portfolio consider is made up ofassets which depend on the price of the precious metal gold. The top axis represents corre-sponding shifts of the volatility of the underlying asset gold and the axis on the right handside represent changes in the underlying price of gold. As you can see below the volatilityand market price is shifted between −2 and +2, and the corresponding value of the goldportfolio is evaluated and the grid point is populated.

Fig. The ‘Volatility vs Underlying’ Absolute Scenario Grid of the Gold Portfolio

Evaluation of Relative (or P/L Change) Scenario Grid

In the case of the relative (or P/L Change) scenario grid, where we consider the profitand loss implications of various market moves the scenario grid can be evaluated by justsubtracting the value of the reference market value from the other values associated withvarious shifts in the market variables. That is, in the notion used above the (x, y) elementwithin the relative (or P/L change) scenario grid is given by:

price(x + qs, y + pf)−R

where R is the reference market value of the portfolio being considered. In the goldportfolio example considered above the reference market value of 256, 488 (see grid elementD4 above).

5.10.2 Scenario Testing

Scenario Testing (also know as back testing) is another technique which allows the portfolioto be put under various stresses and to measure the implications in terms of the portfoliosprofit and loss. Scenario Testing is generally applied in two instances:

58


� Trading Tool - Test a trading idea against various future scenarios.

� Risk Management (Back Testing) - Stress a portfolio according to past (extreme)market dynamics.

Mechanics of Scenario Testing

Whether you intend to use Scenario Testing as a trade or risk management tool to ba-sic mechanics of its use are the same. The general procedure is to re-evaluate an asset (orportfolio) under a shift of all the market variables which the asset (or portfolio) dependson. For an asset this will involve performing the following steps:

� Identify the market variables which an asset depends. Since the Scenario Analysisdepends on a pricing model this will involve going back to the pricing models beingused for the given asset and identifying the models market variables.

� Shift the market variables according to the market scenario which you wish to analyze.

� Re-evaluate the asset according to the shifted market variables using the same model.

In order to undertake Scenario Testing of a Portfolio, we should perform to following:

� Identify all the market variables which the Portfolio is exposed to. Will we involveidentifying the variables involved in the pricing models of the assets within the port-folio.

� Shift the market variables according to the market scenario which you wish to analyze.

� Re-evaluate the assets of the portfolio according to the shifted market variables.

By re-evaluating the asset (or portfolio) after a shift in the market variables has takenplace we can see the effect on the value of an asset (or portfolio) which a given supposedmarket dynamics will have on the assets (or portfolios) value.

Using Scenario Testing as a Trading Tool

Once a trading idea has been identified and the possible future scenarios classified, thevarious ways in which to express a trading idea can be analyzed against the various futurescenarios considered. By analyzing the possible scenarios against the original trading ideawill help in assessing where to put stops and how to adjust the trading strategy as thetrade evolves.

For example, say you take a directional position on the underlying asset price througha trading approach which hedges most of the volatility and interest rate risk at the pointwhen the trade is entered. Further, you decide that you ideally do not wish to be exposedto excessive interest rate or volatility risk. Now, one of the envisaged scenarios plays outand from your a prior analysis you know that your exposure to volatility will grow larger

59


than you feel happy with. At this point you hedge the volatility according to a pre-decidedstrategy, which you analyzed apriori within your original scenario analysis before enteringthe trade. Hence, through Scenario Testing you are able to build a robust trading approachwhich can manage the plan the whole trade life cycle under various scenarios.

Using Scenario (or Back) Testing within a Risk Management Framework

The application of Scenario (or Back) Testing within a VaR/Greek risk methodology isparticularly important since extreme market moves (i.e. the worst 1of 99stock marketcrash of October 1987, taken place significantly more often than would be expected fromthe lognormal distribution of asset prices.

Scenario Testing within a risk management framework involves the following steps:

� Observe the market variables which a given portfolio being considered is exposed to.

� Record the historical market events for which the moves in the market variableswhich the portfolio under consideration is exposed to where particularly large.

� Re-evaluate the portfolio as if the extreme market variable shifts which occurred inthe past happened to the present value of the market variables.

By performing the above procedure the effect that an extreme historical market movewould have on the considered portfolio if that market move would re-occur. In this wayyou can ascertain to what degree a given portfolio is “hedged” against extreme marketmoves. Since in times of market turmoil liquidity often dries up, and hence the hedging ofrisk during extreme market moves is usually impossible.

60

Chapter 6

Programmer’s Guide for Options andFutures Module

This chapter provides technical documentation for developers implementing the WebCab Op-tions and Futures J2EE Application. Its purpose is to enable an efficient exploitation of allmethods and related features of this Applications functionality.

6.1 Options Module

6.1.1 Functionality

The Options module consists of the following 11 EJB components:

1. EuropeanEvaluation - evaluates European call and put options on stocks, indexes,currencies and futures using the Black-Scholes formulae

2. EuropeanDelta - calculates the delta of European options on stocks, indexes, curren-cies and futures

3. EuropeanGamma - calculates the gamma of European options on stocks, indexes,currencies and futures

4. EuropeanTheta - calculates the theta of European options on stocks, indexes, cur-rencies and futures

5. EuropeanVega - calculates the vega of European options on stocks, indexes, currenciesand futures

6. EuropeanRho - calculates the rho of European options on stocks, indexes, currenciesand futures

7. OptionStrategies - considers the payoff functions of different option trading strategies,in particular for spreads and combinations

8. BinaryOptions - considers the Binary (or digital) options

61

Programmer’s Guide for Options and Futures Module Chapter 6

9. PutCallParity - within this component we implement put-call parity relations forVanilla and Binary Options where the underlying asset does not pay dividends andfor Vanilla options where the underlying asset pays a continuous dividend

10. Volatility - consists of a collection of methods for estimating the value of the volatilityfrom historical data using direct calculation, ARCH, EWMA and GARCH models

11. ImpliedVolatility - calculates the implied volatility for call and put options for Black-Scholes formulae

6.1.2 Methods and parameters description

Each method is generally given in three forms depending on whether a RDBMS is used tostore the results or retrieve the input data. We also provide the same functionality withinmethods which do not use JDBC for uses who are only working with relatively few op-tions contracts. In many instances the developer will need to create systems which handlethousands and even tens of thousands of option contracts. The use of RDBMS and henceJDBC greatly simplifies the complexity of the systems which are being created.

We included within our components methods that may be used to extract the source datadirectly from database tables and store the results back into the RDBMS. By browsingour JavaDocs documentation you will see that usually there are groups of three methodswith the same name but different parameters. We give below a brief description for eachof these types of methods which vary in the way that they get input data and store theresults.

� Methods with numbers as parameters These methods take as parameters theasset price, strike, volatility etc., directly as numbers (generally as doubles), computethe results and return a value.

Example: double callDeltaOnIndex(double yield, double indexValue,

double strike, double riskFreeInterestRate,

double volatility, double timeToMaturity)

� Methods with strings as parameters and return values These methods takeSQL standard queries as parameters in string format, extract the data from a database(usually more than one row) and compute the corresponding results which are re-turned as an array. The user of these methods must be careful that all the queriesreturn the same number of values. The number of values returned will be specifiedin the last parameter of these methods: n.

Example: double[] callDeltaOnIndex(String yield query,

String index value query, String strike query,

String interest rate query,String volatility query,

String maturity query, int n)

62


� Methods with strings as parameters and no return values If the results mustbe stored in a database table we should use the method with the same name asprevious used but with a few more parameters:

– result table

– result column

– id column

– start position

The methods that have these parameters do not return the results as an array. Theystore the results in the column result column from table result table in the rowscorresponding to id column = start position + i, with i an integer from 0 to n

(the number of rows your queries return).

Example: void callDeltaOnIndex(String yield query,String index query,

String strike query, String interest rate query,

String volatility query, String maturity query,

int n, String result table, String result column,

String id column, int start position)

Note For further details see the information provided within the JavaDocs documentation.

Remark To use the methods that work with databases the component needs to con-nect to a database via JDBC. This can be done either by the creation of the EJB or usingthe methods loadDriver(String) and changeConnection(String).

1. loadDriver instantiates a JDBC driver class. For example, for the Oracle databasewe have “oracle.driver.OracleDriver” which is needed by Java to connect to a database.

2. changeConnection closes any opened connection and opens a new connection whenprovided with a URL. For example:

jdbc:oracle:thin:@webcab.co.uk:portNumber:databaseName

6.2 Client-Side Implementation

6.2.1 Client Structure

The EJB architecture formalizes how EJB clients obtain and affect remote references fromthe server. Client access to EJB objects consists of the following steps:

1. Obtaining an initial naming context

2. Looking up an EJB Home from the initial context

3. Using the home interface (creating or removing EJB components)

4. Manipulating EJB references

63


6.2.2 A Client Example

The source code below is an example of an EJB client:

import com.webcab.ejb.finance.futures.*;

import java.util.Properties;

64


import javax.ejb.*;

import javax.naming.*;

public class EJBClient{

/ *

*Obtain the JNDI configuration

*/

Properties prop = System.getProperties();

public static void main(String[] args){

try{/*

* Obtaining the initial context

*/

InitialContext initial = new InitialContext(prop);

/*

*Looking up the home interface

*/

Object obj = initial.lookup(

"com/webcab/ejb/finance/futures/EuropeanDelta");

/*

*Casting the home interface according to the RMI-IIOP

standards

*/

EuropeanDeltaHome home = (EuropeanDeltaHome)

PortableRemoteObject.narrow(obj,EuropeanDeltaHome.class);

/*

*Creating the component

*/

EuropeanDelta ed = home.create();

/*

*Using the component

*/

System.out.println("delta ="+ed.callDelta(21,20,0.1,0.2,0.25));

/*

*Removing the component

*/

ed.remove();

}catch(Exception e){}}

65


The JNDI configuration used by the InitialContext may be specified in a file namedjndi.properties. The file should be placed in one of the locations enumerated in thejava.classpath environment variable. Following is an example of a jndi.properties file usedto connect to an Application Server running inside the IBM WebSphere Application Server4.0. For more details regarding Java Naming and Directory InterfaceTM specifications,please consult the related Sun documentation.

# IBM WebSphere Application Server 4.0 JNDI properties

java.naming.factory.initial=com.ibm.websphere.naming.

WsnInitialContextFactory

java.naming.provider.url=iiop://localhost:900/

6.2.3 The create() Methods

As the component has methods that use RDBMS and methods that do not use databasesthere are three ways to initialize the component.

� create() instantiates the component without JDBC connections. 1

� create(String, String) instantiates the component with the specified databaseconnection and the specified JDBC driver.

6.3 Futures Module

6.3.1 Functionality

The Futures module consists of the following six EJB components:

1. DailyReporting - we consider methods related to the daily reporting and managementof a futures trading account. This includes margin requirements, daily P&L, totalequity and excess margin.

2. Forwards - we consider evaluation of forward contracts between two parties.

3. FuturesEvaluation - we consider evaluation of future contracts on stocks, bonds andindexes.

4. FuturesHedging - we consider the use the futures contracts for the hedging of riskswithin stock, commodity, bonds and currency markets.

5. FuturesOnCommodities - we consider the modeling of futures contracts on investmentand consumption commodities.

1 Even if you used this method to create the component you can still connect to a database usingloadDriver and changeConnection methods.

66


6. Interest - we consider basic methods for the evaluation of interest bearing investments.

6.4 Client-Side Implementation

6.4.1 Client Structure

The EJB architecture formalizes how EJB clients obtain and affect remote references fromthe server. Client access to EJB objects consists of the following steps:

1. Obtaining an initial naming context

2. Looking up an EJB Home from the initial context

3. Using the home interface (creating or removing EJB components)

4. Manipulating EJB references

6.4.2 A Client Example

The source code below is an example of an EJB client:

import com.webcab.ejb.finance.futures.*;

import java.util.Properties;

import javax.ejb.*;

import javax.naming.*;

public class EJBClient{

/ *

*Obtain the JNDI configuration

*/

Properties prop = System.getProperties();

public static void main(String[] args){

try{

/ *

* Obtaining the initial context

*/

InitialContext initial = new InitialContext(prop);

/ *

*Looking up the home interface

*/

Object obj = initial.lookup(

"com/webcab/ejb/finance/futures/Interest");

67


/ *

*Casting the home interface according to the RMI-IIOP

standards

*/

EuropeanDeltaHome home = (InterestHome)

PortableRemoteObject.narrow(obj,InterestHome.class);

/ *

*Creating the component

*/

Interest i = home.create();

/ *

*Using the component

*/

System.out.println("interest ="+i.interestCompoundToContinuous

(0.1,2));

/ *

*Removing the component

*/

i.remove();

}catch(Exception e){}}

The JNDI configuration used by the InitialContext may be specified in a file namedjndi.properties. The file should be placed in one of the locations enumerated in thejava.classpath environment variable. Following is an example of a jndi.properties file usedto connect to an Application Server running inside the IBM WebSphere Application Server4.0. For more details regarding Java Naming and Directory InterfaceTM specifications,please consult the related Sun documentation.

# IBM WebSphere Application Server 4.0 JNDI properties

java.naming.factory.initial=com.ibm.websphere.naming.

WsnInitialContextFactory


68


6.4.3 The create() Methods

As the component has methods that use RDBMS and methods that do not use databasesthere are three ways to initialize the component.

� create() instantiates the component without JDBC connections. 2

� create(String, String) instantiates the component with the specified databaseconnection and the specified JDBC driver.

2 Even if you used this method to create the component you can still connect to a database usingloadDriver and changeConnection methods.

69

Chapter 7

Programmer’s Guide for the ExoticOptions Module

This chapter provides technical documentation for developers implementing the Exotic Optionsmodule of the WebCab Options and Future J2EE Application. Its purpose is to enable anefficient exploitation of all methods and related features on this Application.

7.1 Introducing the Exotic Options Module

The Exotic Options module within the WebCab Options and Futures J2EE Applicationprovides methods for the evaluation of exotic options. In particular, this module is able toeffectively evaluated multi-asset European options, American options, Lookback Options,Asian Options and Bermuda Options. These options are priced according the Black-Scholes-Merton formulation using Monte-Carlo and finite difference techniques.

7.2 Client-Side Implementation Procedure

In order to create a Java application that applies the option pricing procedures containedwithin our component you will need to instantiate the home interface. Please note thatyou will not acquire access to the bean class itself but only to its home and remote inter-faces. The following source code provides a standard way of opening a connection to anEnterprise JavaBeansTM Server and requesting an instance of the home interface. Homeobjects are RMI-IIOP objects, and so they must be cast into RMI-IIOP objects using thePortableRemoteObject class:

70

Programmer’s Guide for the Exotic Options Module Chapter 7

import javax.naming.InitialContext;

import javax.rmi.PortableRemoteObject;

import com.webcab.ejb.finance.options.exotic.*;

try {/** Obtain the JNDI initial context.*/InitialContext context = new InitialContext ();

/** Obtain reference to the home object*/Object object = context.lookup (

"com/webcab/ejb/finance/options/exotic/FiniteDifference");

/** FiniteDifferenceHome is the home interface of our component* and requires to be cast according to RMI-IIOP standards.*/FiniteDifferenceHome home = (FiniteDifferenceHome)

PortableRemoteObject.narrow(object, FiniteDifferenceHome.class);

}catch (Exception e) {}

The JNDI configuration used by the InitialContext may be specified inside a file namedjndi.properties. This file should be placed in one of the locations enumerated by thejava.classpath environment variable. Following is an example of a jndi.properties

file, used to connect to an Application Server running inside the IBM WebSphere Applica-tion Server V4.0. For more details regarding the Java Naming and Directory InterfaceTM

(JNDITM ) specifications, please consult the related Sun documentation.

# IBM WebSphere 4.0 Application Server JNDI propertiesjava.naming.factory.initial=

com.ibm.websphere.naming.WsnInitialContextFactory


The home object can obtain through another remote call an instance of the remote in-terface, which will offer access to all business methods defined by the bean class.

71


7.3 Specifying Contract Details

7.3.1 Payoff Function

As seen in the mathematical documentation, the most important thing that differentiatesoption contracts is the payoff function. In the most general form, a strongly path-dependentoption has a payoff function of the following form:

payoff = P (S, I, t) (7.3.1)

where S is the price, I is a path dependent value and t is the time. In the case where thepayoff function depends on more than one asset the variables S and I, will become vectors.

Examples: In the case of both Asian and Loopback options the values given for S (seebelow), will correspond to the market price of the underlying asset at some time T , onwhich the option is defined. The path dependent variables will depend on the way in whichthe option is defined. In particular, for Asian and Loopback option we have:

� Asian - I = ‘Average of the price over a specified period evaluated at a given pointin time’

� Loopback - I = ‘Maximum of the price over a specified period evaluated at a givenpoint in time’

The Payoff function Interface

Before calling any pricing methods you must first set the payoff function. In order to dothis you must implement the PayoffFunction interface. This interface contains the method:

getValueAt(double t, double[] x, double[] path dependent values, int n)

The method getV alueAt implemented by you, must return the value of the payoff function,given the vector of current asset prices (x) and the vector of path dependent values; t is thecurrent time and n is the total number of assets. Both vectors have n elements. We includewith our product implementations of the PayoffFunction interface for some common typesof options. The following is a list of option types for which a payoff function is suppliedtogether with the name of the class. We also include the JavaTM sources for these classes.

� Options with only one asset

– Simple, vanilla options - SimplePayoff

– Binary options - BinaryPayoff

– Standard strongly path dependent options - StronglyPathDependentPayoff

� Multi-asset options

– Spread strategies - SpreadStrategyPayoff

72


– Strangle strategies - StrangleStrategyPayoff

– Straddle strategies - StraddleStrategyPayoff

7.3.2 Boundary conditions

Boundary conditions are required only when using finite differencing methods, namely theFiniteDifference bean. They can become quite complex if used for multi-asset optionsand even for single-asset they are rather tricky to set in order to express the true financialbehavior of option values. The most common types of boundary conditions are:

� Dirichlet conditions - you supply the value of the function on the boundary.

� Neumann conditions - you supply the first derivative of the function on the boundary.

We give the user the choice of supplying its own boundary condition of Dirichlet type. Theinterface DirichletBoundaries was designed for this purpose. It contains the method:

getValueAt(double t, int i, boolean i max, double[] not fixed x, int m)

The question is how this method should be implemented. Think, for example, that wehave a one-asset option to be priced. In this case the PDE will have two variables: t(time) and S (price). The final condition is clearly a function of one variable: S. Theboundary condition is more complex. Boundaries are always supplied in pairs. We have alimit for low values and another limit for high values. This is due to the fact that thereis no preferred direction on the price axis (unlike the time axis). So that’s the utility ofthe i max parameter. If i max is true then the method must return the value from theboundary with the highest price. If it is false the method will return the value from thelowest price boundary. Each boundary is a function of time.

Now, if the option is multi-asset, things get complicated even more. Here you will seethe meaning of the last two unexplained parameters: i and not fixed x. Suppose we havea three-asset option. There will be then three pairs of boundaries, each corresponding toone of the asset prices. But here is the big difference: the boundaries are no more functionsof time, but are now functions of time and the two remaining asset prices. So we fix oneasset price on its highest or lowest value and we must supply the option value at any timeand for any combination of the other two asset prices. Parameter i indicates the asset withfixed price (counting begins from 0). Parameter not fixed x is a vector of m− 1 elements- the prices of the remaining assets. t is, of course, the time and m is the total number ofassets.

The interface DirichletBoundaries extends a more general interface, Boundaries, whichhas only one method: int type(). This method informs the algorithm about the boundarytype. In the current implementation only Dirichlet boundaries can be supplied by the user,so, when implementing the DirichletBoundaries interface, the method type must return thepredefined constant BT DIRICHLET. To avoid the task of always writing this method, an

73


abstract class, named Dirichlet, which provides type and leaves getValueAt unimplemented,was included. You simply have to extend this class instead of implementing the interface.

The class SimpleBoundaries which extends Dirichlet can be used for (single) asset vanillaput and call options. A JavaTM source file is also given.

There is another class, SecondOrderBoundaries, included in the package. This is no longera Dirichlet boundary. The following assumptions are made:

� At S = 0 (the low boundary), for most contracts (including calls and puts) the diffu-sion and drift terms switch off. This means that on S = 0 the payoff is guaranteed,resulting in the condition:

∂V

∂t(0, t)− rV (0, t) = 0 (7.3.2)

� At S → ∞ (the high boundary), the payoff is at most linear in the underlying, sothe condition is:

∂2V

∂S2(S, t) → 0 as S →∞ (7.3.3)

The advantage of SecondOrderBoundary is that it works well with a broad range of op-tions. It is therefore a good starting point if you find it hard to supply a correct Dirichletboundary.

7.4 Class Delivery Procedures

There are two alternatives for a client to solve an option pricing problem on the server, bychoosing to pass local or remote parameters. When delivered locally, the payoff functionand the boundaries are accessed in the same virtual machine where the EJB Server is run-ning. This means that all business methods take place inside the server’s Virtual Machine.

A remote delivery allows the bean running on the server to access objects that exist in theclient-side Java Virtual Machine.

7.4.1 Remote Delivery

In case the function you wish to supply requires client-side specific resources, in order tomake them available to the component running on the server you will use an RMI (Re-mote Method Invocation) type of implementation. If you are not familiar with the RMItechnology, you may wish to go through Sun’s Java 2 Standard Edition tutorial or readthe related API specifications.

There are several steps you will follow in order to make your resource remotely available.First, define your class by implementing the corresponding interface - PayoffFunction

74


or DirichletBoundary. You will then extend the UnicastRemoteObject class, and thusmaking sure that all protocol related functions are being taken care of. We also provide apossibility of using a client-defined protocol implementation for the remote active objectsmodel, in case your application requires such a special treatment. Finally, you will createa Registry or use an existing one and bind an identification name to the remote functioninstance. These steps follow the standard RMI implementation procedure and can be eas-ily applied inside any Java application.

Following is a Java source code that exemplifies the above development process:

public class MyPayoff extends UnicastRemoteObject implements

PayoffFunction {

static int count = 0;

double strike price;

public MyPayoff(double strike price) throws RemoteException {this.strike price = strike price;

}public double getValueAt(double t, double[] x,

double[] path dependent values,int n) {count++;

if (strike price < x[0])

return 0;

else

return Math.sqrt(strike price - x[0]);

}}

Compile your class source file with the Java compiler and then use the RMI compileron the resulting class files to generate the associated RemoteStub implementation. ForJava platforms older than v1.2, you will also require the Skeleton interface.

> javac MyPayoff.java

> rmic MyPayoff

During compilation the MyPayoff class and its Stub and Skeleton classes will be cre-ated in the current directory. The last step you will perform is to create an instance of theEnterprise JavaBeans component on the server. Make sure to initialize your function withan adequate parameter and make it available through a public RMI registry. To continueour example we create a new Registry running on the default 1099 port number, and use

75


‘remote f’ as the identification string.

Registry reg = LocateRegistry.createRegistry(8099);

Remote f = new MyPayoff(50);

reg.rebind("remote f", f);

After completing the entire implementation process, you should be ready to deliver yourpayoff function to the enterprise Bean on the server. As commonly practiced, the RMIsystem asks that the RemoteStub implementation class should be made available to thereceiver, the EJB server in our case. The following class allows you to avoid this inconve-nient, by automatically sending related Stub information to the server.

package com.webcab.ejb.finance.options.exotic;

public class FunctionDelivery implements java.io.Serializable {public FunctionDelivery (String RMILocation)

throws FunctionDeliveryException;

}

This class is responsible for delivering the current instance of the function to be ana-lyzed, its related resources and RMI binding name. You will not require to manuallytransport any of this information to the server, they are automatically passed on by theFunctionDelivery class. In this way the client developer is able to invoke enterprise meth-ods and send valuable information in a transparent and efficient manner. An exception isthrown by the constructor of this class if errors are encountered while locating the remoteresource or while retrieving the RemoteStub implementation.

Use the qualified URL of your remote function as a construction argument for this class,in an RMI specific form:

rmi://Host:Port/BindingName

and pass on the newly created object as a parameter for the creation methods of FiniteDifferenceor MonteCarlo. In our case, we use the local host as the host for the RMI registry andomit the port number.

76


try {MonteCarlo bean = home.create(new FunctionDelivery(

"rmi://localhost/remote f"));

}catch (Exception e) {}

The bean variable is an instance of the WebCab MonteCarlo Enterprise JavaBean run-ning inside the Application Server and contains all of its methods and fields, as describedin the JavaDocs pages.

Remark You do not require to make the RemoteStub implementation available to theserver, the FunctionDelivery class handles all class loading operations.

7.4.2 Local Delivery

As compared to the remote way of delivering a function to the EJB Server, the local de-livery procedure is much easier to implement. This method allows you to pass on to theserver function that do not require client-side specific resources.

Under common circumstances, after compiling a local function, in order to make it avail-able for the EJB component you would have to make a copy of it on the server machine inone of the locations specified by the java.classpath environment variable. The followingclass allows you to manipulate local functions without any such additional operations.

package com.webcab.ejb.finance.options.exotic;

import java.io.*;

public class LocalFunctionDelivery implements Serializable {

public LocalFunctionDelivery (Serializable o)

throws FunctionDeliveryException;

}

This class encapsulates all information related to the Serializable object passed on asa constructor parameter and its class. In order to make a local function available to theenterprise bean running on the server, invoke the creation methods with a LocalFunctionDeliveryinstance, previously instantiated with your function. For example, if you wish to send thepreviously defined MyPayoff class you may write the following Java code:

77


try {

MonteCarlo bean = home.create (new LocalFunctionDelivery

(new MyPayoff(50)));

}catch (Exception e) {

e.printStackTrace ();

}

The bean object holds an instance of the remote EJB component and contains its fields andmethods, as precisely detailed inside the JavaDocs documentation. Unless the object youwish to pass on as a local function to the server is using client-side specific resources, allnumerical methods invoked by the client will perform excellent and with a highly increasedspeed. In order to apply any of the methods, simply invoke the corresponding enterprisemethod and retrieve the result.

7.5 Using JDBC Mediator with our EJBs

7.5.1 Overview

The JDBC mediator is an EJB component which mediates between an EJB component, itclients and DBMS. For each EJB component there exists a corresponding mediator withits own exception class. The mediator receives an input and an output SQL query for theDBMS and a method name to analysis. The mediator sends the SQL input query to the(input) DBMS and then applies the method from the EJB component to each row of theinput query results. Each result row is written into the (output) DBMS according to theoutput SQL query.

78


A diagram that illustrates how JDBC Mediator intermediates the communication between the client,

the Application Server and the Database Servers.

7.5.2 Connecting to your Database Server

If you wish to connect by JDBC to your Database server in order to run a select queryan update statement or a stored procedure you will need to describe the connection withcertain properties. You will be given the opportunity to use JDBC Mediator with Applica-tion Server DataSources and Connection Pools or directly specifying these properties andpassing them to the create methods.

� DriverThe driver is a Java class provided by your Database vendor that implements thejava.sql.Driver interface.

� URLThis property defines the address of your DBMS, the port number and additionalinformation such as service and database name.

� Username and PasswordFor authentication reasons, most connections will not work without providing a username and a password.

� Additional PropertiesThis field allows you to customize even more your JDBC connection as described inthe JavaDocs

We describe these properties individually for the most well known database systems. Pleasefeel to jump to the section which refers to the particular DBMS you plan to use with ourJDBC components.

79


Oracle 9i

We recommend the JDBC thin driver oracle.jdbc.driver.OracleDriver. You maydownload this driver from http://otn.oracle.com/software/tech/java/sqlj jdbc/content.html.The Oracle URL has the following format:

jdbc:oracle:thin:@servername:port:service

where servername is the Internet name of your Oracle DBMS, port is usually 1521 andservice is the name of the service you are going to connect to.

IBM DB2

The name of the DB2 driver is COM.ibm.db2.jdbc.net.DB2Driver and can be downloadedoff the IBM site at http://www-106.ibm.com/developerworks/db2/zones/java/. The for-mat of the DB2 URL is:

jdbc:db2://[servername]:[port]/[database]

where servername is the Internet name of your DB2 DBMS, port may be ignored anddatabase is the name of the database you plan to connect to.

Microsoft SQL Server

The name of the SQL Server driver is com.microsoft.jdbc.sqlserver.SQLServerDriverand can be downloaded off the Microsoft site at http://msdn.microsoft.com/.... The for-mat of the Microsoft SQL Server URL is:

jdbc:microsoft:sqlserver://servername:1433

where servername is the Internet name of your SQL Server.

Sybase

The name of the Sybase driver is com.sybase.jdbc.SybDriver and can be downloaded offthe Sybase site at http://www.sybase.com/home. The format of the Sybase JDBC URL is:

jdbc:sybase:Tds:servername:port/

where servername is the Internet name of your Sybase DBMS and port is the port numberwhere the Sybase server is running.

7.5.3 JDBC Components

Most methods implemented by our enterprise Beans accept numeric parameters and returnnumbers or arrays of numbers. By using these JDBC methods directly inside a database

80

http://otn.oracle.com/software/tech/java/sqlj_jdbc/content.html

http://www-106.ibm.com/developerworks/db2/zones/java/

http://msdn.microsoft.com/library/default.asp?url=/downloads/list/sqlserver.asp

http://www.sybase.com/home


server without any change in functionality will definitely prove necessary. In this case thedatabase server becomes the DataSource for the input and/or output parameters for everyone of these methods.

What we are going to discuss applies only to the following modules included in this appli-cation. Modules not listed here either do not implement JDBC or use a particular JDBCimplementation.

– The “Exotic Options” J2EE Module

– The “Options” J2EE Module

– The “Equity Derivatives” J2EE Module

– The “Futures” J2EE Module

For every bean implementing number-based methods (methods with numeric parametersand numeric return values) there is a bean in a sub-package called “jdbc” bearing a simi-lar name. For example, if there’s a bean called “FinancialBean” within a package called“com.webcab.ejb.finance”, the corresponding JDBC-implementing component would be“com.webcab.ejb.finance.jdbc.FinancialBeanJDBC”.

The JDBC components are designed to easily transfer to an Application Server JDBCspecific tasks that make use of the capabilities of every bean within our enterprise appli-cation. The enterprise database performs demanding transactions which take place on thesame machine that hosts your EJB components. This allows the client to take advantageof the processing power of your Application Server and minimize bandwidth transfer.

The JDBC beans are created by specifying all necessary JDBC connection parameters,such as drivers, url, username and password plus the enterprise Bean’s creation parame-ters. Every JDBC component contains several methods that invoke methods from theircorresponding enterprise Bean and apply them directly to your database tables and/orwrite the answer back into the same or another DBMS. The JDBC methods accept thename of the enterprise method as the first parameter and an SQL Query or an array ofJava objects for the method’s input and output.

The following source code listing exemplifies how to use an input/output SQL queryJDBC method for a generic bean called “com.webcab.ejb.finance.FinancialBean” anda generic method “double calculateAmount (double, double)”.

81


import com.webcab.ejb.finance.FinancialBean;

import com.webcab.ejb.finance.jdbc.FinancialBeanJDBC;

...

try {...

/*

* The first creation parameter (riskFreeInterestRate) is FinancialBean* specific. The next creation parameters define the input and the output* DBMS connections by driver, url, username, password and additional* properties.*/

FinancialBeanJDBC jdbcBean = home.create (riskFreeInterestRate,

"oracle.jdbc.driver.OracleDriver", // Input Connection

"jdbc:oracle:thin:@inputserver.com:1521:ORACLE",

"SCOTT", "tiger", null,

"oracle.jdbc.driver.OracleDriver", // Output Connection

"jdbc:oracle:thin:@updateserver.com:1521:ORACLE",

"MIKE", "wolf", null);

jdbcBean.call ("calculateAmount",

"SELECT C ID, SHARES, VALUE FROM TRADES",

"UPDATE CUSTOMER SET MONEY=? WHERE C ID=?",

new int[][] {{2, 1}});catch (Exception e) {e.printStackTrace ();

}

The first parameter of the call method represents the FinancialBean method name. Thesecond parameter is the input query, a select query which returns three columns C ID,

SHARES and VALUE. The third parameter is a prepared statement that is meant to write thevalue returned by calculateAmount in the MONEY field and the C ID primary key in thewhere clause. This assignment is described by the last parameter, an array of integer pairsthat specifies the index of the IN parameter in the output query and the column numberof the input query. Both indices start counting from 1. In our case, the second IN param-eter is the second question mark in the update statement and the first input column is C ID.

Every output update is made according to a primary key C ID. Even though this isreturned by the select statement it is not used for computation by the two-parameter“calculateAmount” method.

As an alternative you may wish to define two DataSources that point to the input and out-put connections described above. You may then map the corresponding resource references

82


defined inside the ejb-jar.xml deployment descriptor to the JNDI names correspondingto these DataSources. In this case scenario, the previous code would look like this:

import com.webcab.ejb.finance.FinancialBean;

import com.webcab.ejb.finance.jdbc.FinancialBeanJDBC;

...

try {...

/*

* The only creation parameter is riskFreeInterestRate. Ignore the* JDBC specific parameters. The bean will be using the* resource references defined inside the ejb-jar.xml XML* to locate the Input and Output JDBC connections.*/

FinancialBeanJDBC jdbcBean = home.create (riskFreeInterestRate);

jdbcBean.call ("calculateAmount",

"SELECT C ID, SHARES, VALUE FROM TRADES",

"UPDATE CUSTOMER SET MONEY=? WHERE C ID=?",

new int[][] {{2, 1}});catch (Exception e) {e.printStackTrace ();

}

Note The primary key reference can be made across two different database servers avery useful feature provided by this type of JDBC methods.

7.6 Support for Developers

7.6.1 Compilation and Custom Modification of Source Code

This J2EE Application and related JavaTM source files have been compiled using Sun’sJ2SDK1.4.2 and J2EE 1.3, should you prefer compilation of the source code using anothercompiler then please contact us. Some functions (for example standard mathematicaloperations) are embedded within the source code, if you license classes which you believeoffer a similar level of functionality from a third party and wish to include these classeswithin our components then please contact us. Both of the above services are offered freeof charge at WebCab’s discretion.

83


7.6.2 Online Support

If you have any questions or queries concerning the use of this component then please feelfree to contact us via our support forum at:


For updates and new releases, visit:

http://www.WebCabComponents.com

84



Chapter 8

Examples

Within this chapter we detail the examples provided with this J2EE Application. Weprovide with this Component examples of two types:

1. QA Examples

2. Custom Examples

8.1 Question and Answer (QA) Client Examples

8.1.1 Overview

Within this folder we offer Java client examples for the J2EE Business Components pro-vided within this package. In particular, for each business method contained within eachbusiness Component we provide a client side example; which illustrates how functionalitycontained within this component can be applied to solve real world problems. In addition,to these examples we also include custom applications which solve some of the genericproblems which this Component is designed to address.

8.1.2 Structure of QA Examples Directory

By drilling down the QA Client directory structurr you will find the following six directorylevels:

1. Client Level2. Technology Level3. Business Module Level4. Business Class Level5. Example Level6. Custom Example Level

which have the structure as shown in the following diagrams.

85

Examples Chapter 8

8.1.3 Top Four levels of the QA Directory Structure

(Technology Level) (Business Module Level) (Business Class Level)

Client +

|

+ Java -------+

| |

+ Readme.txt + ‘Business Module 1’ -------+

| |

+ ‘Business Module 2’ --+... + ‘Business Class 1’ ----------

| |

+ QALibrary.jar + ‘Business Class 2’ --+...

|

+ ...

8.1.4 Bottom Two levels of the QA Directory Structure

(Example Level) (Custom Example Level)

-----+

|

+ ‘BusinessClass’.java

|

+ compile.cmd (.sh for Linux)

|

+ run.cmd (.sh for Linux)

|

+ run_gui.cmd (.sh for Linux)

|

+ ‘CustomClient’ -----------------+ ‘CustomClient’.java

| |

+ ... + compile.cmd (.sh for Linux)

|

+ run.cmd (.sh for Linux)

8.1.5 Quick Start Guide

Browse down to the particular client within the business module for the given client tech-nology you are interested in. Run the compile.cmd (.sh for Linux), script in order tocompile the example and then run the run.cmd (.sh for Linux), script in order to run theexample.

86

Examples Chapter 8

8.1.6 Explanation of the QA Directory Structure and its files

1. Client Level

The directory containing the Questions and Answer Examples is named ‘QAClients’.This directory can be located by using the Index.html file, which is presented at theend of the installation process, by selecting:

Run Examples > Client Examples Directory

Within this folder you will also find the following file:

� Readme.txt - this readme file

2. Client Technology Level

Within the ‘Client’ folder is the Technology Level of the QA directory structure.Within this folder you will find sub-directories; which contain examples written ineach of the Java Client Technologies in which the clients have been implemented.

As mentioned above within the overview we provide an implementation of each ‘Ques-tion and Answer (QA)’ example using each of the client technologies used. Selectingone of these folders in order to view the client implemented within the correspondingtechnology.

3. Business Module Level

After selecting one of the technology sub-folders at the ‘Client Technology Level’ (see(2) above) you will enter a folder which contains a sub-folder for each of the modulescontained within this component package. The modules are convenient collectionsof business classes containing the business functionality offered by this component.Each module has a sub-folder which contains the ‘Question and Answer’ examples ofeach method of the classes which it contains.

This directory will also contain the following file:

� QALibrary.jar - contains utility functionality necessary for running the clients.

4. Business Class Level

At the business class level under the module level we are presented with one sub-folderfor each of the classes within the business module. Each of these folders contains thefiles of the examples for each of the methods contained with the respective class.

5. Example Level

At the Example level you will be presented with the files which allow you to compile

87

Examples Chapter 8

and then run the examples of the application of the Business methods of the respec-tive class. The files within this directory which constitute the Client example are asfollows:

� Source Code File(s) - Depending on the Java compatible technology selected atthe ‘Technology Level’ this folder will contain a source code file(s) of the client.

� Compile Batch File - Assuming that you have access to the relevant compilerthe compile batch file (compile.cmd or compile.sh) once run will compile theclient example from the folders source code file.

� Run Batch File - The run batch file (run.cmd or run.sh) will run the examplesexecutable file (exe) which is generated from the compilation of the source codefile. If the example over runs your console screenful then press space in orderto page down or enter is order to scroll down.

6. Custom Example Level

At the Custom Example level you will find a source code file containing the im-plementation of the Application which addresses a typical question for which theComponent is designed. The source code has a linear structure with full inline com-mentary. By just running the compile and then run scripts contained within thisdirectory you will be able to solve to given problems view the results obtained. Thefiles contained within each Custom Client Example directory are as follows:

� Source Code File(s) - The custom clients source code in the appropriate clienttechnology.

� Compile Batch File - Assuming that you have access to the relevant compilerthe compile batch file (compile.cmd or compile.sh) once run will compile theclient example from the folders source code file.

� Run Batch File - The run batch file (run.cmd or run.sh) will run the examplesexecutable file which is generated from the compilation of the source code file.If the example over runs your console screenful then press space in order to pagedown or enter in order to scroll down..

8.1.7 Database Example with JDBC Mediator

The Database Example is located inside the Client/Options/DatabaseExample directory.The following steps are required before running the Database example.

1. Installing our Tables (MySQL Only)In order to create the database structure from which you are able to load the outputresults, you will need to run the ‘create.sql’ scripts in the ‘Data’ subdirectory. Openthe MySQL prompt from the ‘Data’ subdirectory and:

88

Examples Chapter 8

� Select (or create and then select) a database you can spare for tables namedAMD, BEAS, DELL, IBM, MSFT, ORCL, and RATE. For example, if you havedecided using the ‘test’ database, you would optinally type the SQL commandto create it (unless it already exists):

CREATE DATABASE test;

and then, you would type the following to select it:

USE DATABASE

� Run the ‘create.sql’ SQL script located in the ‘Data’ subdirectory of the currentdirectory by typing at the same MySQL prompt the following:

source create.sql

If this fails, make sure you have started the MySQL prompt from the ‘Data’subdirectory (this is where the database files for this example are stored).

2. Configuring the Database ConnectionEdit the Java source code file by filling out JDBC information about your database,such as:

(a) Driver Name (e.g. com.jdbc.mysql.Driver)

(b) JDBC Url (e.g. jdbc:mysql://localhost/test)

(c) Username and Password

If you are unsure whether you have a JDBC Driver for your Database, skip this stepand try running the example with the predefined values. If that fails, you will needto probably download the latest driver.

3. Running the example

Run the ‘compile’ script (compile.sh for Linux, compile.bat for Windows) to compilethe Java source code, and then the ‘run’ script to see the results.

Uninstalling the Source Data

To delete all the tables used in this example, open the MySQL prompt from the ‘Data’subdirectory, select the database where you created the tables, and run the following:

source delete.sql

8.2 Exotic Options Custom Examples

This section provides examples of using option pricing methods (in particular Monti-Carlo andFinite Differencing) implemented within the Exotic Options module of the WebCab Optionsand Futures J2EE Application. For the below listed examples we built working applications sothat you may see how the component can be used and then how it performs.

89

Examples Chapter 8

8.2.1 About the examples

There are seven examples included for the Exotic Options module. We designed them withthe intention of covering a broad range of possible user scenarios.

8.2.2 Testing procedure

In all our examples of options on one asset the following financial parameters were used:

� interest rate = 0.1

� no dividend (dividend yield = 0)

Also note that all the results are displayed with five digit precision.

Monte Carlo results will differ with each subsequent method call using identical parame-ters, because the Monte Carlo algorithm contains a fundamental random selection element.Therefore a comparison between MonteCarlo and finite differencing cannot be relevant un-less seen in a statistical manner. You should run our examples many times before makingany conclusions regarding the differences between Monte Carlo and finite differencing.

In some of the examples we use a formula to estimate the magnitude of the differencein relation with the magnitude of the results. That is, we calculate:

relative difference =|fd result−mc result||fd result|+ |mc result|

(8.2.1)

8.2.3 Example 1 - European vanilla options

Motivation and Problem

This example compares finite differencing with Monte Carlo for very simple option typeswith known boundaries. We use the SimplePayoff and SimpleBoundaries classes to specifyour option type. The contract stipulates that we have an European call option with strikeprice equal to 50 and that it will be exercised after one year.

Suppose that the current asset price is 40 and we wish to find out the present optionvalue.

The Parameters

In this instance the following parameters should be used within the finite differencingalgorithm:

� algorithm = Cranck-Nicholson

90

Examples Chapter 8

� time steps = 1000

� maximum asset price = 150

� asset price steps = 150

Results

According to the finite difference procedure the present option price is 4.44724.

For Monte Carlo, the number of random walks is set to 1000.

Almost 90% of the tests runs with this example show a relative difference between MonteCarlo and finite differencing less than 5%.

Source Files

The source file for this example is EuropeanVanilla/EuropeanVanilla.java and it can befound in the /Client/ExoticOptions directory within the Applications package.

8.2.4 Example 2 - Supplying your own payoff function and bound-aries


This example shows you how to supply your own payoff function and boundaries. Thepayoff function used here is actually the square root of the payoff from a Vanilla put option.

We compared the results obtained using the generic SecondOrderBoundaries class withthe results obtained when we have set the boundaries by implementing Dirichlet abstractclass.

The Parameters

The algorithm parameters are exactly the same as those used in the previous example.

Results

The results are:

� generic boundaries - 2.3347

� user designed boundaries - 2.34563

The Monte Carlo method returns similar results.

91

Examples Chapter 8

Source Files

The source files for this example is SupplyingPayoffFunction/SupplyingPayoffFunction.java.It can be found in the /Client/ExoticOptions directory within the Applications package.

8.2.5 Example 3 - Supplying your own payoff function for multi-asset boundaries

The Problem This example is similar to the previous one, the only difference being thatnow we have a two-asset option to be priced.

The Parameters

The financial parameters are:


� volatility of first asset = 0.4

� volatility of second asset = 0.3

� no dividend (dividend yield = 0)

� correlation matrix =

(1 0.15

0.15 1

)As there is more than one asset, we do not have the possibility of choosing the algorithmtype. The only algorithm which can be used is the explicit algorithm.

The (explicit) algorithm parameters are:




The strike price for the first asset is 50 and for the second asset it is 40.

Results

The results are:

� generic boundaries - 2.19603

� user designed boundaries - 2.19578

92

Examples Chapter 8

Remark If you are using the J2EE platform and local delivery then you can see thatthe finite differencing algorithm is slower in combination with the generic boundaries. Thereason for this is that the computations required by the client MyBoundaries class arefewer than those performed by SecondOrderBoundaries. Quite the opposite happens whenusing remote delivery. In this case, with generic boundaries, the algorithm finishes muchfaster. Indeed, the server using client boundaries must now call the getValueAt methodremotely while all processing for general boundaries still takes place on the server. In thisinstance you can see the huge speed difference which can occur between the two deliverymethods. Here in this example there are 40000 calls to the boundary evaluation methodwhich needs 40000 network connections and greatly infringes performance.

Source Files

The source files for this example is MultiAssetOptions/MultiAssetOptions.java and it canbe found in the /Client/ExoticOptions directory within the Applications package.

8.2.6 Example 4 - Thorough comparison between finite differ-encing and Monte Carlo


In this example we call the Cranck-Nicholson finite differencing algorithm and Monte Carlosuccessively for 6 types of options each having 10 different maturity dates. This meansthat we have a total of 60 option contract to value. For each contract the absolute and therelative difference between the results are also displayed.

Remark There exist some results that are evidently wrong (for example the negativevalue which appears when evaluating Lookback strike put option with 10 years to matu-rity). The most probable cause of these and of other very large differences is simply thatthe boundaries are wrong (the general” boundaries we use here are based on two assump-tions that are not necessarily applicable to all option types). In such cases you shouldconstruct your own boundaries. For further discussion of this issue please see boundaryconditions section of the Exotic Options Programmers Guide. Also see other possible errorsources in Mathematical Documentation.

Source Files

The source file for this example is ComparisonFDMC/ComparisonFDMC.javaanditcanbefoundinthe/Client/ExoticOptionsdirectorywithintheApplicationspackage.

8.2.7 Example 5 - American options

Motivation and Examples

This example compares the three finite differencing algorithms: explicit, implicit and Cranck-Nicholson. American options cannot be priced with Monte Carlo, so no such results are

93

Examples Chapter 8

displayed. When evaluated with an implicit algorithm (fully implicit or Cranck-Nicholson)the tolerance parameter must be set. In our example the tolerance was set to 0.001. Gen-erally it is not worth trying to set this to a lower value in the hope that precision willincrease.

The Parameters

Algorithm parameters are:




The current price was considered to be 75, the strike price 50 and the time to maturity ofone year.

Results

The results are:

� explicit algorithm - 0

� fully implicit algorithm - 30.07861

� Cranck Nicholson algorithm - 30.51493

The explicit algorithm returns 0, because it is unstable in the current configuration of al-gorithm parameters. If you increase the number of time-steps to, say 10000, you will seethat it will return a correct result. The same thing happens if you decrease the asset pricestep to 50 (for example).

Remark Zero is not the only result possible when the algorithm is unstable. Oftenvery large results are returned (for example 1E100).

Source Files

The source file for this example is AmericanOptions/AmericanOptions.java and it can befound in the /Client/ExoticOptions directory within the components package.

8.2.8 Example 6 - American multi-asset options


This example shows you how to evaluate American multi-asset options. For this purposewe use two standard option strategies: the spread and the strangle.

94

Examples Chapter 8

The Parameters

The financial parameters are the same as in the European multi-asset example.

The algorithm parameters are:




The contract specifies that the strike price for the first asset is 50 and for the second asset40. The expiry time is one year and the current asset prices are 40 and 90 respectively.

Results

The results are:

� American bull spread - 4.60251

� American bear spread - 10

� American strangle - 12.5145

� American straddle strategy - 10.09196

Source Files

The source file for this example is AmericanMultiAssetOptions/AmericanMultiAssetOptions.javaand it can be found in the /Client/ExoticOptions directory within the Applications pack-age.

8.2.9 Example 7 - Example of Bermudan options


This is an example of a simple put option with expiry time of one year and early exercisepermitted only during an interval of six month beginning with the third month of the year.All these restrictions are set in the payoff function, which is, in this case, time dependent.That means we have a Bermudan-type option.

The Parameters

The current price is 40 and the strike price is 50. Cranck-Nicholson algorithm is used withgeneric boundaries.

Results

The result returned are 10.91813.

95

Examples Chapter 8

Source Files

The source files for this example is BermudanOptions/BermudanOptions.java. It can befound in the /Client/ExoticOptions directory within the Applications package.

8.2.10 Example 8 - Example of Binary options


This is an example of a binary option, which pays off 1 currency unit if the price after oneyear is above the strike price.

Results

The result of the Crank-Nicholson algorithm is 0.28462.

Source Files

The source files for this example is BinaryOptions/BinaryOptions.java. It can be found inthe /Client/ExoticOptions directory within the Application package.

8.2.11 Example 9 - Example of Asian options


This example shows you how to use the pricing methods for strongly path dependentoptions. Specifically a Asian option with daily arithmetic averaging is used. It is a rate(price) call option. This means that the payoff is max(average− strike, 0). The followingparameters were used:


� volatility = 0.3

� time to maturity = 1

� current price = 40

� strike price = 50

� dividend = 0

� price steps = averagesteps = 150

� maximum price = maximumaverage = 150

� time steps for finite differencing = 5 ∗ 260 = 1300

� sampling period = 5(dailyupdatingoftheaverage)

96

Examples Chapter 8

� time stepsforMonteCarlo = 260

� random walks = 9000

Results

The result of the Cranck-Nicholson algorithm is 0.74908.

Source Files

The source files for this example is AsianOptions/AsianOptions.java. It can be found inthe /Client/ExoticOptions directory within the Application package.

8.2.12 Example 10 - Example of Lookback options


This example is very similar to the previous one, except that we are now pricing lookbackoptions instead of Asian options (which are also strongly path dependent). The differenceis that the path dependent variable is now the maximum value of the price registered fromthe beginning of the contract. The payoff is max(max− strike, 0). The same parametersas in the previous example were used.

Results

The result of the Cranck-Nicholson algorithm is 4.94097.

Source Files

The source files for this example is LookbackOptions/LookbackOptions.java. It can be foundin the /Client/LookbackOptions directory within the Application package.

8.2.13 Example 11 - Example of Monte Carlo with error control


This example shows you how to use error control for Monte Carlo. It is identical withthe first example (European vanilla options), except that now we require that the relativeerror of Monte Carlo is less than 5%, with 95% certainty. So the confidence level is 0.95and max relative error is 0.05.

Results

If you run the example multiple times, you can notice that in the large majority of casesthe relative error is below 5%. On the average, only 1 in 20 runs should have a biggererror.

97

Examples Chapter 8

Source Files

The source files for this example is ErrorControl/ErrorControl.java. It can be found in the/Client/LookbackOptions directory within the Application package.

98

Chapter 9

Guide to WebCab Components

9.1 The Company

WebCab is a privately owned British company that has built business solutions since itsinception in 1999. We continue to refine and develop our Mathematical and FinancialFramework which we have implemented on the J2SE, J2EE and .NET platforms.

9.2 Presentation of Products

We aim to provide good quality, useful information to help you decide which J2EE appli-cation best suits your development needs. WebCab is committed to honesty and realismwhen presenting our products. In order to achieve this a detailed, clear and factual stylefor presentation is adopted within our documentation and marketing material.

9.3 Supported Clients, IDEs, Containers and DBMSs

We support all major development, server and client side technologies. Each productcontains detailed examples and advice concerning the integration of our enterprise applica-tions within existing infrastructure. Our documentation provides the information that thedeveloper needs to get their applications up and running as quickly and as easily as possible.

We detail exactly how the developer can use our J2EE Applications with the followingtechnologies:

� Client containers - Internet Explorer, Netscape Navigator, Opera

� IDEs - JBuilder, Eclipse, BEA Studio, Sun ONE (formerly Forte For Java), IBMVisualAge, Oracle JDeveloper

� Client Side Technologies - Application Clients, Servlet, JSP, Applets

� EJB containers - IBM WebSphere, BEA WebLogic, Oracle 9iAS, Sun ONE AppServer,Borland AppServer, Sybase EAServer, Ironflare Orion, JBoss

99

Guide to WebCab Components Chapter 9

� DBMS - Oracle, IBM DB2, SQL Server, Sybase, MySQL

� Platforms - Windows XP/2000/NT, Linux, Solaris, IBM AIX

For these technologies we include all the deployment descriptors, installation scripts andtemplate examples which will help the developer quickly and easily assemble their multi-tierenterprise application.

9.4 Transparent Functionality

All technical and business intelligence incorporated within our products is described withinthe associated documentation. This allows the developer to see the nature of the method-ology implemented within our proprietary algorithms.

9.5 Code Conventions

WebCab adheres to the ‘Code Conventions for the Java Programming Language’ as spec-ified on April 20, 1999 by Sun Microsystems Inc. These conventions cover filenames, fileorganization, indentation, comments, declarations, statements, white space, naming con-ventions and programming practices. Code conventions improve the readability of thesoftware, allowing engineers to understand new code more quickly and thoroughly.

9.6 Company Culture and Activity

WebCab Components is focused solely on the production of high quality software moduleswithin our Financial and Mathematical Framework. The WebCab team contains a widerange of expertise and experience from the academic, investment banking and softwaredevelopment worlds.

Within the company there exists significant internal competitive pressures with constantpeer review and evaluation, resulting in higher quality products, which adhere to highprofessional standards and offer extended functionality.

9.7 Product Life cycle

We continuously add value to our products by evolving them according to new J2EE spec-ifications, customer feedback and market demands. We give particular emphasis to incor-porating our clients suggested modifications and additions into our product developmentcycle.

100

Guide to WebCab Components Chapter 9

9.8 Support, Warranty and Upgrades

WebCab warrants that each component will perform substantially in accordance with theaccompanying written material. We provide with all our products without charge sixty(60) days product support services including fixing bugs, compatibility issues and othertechnical support issues.

All maintenance updates (including service packs) will be distributed free of additionallicense cost. New version releases of this product will be offered to present licensee holdersat a greatly reduced rate.

Dr Ben Fairfax

Founder and CEO

WebCab Components - From Developer, To Developer

Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in

the U.S. and other countries. .NET is a trademark of Microsoft Corporation in the U.S. and other

countries

101

WebCab Options and Futures v3€¦ · management techniques for European, Asian, American,...

Documents

Transcript of WebCab Options and Futures v3€¦ · management techniques for European, Asian, American,...