Re: bond spreads/option adjusted spreads

[FORNAROLA CHIARA]

Hi Allen,

 

for non callable bonds you calculate the Z-spread which is the required shift to the  zero-cpn rates so that when you sum the value of the bond’s discounted payments, you get the observed market price of the bond. For bonds with embedded options, such as callable bonds, the z-spread is often not meaningful. This is because it is usually not appropriate to value a callable bond simply by discounting its scheduled payments. To value a callable bond properly, a model that explicitly takes into account volatility in interest rates is needed, so that the risk of the bond being called can be taken into account.

Considered a stochastic term structure model, this will take as input a curve of zero cpn interest rates and some parameters determining the volatility of these interest rates. >From these inputs the model generates a large number of possible scenarios for futures interest rates. A callable bond then is valued by first discounting the cashflows of the security in each scenario separately and then averaging over all the scenarios. Given this assumptions, the OAS is simply the constant absolute shift to the zero cpn rates in all scenario that is requires to ensure that the model value of the bond equals the market price. For bonds without embedded options, the OAS is exactly the same as the Z-spread (when adjusting for the proper daycount and coumpounding conventions).

I hope this will help to clarify the difference between the two kinds of spread you mentioned.

 

Chiara

p.s.

Regarding, Z-spread, in the next release you’ll find in the bond class cleanPriceFromZSpread and dirtyPriceFromZSpread.

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Allen Kuo
Sent: Sunday, July 15, 2007 10:06 AM
To: [hidden email]
Subject: [Quantlib-dev] bond spreads/option adjusted spreads

 

Hi:

 

I am interested in calculating the spread over a reference zero curve (Fabozzi's "zero volatility spread") for a bond. I would approach via Newton Raphson iteration, varying the spread (using ZeroSpreadedTermStructure) to make NPV() match the market quote on the bond. I would look to create a method under Bond to do this, e.g. myBond.zeroVolSpread(Handle<Quote> marketQuoteCleanPrice).

 

What I was ultimately trying to get at was the CallableFixedRateBond "option adjusted spread" (OAS). I was looking at Fabozzi and his OAS for a callable bonds was the constant rate added to all the nodes on his binomial short rate tree that make the NPV equal the observed market price. Isn't  the spread over the tree a spread over forward rates, rather than zero rates ? Could I instead compute the spread the same way as I do for a non-callable bond, as mentioned above, by varying the spread over the input reference zero curve so that the the forward rate tree gets "raised" by the spread automatically/implicitly when you do this ? This would be easier than to go into the ShortRateModel and add the spread to each node of the tree.

 

Thanks,

GZH

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Toyin Akin]

Hi,

I've been reading up on some of QuantLibXL docs and came across a potential
issue with the way QuantLib is designed when run on Excel 2007 with
dual/quad core machines.

I found the following snippet on the web...

#######################################################
To a large number of customers, Excel’s calculation speed is extremely
important – perhaps the most important “feature” we ship.  When planning
Excel 12, we started a small investigation to look at different ways we
could make Excel calculate faster on computers that had multi-processor or
dual-core chips.  The investigation turned out to be promising, so we
continued the work, and the result is a very exciting feature that we refer
to as multi-threaded calculation, or MTC.  (Note – this is another working
name, not a final name.  Also note that our developers refer to this as MTR,
or multi-threaded recalculation, but since most customers use the word
calculation, I have decided to go that route for this post.)

In a nutshell, this feature enables Excel to spot formulas that can be
calculated concurrently, and then run those formulas on multiple processors
simultaneously.  The net effect is that a given spreadsheet finishes
calculating in less time, improving Excel’s overall calculation performance.
  Excel 12 can take advantage of as many processors (or cores, which to
Excel appear as processors) as there are on a machine - when Excel loads a
workbook, it asks the operating system how many processors are available,
and it creates a thread for each processor.  In general, the more
processors, the better the performance improvement.
#######################################################

This tells me that due to the way that evaluationDate() is handled in
QuantLib, it *MAY* be possible to mis-price deals because one thread may set
the value of the evaluation date while another then uses the changed value.
Within Excel 2003, this is not possible.

I haven't tested this, but maybe one has to be carefull how evalDate() is
used on spreadsheets (one centralised location and not scattered across
spreadsheets). This may restrict how some spreadsheets are designed.

Can someone look into this? Is this really an issue?

More info on this can be gleamed here...

http://blogs.msdn.com/officerocker/archive/2006/08/17/704242.aspx

or google for "excel 2007 multithreaded dual core"

Toy out...

_________________________________________________________________
Got a favourite clothes shop, bar or restaurant? Share your local knowledge  
http://www.backofmyhand.com



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Allen Kuo]

Hi Chiara: Thank you for your reply.

 

Given this assumptions, the OAS is simply the constant absolute shift to the zero cpn rates in all scenario that is requires to ensure that the model value of the bond equals the market price.

 

The only thing I was getting confused about was that in all the "scenarios" (e.g. all the nodes on a tree for a lattice method),  i thought those rates were forward rates, not zero rates.

 

Fabozzi does exactly what you are saying above- you model the tree (of forward rates, I thought) and find the constant rate when added to all the nodes that reprices the bond correctly. I can do it that way but... is it right ? I thought the OAS was defined as a spread over zero rates, not the forward rates.

 

Best, GZH

 

 

 

 

 

On 7/24/07, FORNAROLA CHIARA <[hidden email]> wrote:

Hi Allen,

 

