C++ For Finance, C++ Project 1, 2018-9
This assessment is worth 40% of the total marks available for C++ programming. The hand-in date is 12noon 21st January 2019.
Option Pricing under non-constant volatility
In the lectures all option pricing has been done under the assumption of the stock price following (GBM) geometric brownian motion with constant volatility. However in real world data it’s well known that volatility isn’t constant and exhibits a so called “smile” when plotted again the strike price of a vanilla option. There are many ways to extend GBM, this project will focus on the pricing options under the Heston stochastic volatility model with a Monte-Carlo method.
The Heston stochastic volatility model assumes that the stock (under a change of measure) follows the stochastic process
dSt=rStdt+√vtStdWtS .
While the variance vt is governed by the following equation
d vt=κ(θ−vt)dt+σ√vt dWvt .
r is the risk free interest rate, k volatility mean reversion rate, Θ long run average volatility and σ volatility of volatility.
W S ,W v are Brownian motion correlated with coefficient ρ. There is no simple closed formula for v you will ttt
therefore need to simulate it using an Euler method as outlined below.
In the following a superscript of “p” denotes the maximum of the variable and 0, this is done to ensure the discretised v
stays positive for all I, vip≝max(vi ,0) .
First simulate the volatility v using an Euler method
vi+1=vi+κ(θ−vip)δt+σ√vip√(δt)Wiv
You can then use this volatility path to simulate the stock path using the exact solution in the same manner as before.
Si+1=Siexp((r−0.5vip)δt+√vip√δtWSi )
W Si and W vi are random N(0,1) variables which are correlated with coefficient ρ . Refer to week 10 lecture notes for how to generate these. The rest of the variables are defined in the specification
You may use the code “MC_v0_plain” as a starting point which computes the price of a European Call option assuming GBM. Note that this implementation is very basic and procedural. For some idea of how to continue and structure your code refer to “MC_v1b_fns_struc” which should give you some direction.
Specification
You are asked by a client to create a C++ program to value a European vanilla call and put, and a European call and put lookback option with both floating and fixed strike under the Heston Volatility model. The following parameters are given
Stock and Option Parameters
S0 r X
T v0 Smin Smax
= 100 – Initial stock price = 0.05 – Risk free rate
= 100 – Strike Price
= 1 – Expiry time
= 0.04 – Initial Volatility
– Minimum price of the asset over the life of the option – Maximum price of the asset over the life of the option
Stochastic Variance Parameters
ρ = -0.5 – correlation between the Brownian motions W s ,W v κ = 5.0 – volatility mean reversion rate
Θ = 0.04 – long run average volatility
σ = 0.5 – volatility of volatility
The payoff of a European Call LookBack Float is given by ECfloat=max(ST−Smin,0)
Project 1 1
and for the fixed strike ECfix=max(Smax−X ,0)
similarly for the put
EPfloat=max(Smax−ST ,0) EPfix=max(X−Smin,0)
Your code should make it easy for the user to switch between each of the options as well as offering the choice of using either a standard GBM or Heston model for the simulations.
There is no simple closed form solution for the price of the lookback options under this model, it is therefore extremely important that you carry out checks (what happens when you make the time step smaller, what happens if you increase the number of simulations) and document these to ensure that your software the correct price for the model. Note there are exact prices for a european call and put under GBM, how can you make use of this?
The client wishes to deploy this software for years to come it is therefore imperative you comment and document the code fully so that others may continue development.
Things to think about
– How big/small will you take your time step δt ? What should happen when your time step gets smaller? – It might be useful to output the data to a csv file if you wish to do plots.
– What C++ structs you can use to simplify passing data.
– How many simulations should you run?
– Is your code generalisable in a way that would make it easy to extend and implement a different stochastic volatility model or option?
– It might be more efficient to generate the whole sample path at once in a vector rather than step by step. This then has the added bonus you can use vector methods to for example find the maximum stock price.
– When parameters are read in how can you do validation to make sure they are of the correct type? – What errors might your code produce? How can you deal with these?
Submission and requirements (IMPORTANT)
The assignment must be submitted, as electronic files, by the time and date supplied. A zip file must be uploaded which contains
1) The assessment report (the Report) in .docx, .doc or .pdf formats. A description of what it must contain is below.
2) a folder containing the .h, and .cpp in your project (the Code). You must not
include CMakeLists.txt, .o files .exe file, or any superflous folder such as cmake-build-debug or .idea in the zip
file. The files must be placed in a folder in the .zip file.
Code requirements
The code you submit in your zip must to be able to run without modification or addition with the CLion installation on the machines in the teaching area (even if you have used another IDE).
Use the most advanced style of C++ you can, but it is very significantly better to submit lower level, working, code than higher level code that does not have the required functionality.
Report requirements
The electronic report must be a single self-contained file and be print-ready. It is your responsibility to ensure that your report file can print correctly without modification.
Your report must include a clear description of the algorithm you implement and an assessment of your results. You will be assessed on.
a) The quality of your code in terms of readability, maintainability, clarity and sophistication, generalizability and general presentation.
b) The degree to which your code has the required functionality.
c) Your assessment of the efficiency of your implementation.
d) The presentation quality of the assessment as a whole
The report must have a title page giving the assessment title, your university number, and contain: i) A description of your program.
a) Mention any particular attributes of your programme you wish to draw attention to. b) Explain the structure/layout of the program.
Project 1
2
c) If you wish to refer to code you may either do so by saying the file and line number e.g line 30 in file main.cpp or include small code snippits.
ii) Contain results and analysis as requested in the code specification.
The description of your program must be less than three pages, excluding the title page, figures, tabales and code. The discussion of your results, must not exceed four pages. Benchmarking(testing) should be included within the results section and should be sufficiently extensive to convince the examiner of the veracity of your code.
The bode of your report must use Times New Roman.
The name of the report, the zip file, and the folder inside your zip file must be your university number. Rename the internal C++ project name to be your ID number. Your university number must also appear (i) on the title page of the report and (ii) in a comment at the top of each .h and .cpp file. (marking is anonymous so your name must appear nowhere).
The code in the zip files will be compiled and run to confirm its functionality.
Conventions for code: Look at the file C++StyleGuide.pdf
Supply banner comments:
Follow the guidelines used in the module.
Header comment:
End of file comment:
In-line comments:
Supply intermediate banner comments preceding functions and elsewhere as appropriate. Your student ID must appear in every source code file in the header comment.
At minimum giving the name of the file/module. No code must appear after this comment. Supply these liberally to explain the code
Group work is not permitted
You are encouraged to discuss the assessment with other students but the code you submit must be yours alone. Clear similarities in code, in the write-up or in the results, will be taken as evidence of group work (for instance if identical or very similar tables of results are given, or if code is clearly shared.)
Code closely modelled on that from other sources is not permitted
Code to perform components of this exercise is likely be found in various places and might, for instance, be downloadable from the web. Use of code taken from, or cosmetically altered from, such sources is not permitted. You must devise your code from scratch.
Specifically excluded from this prohibition is code I have declared that you may use. In particular you may use the library code I have made available and the code “MC_v0_plain”, without attribution.
Project 1 3