Multi-asset options

[Neil P Firth]

Hello,

I'm looking at coding up some multi-asset options, so that I can try out
the Least Squares Monte Carlo algorithm in a realistic, multi-asset case.
I am going to start with the basic two asset basket, calls and puts on the
max and min. This just requires the bivariate normal, which is in the
library already.

There are some library design issues, however. The current Option class
seems to be inherently single asset, as it has a Payoff as a data member
and Payoff calculates the value from a (double price). This needs to be
more general to deal with, say, a vector of prices. As this would no doubt
involve some major changes I thought it best to get a discussion going
before changing anything!

Any suggestions?

Neil

---------------------------------------------------
  Neil Firth
  Brasenose College Oxford OX1 4AJ United Kingdom
  Office: 01865 280616
  [hidden email]
  http://www.maths.ox.ac.uk/~firth
---------------------------------------------------

[Ferdinando M. Ametrano-3]

Hi Neil

>I'm looking at coding up some multi-asset options [...]
>There are some library design issues, however. The current Option class
>seems to be inherently single asset, as it has a Payoff as a data member
>and Payoff calculates the value from a (double price). This needs to be
>more general to deal with, say, a vector of prices.

As long as the payoff is calculated comparing a double against the (double)
strike the current interface could work for multi-asset options too.
I agree that the label "price" for the double to be compared against the
strike is inappropriate, as it could be the min/max between multiple
prices, the average of different prices, etc.

Please let me know if I'm missing something

ciao -- Nando  

[Neil P Firth]

> >I'm looking at coding up some multi-asset options [...]
> >There are some library design issues, however. The current Option class
> >seems to be inherently single asset, as it has a Payoff as a data member
> >and Payoff calculates the value from a (double price). This needs to be
> >more general to deal with, say, a vector of prices.
>
> As long as the payoff is calculated comparing a double against the (double)
> strike the current interface could work for multi-asset options too.
> I agree that the label "price" for the double to be compared against the
> strike is inappropriate, as it could be the min/max between multiple
> prices, the average of different prices, etc.
>
> Please let me know if I'm missing something
>

I'm thinking of weigthed baskets, with payoffs such as:

\Sum_{i=0}^{n} w_i S_i - K

or

\max(S_1, S_2, S_3) - K

or

\min(S_1, S_2, S_3) - K

You can have a call or a put. Some code is required to define and
calculate the sum, max, or min at the expiry time. As the current Payoff
only allows (double price) this would have to be calculated elsewhere.
I'm thinking of having a BasketOption which is created using a Payoff and
a BasketPayoff which calls the Payoff object.

To calculate the payoff you would call

double finalOptionValue = payoff(basketPayoff(assetPriceVector));

where the payoff would be Call or Put, the basketPayoff would return the
max, min, k^th best, k^th worst, or whatever, asset price in the
assetPriceVector. I'll code it up like that and see how it works.

Neil

[Luigi Ballabio-2]

On 2004.01.21 14:46, Neil P Firth wrote:

>>>I'm looking at coding up some multi-asset options [...]
>
> I'm thinking of weigthed baskets, with payoffs such as:
>
> \Sum_{i=0}^{n} w_i S_i - K
>
> or
>
> \max(S_1, S_2, S_3) - K
>
> or
>
> \min(S_1, S_2, S_3) - K
>
> You can have a call or a put. Some code is required to define and
> calculate the sum, max, or min at the expiry time. As the current
> Payoff only allows (double price) this would have to be calculated  
> elsewhere.
> I'm thinking of having a BasketOption which is created using a Payoff  
> and a BasketPayoff which calls the Payoff object.
>
> To calculate the payoff you would call
>
> double finalOptionValue = payoff(basketPayoff(assetPriceVector));

Neil,
        while I'm not yet extremely familiar with what Nando had in  
mind, I think this is the right way to go. One would do the same with  
e.g. Asian options, where the value on a realized path could be written

    double value = payoff(average(fixings));

and the payoff would be described a simple Call/Put with strike k.
Nando, can you comment on this?

Later,
        Luigi

[Ferdinando M. Ametrano-3]

Hi all

it seems like we all agree. Sorry if my first reply was not clear enough.

The idea is that as long as I can calculate the payoff:

    double value = payoff(f(...));

the current Payoff classes are ok.

The f function could be max, min, average, whatever, with as many arguments
you need.

ciao -- Nando

[Wujiang Lou]

What about some other idea like this:

//state is a vector of double
template <int N=1>
class State<N>;

//class D is a date, in years (double), in num of days( int), and your Date
class.
// A path is a function mapping time D to State<N>.
template <class D, int N=1>
class Path;

template<class D, int N>
class Payoff
{
public:
 virtual ~Payoff() {}
 virtual double operator()(D t, const State<N> & s) const = 0;
 virtual double operator()(D t, const Path<D, N>& p) const = 0;
};

Cheers,


Ferdinando Ametrano wrote:

> Hi all
>
> it seems like we all agree. Sorry if my first reply was not clear enough.
>
> The idea is that as long as I can calculate the payoff:
>
>     double value = payoff(f(...));
>
> the current Payoff classes are ok.
>
> The f function could be max, min, average, whatever, with as many arguments
> you need.
>
> ciao -- Nando
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

--
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation.  Morgan Stanley
may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers.  This may refer to
a research analyst/research report. Unless indicated, these views are the
author's and may differ from those of Morgan Stanley research or others in the
Firm. We do not represent this is accurate or complete and we may not update
this.  Past performance is not indicative of future returns. For additional
information, research reports and important disclosures, contact me or see
https://secure.ms.com.  You should not use email to request, authorize or
effect the purchase or sale of any security or instrument, to send transfer
instructions, or to effect any other transactions.  We cannot guarantee that
any such requests received via email will be processed in a timely manner.
This communication is solely for the addressee(s) and may contain confidential
information.  We do not waive confidentiality by mistransmission.  Contact me
if you do not wish to receive these communications.  In the UK, this
communication is directed in the UK to those persons who are market
counterparties or intermediate customers (as defined in the UK Financial
Services Authority's rules).

[Luigi Ballabio-2]

Hi,

On 2004.01.21 17:31, Wujiang Lou wrote:
> What about some other idea like this:
>
> //state is a vector of double
> template <int N=1>
> class State<N>;

Hmm, I'm not sure that I like it. Does that mean that a basket option  
would be templated on the number of assets? I'd rather keep the  
possibility to set it at run-time (in which case State looks very much  
like a typedef to std::vector.) Not only that--an Asian option could be  
priced with e.g. a MC simulation (where N = number of fixings) or an  
analytic formula (where N = 1). In this case too, I'd like to have the  
choice at run-time.

> template<class D, int N>
> class Payoff
> {
> public:
>  virtual double operator()(D t, const State<N> & s) const = 0;

or
virtual double operator()(D t, const std::vector<double>& s) const = 0;
if we want the choice of N at run-time.

As for the date, I think that time is taken care of by the Exercise  
instance. Keeping them separated might ease composition.

As for the vector, the same might apply---but I'd prefer Nando to step  
in at this time...

Later,
        Luigi

[Ferdinando M. Ametrano-3]

Hi Wujiang

>template<class D, int N>
>class Payoff
>{
>public:
>  virtual ~Payoff() {}
>  virtual double operator()(D t, const State<N> & s) const = 0;
>  virtual double operator()(D t, const Path<D, N>& p) const = 0;

in the current QuantLib design Payoff just encapsulate max(S-K, 0),
max(K-S,0), etc
The operator()(D t, const Path<D, N>& p) is similar to the PathPricer
interface double operator()(Path), and I wouldn't favour the mixing of the
payoff/pathpricer concept until I understand which benefit we would obtain.

In the current framework a PathPricer takes care to calculate for each Path
(single or multi-asset) the double referenceValue that Payoff::operator()
requires as input

ciao -- Nando

[Neil P Firth]

Hello,

I've checked in a first attempt for the European call on the max basket of
two assets priced in the Stulz (1982) paper. He also has parity results
for the min basket and for the put options. There is a MultiAssetOption
superclass and a BasketOption subclass. The engine is called StulzEngine
and the test cases are in basketoption.cpp in the test suite. I have also
put an Excel spreadsheet on my website:
http://www.maths.ox.ac.uk/~firth/

The obvious next step for me is to replicate these numbers with a Monte
Carlo basket engine. There is a multipath generator, but I don't think it
is in use at the moment. Any advice?

I have yet to create the basket payoff functions that we were dicussing
earlier.

Thanks,

Neil

---------------------------------------------------
  Neil Firth
  Brasenose College Oxford OX1 4AJ United Kingdom
  Office: 01865 280616
  [hidden email]
  http://www.maths.ox.ac.uk/~firth
---------------------------------------------------

[Wujiang Lou]

Hi,
  The benefit of a more sophisticated Payoff class is that it allows pricing to
be decomposed into modeling phase and computing phase. By modeling I mean the
things quant does to arrive at model dynamics (SDE) and economics (cashflow,
payoff etc.) while computing is simply a numerical/analytical procedure to
solve the SDE, whether  closed form, finite difference, MC, lattice, etc.
   In the asian option example Luigi mentioned, the MC method is modeling asset
price as a SDE while the analytic formula the avearged asset price
approximately. You see here the modeling phase one comes out different SDEs.
    The real advantage of such a separation is, as soon as you've arrived your
SDE and payoffs, existing solutions / tools may be reused to compute it.
Black-Scholes formula for example can be used without modification and you
don't need to write a AsianOptionBlackScholesPricer. In fact, all your 1-D
trees, 1-D finite differences work as well, in a similar manner to plug-n-play.
With this design I can see the number of Pricers in quantlib can be
significantly reduced without lossing any pricing capability. (That was the
exact reason I came across this design in my earlier job. Jus t name this:
OptBSPricer, OptBinTreePricer, OptFDPricer; QuantoBSPricer,
QuantoBinTreePricer, QuantoFDPricer; ... repeat that list with CompositeOpt,
FuturesOpt,  DigitalOpt, ... Eventually the list of pricers grows
unmanageably.)
    I think we're already seeing the list grow a lot in QuantLib. May be a good
time to revisit it a little bit.
Best,
-Wujiang

Ferdinando Ametrano wrote:

> Hi Wujiang
>
> >template<class D, int N>
> >class Payoff
> >{
> >public:
> >  virtual ~Payoff() {}
> >  virtual double operator()(D t, const State<N> & s) const = 0;
> >  virtual double operator()(D t, const Path<D, N>& p) const = 0;
>
> in the current QuantLib design Payoff just encapsulate max(S-K, 0),
> max(K-S,0), etc
> The operator()(D t, const Path<D, N>& p) is similar to the PathPricer
> interface double operator()(Path), and I wouldn't favour the mixing of the
> payoff/pathpricer concept until I understand which benefit we would obtain.
>
> In the current framework a PathPricer takes care to calculate for each Path
> (single or multi-asset) the double referenceValue that Payoff::operator()
> requires as input
>
> ciao -- Nando
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

--
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation.  Morgan Stanley
may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers.  This may refer to
a research analyst/research report. Unless indicated, these views are the
author's and may differ from those of Morgan Stanley research or others in the
Firm. We do not represent this is accurate or complete and we may not update
this.  Past performance is not indicative of future returns. For additional
information, research reports and important disclosures, contact me or see
https://secure.ms.com.  You should not use email to request, authorize or
effect the purchase or sale of any security or instrument, to send transfer
instructions, or to effect any other transactions.  We cannot guarantee that
any such requests received via email will be processed in a timely manner.
This communication is solely for the addressee(s) and may contain confidential
information.  We do not waive confidentiality by mistransmission.  Contact me
if you do not wish to receive these communications.  In the UK, this
communication is directed in the UK to those persons who are market
counterparties or intermediate customers (as defined in the UK Financial
Services Authority's rules).

[Ferdinando M. Ametrano-3]

Hi Wujiang

>   The benefit of a more sophisticated Payoff class is that it allows
> pricing to
>be decomposed into modeling phase and computing phase. By modeling I mean the
>things quant does to arrive at model dynamics (SDE) and economics (cashflow,
>payoff etc.) while computing is simply a numerical/analytical procedure to
>solve the SDE, whether  closed form, finite difference, MC, lattice, etc.

In QuantLib this is achieved using StochasticProcess and DiffusionProcess
for the modelling phase, Instruments for the economics, and PricingEngine
for the numerical/analytical procedures.

>     The real advantage of such a separation is, as soon as you've arrived
> your
>SDE and payoffs, existing solutions / tools may be reused to compute it.
Indeed this is the major reason behind the new
Instrument/StochasticProcess/PricingEngine framework. In this framework the
Payoff class is just a terminal/boundary condition provided by the
Instrument and used by the PricingEngine.

>Black-Scholes formula for example can be used without modification and you
>don't need to write a AsianOptionBlackScholesPricer. In fact, all your 1-D
>trees, 1-D finite differences work as well, in a similar manner to
>plug-n-play.
>With this design I can see the number of Pricers in quantlib can be
>significantly reduced without lossing any pricing capability. (That was the
>exact reason I came across this design in my earlier job. Jus t name this:
>OptBSPricer, OptBinTreePricer, OptFDPricer; QuantoBSPricer,
>QuantoBinTreePricer, QuantoFDPricer; ... repeat that list with CompositeOpt,
>FuturesOpt,  DigitalOpt, ... Eventually the list of pricers grows
>unmanageably.)
>     I think we're already seeing the list grow a lot in QuantLib. May be
> a good
>time to revisit it a little bit.

My impression is that you're referring to the old QuantLib Pricer
framework. This problem has been solved in the new framework, even if not
all old Pricers have been ported to the new framework yet.

Even if slightly outdated I suggest you read QuEP 5 "Using replaceable
pricing engines in option implementations"
(http://quantlib.org/quep/quep005.html), then take a look at the code under
ql\PricingEngines.

Of course I might be just missing your point, in which case please forgive
me and try again: your contribution is appreciated.

ciao -- Nando

[Ferdinando M. Ametrano-3]

Hi Neil

I've extended your code to handle dividends: it was nothing more than using
forward values instead of spot (and variances instead of vols).

Forward/variance is always my favorite approach vs spot/vol for European
options (and spot/variance for American options). This is also because it
removes any problem about the definition of time to maturity which is
dependent on the day count, and one can have different day count
conventions for the volatility, risk-free rate, and dividend term structures.

I've also added few test cases from "Option Pricing Formulas", Haug, 1998
to the test suite.

For those interested, it would be worthwhile to compare the current
two-asset code with the single-asset blackformula.hpp: it shows the natural
path toward American and European digital two-asset options with
cash/asset-at-hit/expiry payoff.

Thank you very much for your contribution, I look forward to the Monte
Carlo simulation engine.

ciao -- Nando

[Ferdinando M. Ametrano-3]

Hi Neil

>I've checked in a first attempt for the European call on the max basket of
>two assets priced in the Stulz (1982) paper. He also has parity results
>for the min basket and for the put options.
I am considering the usage of analytic formulas for max/min call/put,
reserving parity results as validating tests. Any opinion about this approach?

>The obvious next step for me is to replicate these numbers with a Monte
>Carlo basket engine. There is a multipath generator, but I don't think it
>is in use at the moment. Any advice?
The old multipath generator (that is multi-asset path generator) is used by
the old QuantLib Pricers, but it has never been used in the new pricing
engine framework.
Besides there should be a new multipath generator along the lines of the
old/new single-asset path generator, but I don't think it has been finished
yet.
I hope to look into this next week.

>I have yet to create the basket payoff functions that we were dicussing
>earlier.
it still escapes me what is wrong with the current Payoff class. I will try
to refactor the two-assets min/max code not using parity results to stress
the Payoff usage, and I'm willing to take a look at which kind of needs
will emerge that require a multi-asset Payoff class.

ciao -- Nando