for non callable bonds you calculate the Z-spread which is the required shift to the  zero-cpn rates so that when you sum the value of the bond's discounted payments, you get the observed market price of the bond. For bonds with embedded options, such as callable bonds, the z-spread is often not meaningful. This is because it is usually not appropriate to value a callable bond simply by discounting its scheduled payments. To value a callable bond properly, a model that explicitly takes into account volatility in interest rates is needed, so that the risk of the bond being called can be taken into account.

Considered a stochastic term structure model, this will take as input a curve of zero cpn interest rates and some parameters determining the volatility of these interest rates. From these inputs the model generates a large number of possible scenarios for futures interest rates. A callable bond then is valued by first discounting the cashflows of the security in each scenario separately and then averaging over all the scenarios. Given this assumptions, the OAS is simply the constant absolute shift to the zero cpn rates in all scenario that is requires to ensure that the model value of the bond equals the market price. For bonds without embedded options, the OAS is exactly the same as the Z-spread (when adjusting for the proper daycount and coumpounding conventions).

I hope this will help to clarify the difference between the two kinds of spread you mentioned.

 

Chiara

p.s.

Regarding, Z-spread, in the next release you'll find in the bond class cleanPriceFromZSpread and dirtyPriceFromZSpread.

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Allen Kuo
Sent: Sunday, July 15, 2007 10:06 AM
To: [hidden email]
Subject: [Quantlib-dev] bond spreads/option adjusted spreads

 

Hi:

 

I am interested in calculating the spread over a reference zero curve (Fabozzi's "zero volatility spread") for a bond. I would approach via Newton Raphson iteration, varying the spread (using ZeroSpreadedTermStructure) to make NPV() match the market quote on the bond. I would look to create a method under Bond to do this, e.g. myBond.zeroVolSpread(Handle<Quote> marketQuoteCleanPrice).

 

What I was ultimately trying to get at was the CallableFixedRateBond "option adjusted spread" (OAS). I was looking at Fabozzi and his OAS for a callable bonds was the constant rate added to all the nodes on his binomial short rate tree that make the NPV equal the observed market price. Isn't  the spread over the tree a spread over forward rates, rather than zero rates ? Could I instead compute the spread the same way as I do for a non-callable bond, as mentioned above, by varying the spread over the input reference zero curve so that the the forward rate tree gets "raised" by the spread automatically/implicitly when you do this ? This would be easier than to go into the ShortRateModel and add the spread to each node of the tree.

 

Thanks,

GZH

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Wed, 2007-07-25 at 01:08 -0400, Zhonghua Guo wrote:
> The only thing I was getting confused about was that in all the
> "scenarios" (e.g. all the nodes on a tree for a lattice method),  i
> thought those rates were forward rates, not zero rates.
>  
> Fabozzi does exactly what you are saying above- you model the tree (of
> forward rates, I thought) and find the constant rate when added to all
> the nodes that reprices the bond correctly. I can do it that way
> but... is it right ? I thought the OAS was defined as a spread
> over zero rates, not the forward rates.

Zero rates are averages of forward rates. If the spread over the
forwards is constant, it results in the same spread on zero rates.

Later,
        Luigi

--

Don't say "yes" until I finish talking.
-- Darryl F. Zanuck



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[eric ehlers]

Hi Toyin,

On 7/25/07, Toyin Akin <[hidden email]> wrote:
> Hi,
>
> I've been reading up on some of QuantLibXL docs and came across a potential
> issue with the way QuantLib is designed when run on Excel 2007 with
> dual/quad core machines.

When an XLL registers a function with Excel, the XLL may pass an
additional new parameter recognized by Excel 2007 to indicate that the
function is thread safe.  Excel 2007 invokes an XLL's functions in
parallel only if they have been registered as thread safe.

In other words, we can take our existing code as-is and run it under
Excel 2007 and it should behave exactly as it did under earlier
versions of Excel, with all calculations running in a single thread.

Of course longer term we would like to take advantage of
multithreading, and as you mention we would need to take account of
QuantLib's processing of the evaluation date.  One simple approach
would be to implement a startup routine which explicilty sets the
evaluation date in each thread to be used by the XLL.

Regards,
Eric

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Toyin Akin]

Hey Eric,

That's pretty cool.

Thanks for the update. I've just obtained a couple of new dual core servers
to test stuff on...

Toy out.

>From: "eric ehlers" <[hidden email]>
>To: "Toyin Akin" <[hidden email]>
>CC: [hidden email],[hidden email]
>Subject: Re: [Quantlib-users] QuantLibXL, Office 2007, dual core
>machines...
>Date: Mon, 30 Jul 2007 11:10:53 +0200
>
>Hi Toyin,
>
>On 7/25/07, Toyin Akin <[hidden email]> wrote:
> > Hi,
> >
> > I've been reading up on some of QuantLibXL docs and came across a
>potential
> > issue with the way QuantLib is designed when run on Excel 2007 with
> > dual/quad core machines.
>
>When an XLL registers a function with Excel, the XLL may pass an
>additional new parameter recognized by Excel 2007 to indicate that the
>function is thread safe.  Excel 2007 invokes an XLL's functions in
>parallel only if they have been registered as thread safe.
>
>In other words, we can take our existing code as-is and run it under
>Excel 2007 and it should behave exactly as it did under earlier
>versions of Excel, with all calculations running in a single thread.
>
>Of course longer term we would like to take advantage of
>multithreading, and as you mention we would need to take account of
>QuantLib's processing of the evaluation date.  One simple approach
>would be to implement a startup routine which explicilty sets the
>evaluation date in each thread to be used by the XLL.
>
>Regards,
>Eric
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>QuantLib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

_________________________________________________________________
The next generation of Hotmail is here!  http://www.newhotmail.co.uk


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev