PROJECT. COMPUTING BARRIER OPTION PRICES UNDER LOCAL VOLATILITY MODEL WITH FINITE DIFFERENCE AND MONTE CARLO SIMUL ATION
Assume the stock price S paying a continuous dividend yield q follows the process below
dSt = (r − q)Stdt + σ(St, t)StdWt, (1)
where r is the risk free interest rate and W is a Wiener process under the risk-neutral probability measure. The local volatility surface has been calibrated with the form below:
σ(S, t) = 0.25e−t(100/S)α.
We know that the price of an option, V (S, t), on the above stock satisfies the PDE below:
∂V +1∂2Vσ(S,t)2S2+(r−q)S∂V −rV =0. ∂t 2 ∂S2 ∂S
In this project you are asked to price some very popular weakly path dependent option, such as a Barrier option using both Finite Difference and Monte Carlo Methods.
Barrier options (also called knock-in or knock-out options) are standard calls or puts except that they disappear (knock-out) or come into existence (knock-in) if the underlying asset price is found to have crossed a predetermined (barrier) level, B, anytime before the matu- rity of the option. They have a fairly standard naming convention which describes whether the barrier is below or above the current asset price (“down” or “up”), whether the option disappears or appears when the barrier is crossed (“out” or “in”) and whether they have a standard call or put pay-off. For instance, an up-and-out call option with zero rebate will have a payoff
hup-and-out call(ST ) = max(ST − K, 0), if max0≤t≤T St < B 0, otherwise
The aim of this project is to use the following pricing parameters, spot price S0 = £100, strike price K = £100, a Barrier level B = £130, risk-free rate r = 3%, dividend yield q = 5%, time to maturity T = 0.5 year, and α in the local volatility function α = 0.35, solve the Black-Scholes PDE numerically to price an up-and-out call option by means of
(1) Explicit finite differences (2) Implicit finite differences
Date: Current Version February 19, 2018.
1
2
PROJECT
(3) Crank-Nicolson finite differences
Since there is no analytic solution to the PDE, you need to compare the results from finite difference method with the prices calculated from Monte Carlo simulation. Please finish the tasks below:
- a (35% of project mark) Implement Monte Carlo Simulation using Euler Scheme to dis- cretize equation (1) with 500 time steps and 1 million paths to compute the up-and-out call option prices and 95%− confidence intervals of those prices. Please use the antithetic method to reduce the variance of the results.
- b (15% of project mark) Discuss proper domain and boundary conditions you should use in the finite difference schemes based on the properties of the up-and-out call option.
- c (40% of project mark) For each of three finite difference schemes, namely each scheme in (1) – (3), compare the prices with different grid sizes with those from the Monte Carlo methods and report the convergence properties of each scheme.
- d (10% of project mark) In the case of the explicit finite difference scheme demonstrate that the scheme is conditionally stable and find the condition under which the scheme would be stable.
The code should be accompanied by detailed documentation, split into:
- code developer documentation: presenting the structure of the code, available func- tions, main variables and any other information to help to understand the code, including directions on how to extend the code to handle more general features; the test runs of your code and timings should be reported in a separate section of the developer documentation;
- end-user’s instructions: how to use the .m program, how to input data and how the results are presented, and a brief description of the methods implemented. Also the discussions of parts (b), (c) and (d) should be included here.
- Each of the marks in the above categories (a) − (d) will be split as follows: 60% for coding style, clarity and accuracy of computation, and 40% for documentation (including comments within the code).
This project will contribute 40% towards the final mark for the module.
Submit your work by uploading it in Moodle by 23:55 on Sunday, 15 April 2018. Submit the code as a single compressed .zip file, including all Matlab (.m) files all residing in a sin- gle parent directory, whose name should contain your name and student code. The .zip file should preserve the subdirectory structure of the parent directory (that is, the subdirectory structure must be automatically recreated when unzipping the file).
PROJECT 3
The documentation files must be submitted in .pdf format (two separate .pdf files containing developer documentation and user instructions) and uploaded in Moodle as a single .zip file separate from the code file. The .zip file containing documentation should also bear your name and student number. Unless approved mitigating circumstances apply (if you need to claim the mitigating circumstances, please refer to the mitigating circumstances procedure), late submissions will incur a penalty according to the formula
10%×m×d, ifd≤5 100% × m, if d > 5
where m is the maximum mark that can be awarded for this assignment, and where d is the number of days or part days that the assignment is late, i.e. according to the standard university rules for late submission of assessed work. It is advisable to allow enough time (at least one hour) to upload your files to avoid possible congestion in Moodle before the deadline. In the unlikely event of technical problems in Moodle please email your .zip files to boda.kang@york.ac.uk before the deadline.
It may prove impossible to examine projects that cannot be unzipped and opened, and run on computer lab machines directly from the directories created by unzipping the submitted .zip files. In such cases a mark of 0 will be recorded. It is therefore essential that all project files and the directory structure are tested thoroughly on computer lab machines before being submitted in Moodle. It is advisable to run all such tests starting from the .zip files about to be submitted, and using a different lab computer to that on which the files have been created.
A common error is to place some files on a network drive rather than in the submitted directory. Please bear in mind that testing on a lab computer may not catch the error if the machine has access to the network drive. However, the markers would have no access to the file (since they have no access to your part of the network drive) and would be unable to compile the project. All files must be submitted inside the zipped project directory, and connected to the project. Please check before submitting!