QuantLib › quantlib-dev

CDS last period

Classic

List

Threaded

20 messages Options

Peter Caspers-4

CDS last period

Hi,

the days in the last period of a CDS are usually counted as (d2-d1+1),
i.e. including the first and the last date. I might miss something but
this seems not possible in the current implementation of the credit
default swap? This would be my plan to fix that:

1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
to FixedRateLeg and extend the Leg() operator accordingly
3. Add a parameter const DayCounter& lastPeriodDayCounter =
DayCounter() to the CreditDefaultSwap constructors and invoke
withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
parameter is not empty

Maybe one could also default the dayCounter to Actual360() and the
lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
constructors already to match the usual use case?

Does that make sense?

Thank you
Peter

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

japari

Re: CDS last period

Hi,
True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
contracts too.

Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
time).

See:
*The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
p.18 Markit March 2009
*Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009 p.4
*The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64

Do you mind having a look on this too, pls? To have someone elses opinion.

And another related point to the new convention intial accrual is that I have also patched the
constructors moving this:
QL_REQUIRE(protectionStart_ <= schedule[0],
"protection can not start after accrual");
which used to be true in the old convention,
into this:
QL_REQUIRE((protectionStart_ <= schedule[0])
|| (schedule.rule() == DateGeneration::Rule::CDS),
"protection can not start after accrual");
since now it can be the case that the protection period starts before T+1 (actually T-60) but
rather than my hacks it might be better to leave it open completely;

Best
pp

----- Mail original -----
De: "Peter Caspers" <[hidden email]>
À: [hidden email]
Envoyé: Dimanche 7 Octobre 2012 20:49:53
Objet: [Quantlib-dev] CDS last period

Hi,

the days in the last period of a CDS are usually counted as (d2-d1+1),
i.e. including the first and the last date. I might miss something but
this seems not possible in the current implementation of the credit
default swap? This would be my plan to fix that:

1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
to FixedRateLeg and extend the Leg() operator accordingly
3. Add a parameter const DayCounter& lastPeriodDayCounter =
DayCounter() to the CreditDefaultSwap constructors and invoke
withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
parameter is not empty

Maybe one could also default the dayCounter to Actual360() and the
lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
constructors already to match the usual use case?

Does that make sense?

Thank you
Peter

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Peter Caspers-4

Re: CDS last period

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual
rebate can be handled via the upfront amount, i.e. if you provide the
dirty upfront amount you get what is standard now, don't you? So no need
for an extension unless (and that's what you are probably pointing at?)
you want automatic computation of the accrual rebate amount. Btw I
think the upfront payment is usually done on T + 3 open days (not T+1),
is that correct?

What I planned however is to implement a CDS bootstrap helper which can
pay a full first coupon and an accrual rebate (computed from last roll
date to T+1) on T+3. In fact the spreads provided by markit are meant
using this convention rather than paying a short first coupon, at least
some guy working there told me so. Can you validate this? Admittedly
this makes only a little difference in the bootstrapped curve in
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb [hidden email]:

> Hi,
> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
> contracts too.
>
> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
> time).
>
> See:
> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
> p.18 Markit March 2009
> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009 p.4
> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>
> Do you mind having a look on this too, pls? To have someone elses opinion.
>
> And another related point to the new convention intial accrual is that I have also patched the
> constructors moving this:
> QL_REQUIRE(protectionStart_ <= schedule[0],
> "protection can not start after accrual");
> which used to be true in the old convention,
> into this:
> QL_REQUIRE((protectionStart_ <= schedule[0])
> || (schedule.rule() == DateGeneration::Rule::CDS),
> "protection can not start after accrual");
> since now it can be the case that the protection period starts before T+1 (actually T-60) but
> rather than my hacks it might be better to leave it open completely;
>
> Best
> pp
>
> ----- Mail original -----
> De: "Peter Caspers" <[hidden email]>
> À: [hidden email]
> Envoyé: Dimanche 7 Octobre 2012 20:49:53
> Objet: [Quantlib-dev] CDS last period
>
> Hi,
>
> the days in the last period of a CDS are usually counted as (d2-d1+1),
> i.e. including the first and the last date. I might miss something but
> this seems not possible in the current implementation of the credit
> default swap? This would be my plan to fix that:
>
> 1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
> 2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
> to FixedRateLeg and extend the Leg() operator accordingly
> 3. Add a parameter const DayCounter& lastPeriodDayCounter =
> DayCounter() to the CreditDefaultSwap constructors and invoke
> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
> parameter is not empty
>
> Maybe one could also default the dayCounter to Actual360() and the
> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
> constructors already to match the usual use case?
>
> Does that make sense?
>
> Thank you
> Peter
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

japari

Re: CDS last period

Sorry, yes your right settlement is T+3 for upfront and accrual rebate
computed to T+1.

Yes, thats what I think too. I have my engines patched to bootstrap that way,
its not a big change. Small difference yes, still it can be seen as a 3M
oscillation.

On the way Markit works that was my assumption for the upfront quotes,
Markit's 'standard cds contract converter specification' mentions
this on p.3, section 'solving for the constant hazard rate'; there it
says that the upfront does not include the rebate. So their quotes must
be that way.
A way to test minimum coherence is to compute with QL the conventional
spread Markit quotes alongside and I get agreement or 1bp difference
at max (for a ~100bp conventional level of spreads). Which is quite decent
considering that it is not rare to see Markit converting the same upfront
quote by two sources on the same day to two different conv spreads (by 1bp).
Also when I did this I was using the yieldTS from T, not T-1 as the converter
mandates. I was not far from the last standard coupon date though, that makes
agreement easier; I was too lazy to follow this with time...

Best regards
Pepe

----- Mail original -----
De: "Peter Caspers" <[hidden email]>
À: [hidden email]
Cc: [hidden email]
Envoyé: Mardi 9 Octobre 2012 22:00:06
Objet: Re: [Quantlib-dev] CDS last period

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual
rebate can be handled via the upfront amount, i.e. if you provide the
dirty upfront amount you get what is standard now, don't you? So no need
for an extension unless (and that's what you are probably pointing at?)
you want automatic computation of the accrual rebate amount. Btw I
think the upfront payment is usually done on T + 3 open days (not T+1),
is that correct?

What I planned however is to implement a CDS bootstrap helper which can
pay a full first coupon and an accrual rebate (computed from last roll
date to T+1) on T+3. In fact the spreads provided by markit are meant
using this convention rather than paying a short first coupon, at least
some guy working there told me so. Can you validate this? Admittedly
this makes only a little difference in the bootstrapped curve in
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb [hidden email]:

japari

Re: CDS last period

Couldnt help it: The conventional spread conversion is a good proxy to check
things like the accrual rebate or other features like the one you mentioned
initially in this post.

Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS
(should have used yesterday though). These are my figures and Markits quotes:

Without and with accrual rebate in both bootstrapping and pricing/conversion:

Mkit 5Y conv QL NoR QL+Rebt
upfront=11 for 5Y lowest bid: 443 439.21 443.38
upfront=14.5 for 5Y highest ask: 506 499.28 504.30

The correction you propose is still missing. With an artificil fix (adding 1
day to the last coupon in the pricing):
443.24
504.15

Regards
Pepe

----- Mail original -----
De: [hidden email]
À: "Peter Caspers" <[hidden email]>
Cc: [hidden email]
Envoyé: Mercredi 10 Octobre 2012 13:43:14
Objet: Re: [Quantlib-dev] CDS last period

Sorry, yes your right settlement is T+3 for upfront and accrual rebate
computed to T+1.

Yes, thats what I think too. I have my engines patched to bootstrap that way,
its not a big change. Small difference yes, still it can be seen as a 3M
oscillation.

On the way Markit works that was my assumption for the upfront quotes,
Markit's 'standard cds contract converter specification' mentions
this on p.3, section 'solving for the constant hazard rate'; there it
says that the upfront does not include the rebate. So their quotes must
be that way.
A way to test minimum coherence is to compute with QL the conventional
spread Markit quotes alongside and I get agreement or 1bp difference
at max (for a ~100bp conventional level of spreads). Which is quite decent
considering that it is not rare to see Markit converting the same upfront
quote by two sources on the same day to two different conv spreads (by 1bp).
Also when I did this I was using the yieldTS from T, not T-1 as the converter
mandates. I was not far from the last standard coupon date though, that makes
agreement easier; I was too lazy to follow this with time...

Best regards
Pepe

----- Mail original -----
De: "Peter Caspers" <[hidden email]>
À: [hidden email]
Cc: [hidden email]
Envoyé: Mardi 9 Octobre 2012 22:00:06
Objet: Re: [Quantlib-dev] CDS last period

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual
rebate can be handled via the upfront amount, i.e. if you provide the
dirty upfront amount you get what is standard now, don't you? So no need
for an extension unless (and that's what you are probably pointing at?)
you want automatic computation of the accrual rebate amount. Btw I
think the upfront payment is usually done on T + 3 open days (not T+1),
is that correct?

What I planned however is to implement a CDS bootstrap helper which can
pay a full first coupon and an accrual rebate (computed from last roll
date to T+1) on T+3. In fact the spreads provided by markit are meant
using this convention rather than paying a short first coupon, at least
some guy working there told me so. Can you validate this? Admittedly
this makes only a little difference in the bootstrapped curve in
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb [hidden email]:

japari

Re: CDS last period

Hi,
shall we do anything about this? Do you want to implement the day counter and I can
change the engines for the rebate?
Can anyone else give an opinion?
Best
Pepe

----- Mail original -----
De: [hidden email]
À: "Peter Caspers" <[hidden email]>
Cc: [hidden email]
Envoyé: Mercredi 10 Octobre 2012 18:59:28
Objet: Re: [Quantlib-dev] CDS last period

Couldnt help it: The conventional spread conversion is a good proxy to check
things like the accrual rebate or other features like the one you mentioned
initially in this post.

Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS
(should have used yesterday though). These are my figures and Markits quotes:

Without and with accrual rebate in both bootstrapping and pricing/conversion:

Mkit 5Y conv QL NoR QL+Rebt
upfront=11 for 5Y lowest bid: 443 439.21 443.38
upfront=14.5 for 5Y highest ask: 506 499.28 504.30

The correction you propose is still missing. With an artificil fix (adding 1
day to the last coupon in the pricing):
443.24
504.15

Regards
Pepe

----- Mail original -----
De: [hidden email]
À: "Peter Caspers" <[hidden email]>
Cc: [hidden email]
Envoyé: Mercredi 10 Octobre 2012 13:43:14
Objet: Re: [Quantlib-dev] CDS last period

Sorry, yes your right settlement is T+3 for upfront and accrual rebate
computed to T+1.

Yes, thats what I think too. I have my engines patched to bootstrap that way,
its not a big change. Small difference yes, still it can be seen as a 3M
oscillation.

On the way Markit works that was my assumption for the upfront quotes,
Markit's 'standard cds contract converter specification' mentions
this on p.3, section 'solving for the constant hazard rate'; there it
says that the upfront does not include the rebate. So their quotes must
be that way.
A way to test minimum coherence is to compute with QL the conventional
spread Markit quotes alongside and I get agreement or 1bp difference
at max (for a ~100bp conventional level of spreads). Which is quite decent
considering that it is not rare to see Markit converting the same upfront
quote by two sources on the same day to two different conv spreads (by 1bp).
Also when I did this I was using the yieldTS from T, not T-1 as the converter
mandates. I was not far from the last standard coupon date though, that makes
agreement easier; I was too lazy to follow this with time...

Best regards
Pepe

----- Mail original -----
De: "Peter Caspers" <[hidden email]>
À: [hidden email]
Cc: [hidden email]
Envoyé: Mardi 9 Octobre 2012 22:00:06
Objet: Re: [Quantlib-dev] CDS last period

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual
rebate can be handled via the upfront amount, i.e. if you provide the
dirty upfront amount you get what is standard now, don't you? So no need
for an extension unless (and that's what you are probably pointing at?)
you want automatic computation of the accrual rebate amount. Btw I
think the upfront payment is usually done on T + 3 open days (not T+1),
is that correct?

What I planned however is to implement a CDS bootstrap helper which can
pay a full first coupon and an accrual rebate (computed from last roll
date to T+1) on T+3. In fact the spreads provided by markit are meant
using this convention rather than paying a short first coupon, at least
some guy working there told me so. Can you validate this? Admittedly
this makes only a little difference in the bootstrapped curve in
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb [hidden email]:

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Peter Caspers-4

Re: CDS last period

Hi Pepe,

sure. I'll do the day counter and the last period thing in the fixed
rate leg and create a new rate helper with accrual rebate. Then we can
merge. Give me some days. I want to test against Bloomberg, the Markit
calculator and perhaps also Murex.

I guess Roland should approve the changes and the way they are done
before they enter the library.

Regards
Peter

Am 16.10.2012 12:31, schrieb [hidden email]:

> Hi,
> shall we do anything about this? Do you want to implement the day counter and I can
> change the engines for the rebate?
> Can anyone else give an opinion?
> Best
> Pepe
>
>
> ----- Mail original -----
> De: [hidden email]
> À: "Peter Caspers" <[hidden email]>
> Cc: [hidden email]
> Envoyé: Mercredi 10 Octobre 2012 18:59:28
> Objet: Re: [Quantlib-dev] CDS last period
>
> Couldnt help it: The conventional spread conversion is a good proxy to check
> things like the accrual rebate or other features like the one you mentioned
> initially in this post.
>
> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS
> (should have used yesterday though). These are my figures and Markits quotes:
>
> Without and with accrual rebate in both bootstrapping and pricing/conversion:
>
> Mkit 5Y conv QL NoR QL+Rebt
> upfront=11 for 5Y lowest bid: 443 439.21 443.38
> upfront=14.5 for 5Y highest ask: 506 499.28 504.30
>
> The correction you propose is still missing. With an artificil fix (adding 1
> day to the last coupon in the pricing):
> 443.24
> 504.15
>
> Regards
> Pepe
>
>
> ----- Mail original -----
> De: [hidden email]
> À: "Peter Caspers" <[hidden email]>
> Cc: [hidden email]
> Envoyé: Mercredi 10 Octobre 2012 13:43:14
> Objet: Re: [Quantlib-dev] CDS last period
>
>
> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
> computed to T+1.
>
> Yes, thats what I think too. I have my engines patched to bootstrap that way,
> its not a big change. Small difference yes, still it can be seen as a 3M
> oscillation.
>
> On the way Markit works that was my assumption for the upfront quotes,
> Markit's 'standard cds contract converter specification' mentions
> this on p.3, section 'solving for the constant hazard rate'; there it
> says that the upfront does not include the rebate. So their quotes must
> be that way.
> A way to test minimum coherence is to compute with QL the conventional
> spread Markit quotes alongside and I get agreement or 1bp difference
> at max (for a ~100bp conventional level of spreads). Which is quite decent
> considering that it is not rare to see Markit converting the same upfront
> quote by two sources on the same day to two different conv spreads (by 1bp).
> Also when I did this I was using the yieldTS from T, not T-1 as the converter
> mandates. I was not far from the last standard coupon date though, that makes
> agreement easier; I was too lazy to follow this with time...
>
> Best regards
> Pepe
>
>
> ----- Mail original -----
> De: "Peter Caspers" <[hidden email]>
> À: [hidden email]
> Cc: [hidden email]
> Envoyé: Mardi 9 Octobre 2012 22:00:06
> Objet: Re: [Quantlib-dev] CDS last period
>
> Hi,
>
> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
> rebate can be handled via the upfront amount, i.e. if you provide the
> dirty upfront amount you get what is standard now, don't you? So no need
> for an extension unless (and that's what you are probably pointing at?)
> you want automatic computation of the accrual rebate amount. Btw I
> think the upfront payment is usually done on T + 3 open days (not T+1),
> is that correct?
>
> What I planned however is to implement a CDS bootstrap helper which can
> pay a full first coupon and an accrual rebate (computed from last roll
> date to T+1) on T+3. In fact the spreads provided by markit are meant
> using this convention rather than paying a short first coupon, at least
> some guy working there told me so. Can you validate this? Admittedly
> this makes only a little difference in the bootstrapped curve in
> general, but why not do it correctly if you can.
>
> Kind regards
> Peter
>
> Am 09.10.2012 13:05, schrieb [hidden email]:
>> Hi,
>> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
>> contracts too.
>>
>> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
>> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
>> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
>> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
>> time).
>>
>> See:
>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
>> p.18 Markit March 2009
>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009 p.4
>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>
>> Do you mind having a look on this too, pls? To have someone elses opinion.
>>
>> And another related point to the new convention intial accrual is that I have also patched the
>> constructors moving this:
>> QL_REQUIRE(protectionStart_ <= schedule[0],
>> "protection can not start after accrual");
>> which used to be true in the old convention,
>> into this:
>> QL_REQUIRE((protectionStart_ <= schedule[0])
>> || (schedule.rule() == DateGeneration::Rule::CDS),
>> "protection can not start after accrual");
>> since now it can be the case that the protection period starts before T+1 (actually T-60) but
>> rather than my hacks it might be better to leave it open completely;
>>
>> Best
>> pp
>>
>> ----- Mail original -----
>> De: "Peter Caspers" <[hidden email]>
>> À: [hidden email]
>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>> Objet: [Quantlib-dev] CDS last period
>>
>> Hi,
>>
>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>> i.e. including the first and the last date. I might miss something but
>> this seems not possible in the current implementation of the credit
>> default swap? This would be my plan to fix that:
>>
>> 1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
>> 2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
>> to FixedRateLeg and extend the Leg() operator accordingly
>> 3. Add a parameter const DayCounter& lastPeriodDayCounter =
>> DayCounter() to the CreditDefaultSwap constructors and invoke
>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>> parameter is not empty
>>
>> Maybe one could also default the dayCounter to Actual360() and the
>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>> constructors already to match the usual use case?
>>
>> Does that make sense?
>>
>> Thank you
>> Peter
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: CDS last period

Hi all,
sorry I've been sitting out of this one. Do go ahead (only one
thing: with regard to the day counter, I'd prefer to have an
additional parameter for the existing day counter, as in
Actual360(IncludeLastDay), rather than an additional day counter).

You're also correct when you say that we'll need some expert to look
at the thing---speaking of which, how comfortable are you with git? If
you forked the QuantLib mirror I've put on github and pushed your
changes there, it would make it easier both to do a code review and to
merge the changes afterwards. No big deal if you want to just post
here though.

Thanks,
Luigi

On Tue, Oct 16, 2012 at 8:39 PM, Peter Caspers <[hidden email]> wrote:

> Hi Pepe,
>
> sure. I'll do the day counter and the last period thing in the fixed
> rate leg and create a new rate helper with accrual rebate. Then we can
> merge. Give me some days. I want to test against Bloomberg, the Markit
> calculator and perhaps also Murex.
>
> I guess Roland should approve the changes and the way they are done
> before they enter the library.
>
> Regards
> Peter
>
> Am 16.10.2012 12:31, schrieb [hidden email]:
>> Hi,
>> shall we do anything about this? Do you want to implement the day counter and I can
>> change the engines for the rebate?
>> Can anyone else give an opinion?
>> Best
>> Pepe
>>
>>
>> ----- Mail original -----
>> De: [hidden email]
>> À: "Peter Caspers" <[hidden email]>
>> Cc: [hidden email]
>> Envoyé: Mercredi 10 Octobre 2012 18:59:28
>> Objet: Re: [Quantlib-dev] CDS last period
>>
>> Couldnt help it: The conventional spread conversion is a good proxy to check
>> things like the accrual rebate or other features like the one you mentioned
>> initially in this post.
>>
>> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS
>> (should have used yesterday though). These are my figures and Markits quotes:
>>
>> Without and with accrual rebate in both bootstrapping and pricing/conversion:
>>
>> Mkit 5Y conv QL NoR QL+Rebt
>> upfront=11 for 5Y lowest bid: 443 439.21 443.38
>> upfront=14.5 for 5Y highest ask: 506 499.28 504.30
>>
>> The correction you propose is still missing. With an artificil fix (adding 1
>> day to the last coupon in the pricing):
>> 443.24
>> 504.15
>>
>> Regards
>> Pepe
>>
>>
>> ----- Mail original -----
>> De: [hidden email]
>> À: "Peter Caspers" <[hidden email]>
>> Cc: [hidden email]
>> Envoyé: Mercredi 10 Octobre 2012 13:43:14
>> Objet: Re: [Quantlib-dev] CDS last period
>>
>>
>> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
>> computed to T+1.
>>
>> Yes, thats what I think too. I have my engines patched to bootstrap that way,
>> its not a big change. Small difference yes, still it can be seen as a 3M
>> oscillation.
>>
>> On the way Markit works that was my assumption for the upfront quotes,
>> Markit's 'standard cds contract converter specification' mentions
>> this on p.3, section 'solving for the constant hazard rate'; there it
>> says that the upfront does not include the rebate. So their quotes must
>> be that way.
>> A way to test minimum coherence is to compute with QL the conventional
>> spread Markit quotes alongside and I get agreement or 1bp difference
>> at max (for a ~100bp conventional level of spreads). Which is quite decent
>> considering that it is not rare to see Markit converting the same upfront
>> quote by two sources on the same day to two different conv spreads (by 1bp).
>> Also when I did this I was using the yieldTS from T, not T-1 as the converter
>> mandates. I was not far from the last standard coupon date though, that makes
>> agreement easier; I was too lazy to follow this with time...
>>
>> Best regards
>> Pepe
>>
>>
>> ----- Mail original -----
>> De: "Peter Caspers" <[hidden email]>
>> À: [hidden email]
>> Cc: [hidden email]
>> Envoyé: Mardi 9 Octobre 2012 22:00:06
>> Objet: Re: [Quantlib-dev] CDS last period
>>
>> Hi,
>>
>> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
>> rebate can be handled via the upfront amount, i.e. if you provide the
>> dirty upfront amount you get what is standard now, don't you? So no need
>> for an extension unless (and that's what you are probably pointing at?)
>> you want automatic computation of the accrual rebate amount. Btw I
>> think the upfront payment is usually done on T + 3 open days (not T+1),
>> is that correct?
>>
>> What I planned however is to implement a CDS bootstrap helper which can
>> pay a full first coupon and an accrual rebate (computed from last roll
>> date to T+1) on T+3. In fact the spreads provided by markit are meant
>> using this convention rather than paying a short first coupon, at least
>> some guy working there told me so. Can you validate this? Admittedly
>> this makes only a little difference in the bootstrapped curve in
>> general, but why not do it correctly if you can.
>>
>> Kind regards
>> Peter
>>
>> Am 09.10.2012 13:05, schrieb [hidden email]:
>>> Hi,
>>> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
>>> contracts too.
>>>
>>> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
>>> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
>>> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
>>> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
>>> time).
>>>
>>> See:
>>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
>>> p.18 Markit March 2009
>>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009 p.4
>>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>>
>>> Do you mind having a look on this too, pls? To have someone elses opinion.
>>>
>>> And another related point to the new convention intial accrual is that I have also patched the
>>> constructors moving this:
>>> QL_REQUIRE(protectionStart_ <= schedule[0],
>>> "protection can not start after accrual");
>>> which used to be true in the old convention,
>>> into this:
>>> QL_REQUIRE((protectionStart_ <= schedule[0])
>>> || (schedule.rule() == DateGeneration::Rule::CDS),
>>> "protection can not start after accrual");
>>> since now it can be the case that the protection period starts before T+1 (actually T-60) but
>>> rather than my hacks it might be better to leave it open completely;
>>>
>>> Best
>>> pp
>>>
>>> ----- Mail original -----
>>> De: "Peter Caspers" <[hidden email]>
>>> À: [hidden email]
>>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>>> Objet: [Quantlib-dev] CDS last period
>>>
>>> Hi,
>>>
>>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>>> i.e. including the first and the last date. I might miss something but
>>> this seems not possible in the current implementation of the credit
>>> default swap? This would be my plan to fix that:
>>>
>>> 1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
>>> 2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
>>> to FixedRateLeg and extend the Leg() operator accordingly
>>> 3. Add a parameter const DayCounter& lastPeriodDayCounter =
>>> DayCounter() to the CreditDefaultSwap constructors and invoke
>>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>>> parameter is not empty
>>>
>>> Maybe one could also default the dayCounter to Actual360() and the
>>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>>> constructors already to match the usual use case?
>>>
>>> Does that make sense?
>>>
>>> Thank you
>>> Peter
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Peter Caspers-4

Re: CDS last period

Hi Luigi, Pepe, Roland,

I put my changes on a github (pcaspers) forked from Luigis. Following
Pepes case below I added a test case comparing the conventional spread
computed with ql and the traded spread in the Bloomberg (yielding
431.6945 bp in ql versus 431.6329 bp in BBG which seems quite good). The
testsuite runs without errors under the changes.

I am neither a CDS nor a quantlib expert, so it would be great if
someone could have a look ...

Peter

Am 17.10.2012 10:59, schrieb Luigi Ballabio:

> Hi all,
> sorry I've been sitting out of this one. Do go ahead (only one
> thing: with regard to the day counter, I'd prefer to have an
> additional parameter for the existing day counter, as in
> Actual360(IncludeLastDay), rather than an additional day counter).
>
> You're also correct when you say that we'll need some expert to look
> at the thing---speaking of which, how comfortable are you with git? If
> you forked the QuantLib mirror I've put on github and pushed your
> changes there, it would make it easier both to do a code review and to
> merge the changes afterwards. No big deal if you want to just post
> here though.
>
> Thanks,
> Luigi
>
> On Tue, Oct 16, 2012 at 8:39 PM, Peter Caspers <[hidden email]> wrote:
>> Hi Pepe,
>>
>> sure. I'll do the day counter and the last period thing in the fixed
>> rate leg and create a new rate helper with accrual rebate. Then we can
>> merge. Give me some days. I want to test against Bloomberg, the Markit
>> calculator and perhaps also Murex.
>>
>> I guess Roland should approve the changes and the way they are done
>> before they enter the library.
>>
>> Regards
>> Peter
>>
>> Am 16.10.2012 12:31, schrieb [hidden email]:
>>> Hi,
>>> shall we do anything about this? Do you want to implement the day counter and I can
>>> change the engines for the rebate?
>>> Can anyone else give an opinion?
>>> Best
>>> Pepe
>>>
>>>
>>> ----- Mail original -----
>>> De: [hidden email]
>>> À: "Peter Caspers" <[hidden email]>
>>> Cc: [hidden email]
>>> Envoyé: Mercredi 10 Octobre 2012 18:59:28
>>> Objet: Re: [Quantlib-dev] CDS last period
>>>
>>> Couldnt help it: The conventional spread conversion is a good proxy to check
>>> things like the accrual rebate or other features like the one you mentioned
>>> initially in this post.
>>>
>>> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS
>>> (should have used yesterday though). These are my figures and Markits quotes:
>>>
>>> Without and with accrual rebate in both bootstrapping and pricing/conversion:
>>>
>>> Mkit 5Y conv QL NoR QL+Rebt
>>> upfront=11 for 5Y lowest bid: 443 439.21 443.38
>>> upfront=14.5 for 5Y highest ask: 506 499.28 504.30
>>>
>>> The correction you propose is still missing. With an artificil fix (adding 1
>>> day to the last coupon in the pricing):
>>> 443.24
>>> 504.15
>>>
>>> Regards
>>> Pepe
>>>
>>>
>>> ----- Mail original -----
>>> De: [hidden email]
>>> À: "Peter Caspers" <[hidden email]>
>>> Cc: [hidden email]
>>> Envoyé: Mercredi 10 Octobre 2012 13:43:14
>>> Objet: Re: [Quantlib-dev] CDS last period
>>>
>>>
>>> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
>>> computed to T+1.
>>>
>>> Yes, thats what I think too. I have my engines patched to bootstrap that way,
>>> its not a big change. Small difference yes, still it can be seen as a 3M
>>> oscillation.
>>>
>>> On the way Markit works that was my assumption for the upfront quotes,
>>> Markit's 'standard cds contract converter specification' mentions
>>> this on p.3, section 'solving for the constant hazard rate'; there it
>>> says that the upfront does not include the rebate. So their quotes must
>>> be that way.
>>> A way to test minimum coherence is to compute with QL the conventional
>>> spread Markit quotes alongside and I get agreement or 1bp difference
>>> at max (for a ~100bp conventional level of spreads). Which is quite decent
>>> considering that it is not rare to see Markit converting the same upfront
>>> quote by two sources on the same day to two different conv spreads (by 1bp).
>>> Also when I did this I was using the yieldTS from T, not T-1 as the converter
>>> mandates. I was not far from the last standard coupon date though, that makes
>>> agreement easier; I was too lazy to follow this with time...
>>>
>>> Best regards
>>> Pepe
>>>
>>>
>>> ----- Mail original -----
>>> De: "Peter Caspers" <[hidden email]>
>>> À: [hidden email]
>>> Cc: [hidden email]
>>> Envoyé: Mardi 9 Octobre 2012 22:00:06
>>> Objet: Re: [Quantlib-dev] CDS last period
>>>
>>> Hi,
>>>
>>> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
>>> rebate can be handled via the upfront amount, i.e. if you provide the
>>> dirty upfront amount you get what is standard now, don't you? So no need
>>> for an extension unless (and that's what you are probably pointing at?)
>>> you want automatic computation of the accrual rebate amount. Btw I
>>> think the upfront payment is usually done on T + 3 open days (not T+1),
>>> is that correct?
>>>
>>> What I planned however is to implement a CDS bootstrap helper which can
>>> pay a full first coupon and an accrual rebate (computed from last roll
>>> date to T+1) on T+3. In fact the spreads provided by markit are meant
>>> using this convention rather than paying a short first coupon, at least
>>> some guy working there told me so. Can you validate this? Admittedly
>>> this makes only a little difference in the bootstrapped curve in
>>> general, but why not do it correctly if you can.
>>>
>>> Kind regards
>>> Peter
>>>
>>> Am 09.10.2012 13:05, schrieb [hidden email]:
>>>> Hi,
>>>> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
>>>> contracts too.
>>>>
>>>> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
>>>> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
>>>> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
>>>> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
>>>> time).
>>>>
>>>> See:
>>>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
>>>> p.18 Markit March 2009
>>>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009 p.4
>>>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>>>
>>>> Do you mind having a look on this too, pls? To have someone elses opinion.
>>>>
>>>> And another related point to the new convention intial accrual is that I have also patched the
>>>> constructors moving this:
>>>> QL_REQUIRE(protectionStart_ <= schedule[0],
>>>> "protection can not start after accrual");
>>>> which used to be true in the old convention,
>>>> into this:
>>>> QL_REQUIRE((protectionStart_ <= schedule[0])
>>>> || (schedule.rule() == DateGeneration::Rule::CDS),
>>>> "protection can not start after accrual");
>>>> since now it can be the case that the protection period starts before T+1 (actually T-60) but
>>>> rather than my hacks it might be better to leave it open completely;
>>>>
>>>> Best
>>>> pp
>>>>
>>>> ----- Mail original -----
>>>> De: "Peter Caspers" <[hidden email]>
>>>> À: [hidden email]
>>>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>>>> Objet: [Quantlib-dev] CDS last period
>>>>
>>>> Hi,
>>>>
>>>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>>>> i.e. including the first and the last date. I might miss something but
>>>> this seems not possible in the current implementation of the credit
>>>> default swap? This would be my plan to fix that:
>>>>
>>>> 1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
>>>> 2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
>>>> to FixedRateLeg and extend the Leg() operator accordingly
>>>> 3. Add a parameter const DayCounter& lastPeriodDayCounter =
>>>> DayCounter() to the CreditDefaultSwap constructors and invoke
>>>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>>>> parameter is not empty
>>>>
>>>> Maybe one could also default the dayCounter to Actual360() and the
>>>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>>>> constructors already to match the usual use case?
>>>>
>>>> Does that make sense?
>>>>
>>>> Thank you
>>>> Peter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>> Deploy New Relic app performance management and know exactly
>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: CDS last period

Great. For those not familiar with github, Peter's changes are at
<https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>From the link above, it's also possible to add notes to the changes.
As Peter says, it would be great if someone could have a look.

Luigi

On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers <[hidden email]> wrote:

> Hi Luigi, Pepe, Roland,
>
> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
> case below I added a test case comparing the conventional spread computed
> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
> without errors under the changes.
>
> I am neither a CDS nor a quantlib expert, so it would be great if someone
> could have a look ...
>
> Peter
>
> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>
>> Hi all,
>> sorry I've been sitting out of this one. Do go ahead (only one
>> thing: with regard to the day counter, I'd prefer to have an
>> additional parameter for the existing day counter, as in
>> Actual360(IncludeLastDay), rather than an additional day counter).
>>
>> You're also correct when you say that we'll need some expert to look
>> at the thing---speaking of which, how comfortable are you with git? If
>> you forked the QuantLib mirror I've put on github and pushed your
>> changes there, it would make it easier both to do a code review and to
>> merge the changes afterwards. No big deal if you want to just post
>> here though.
>>
>> Thanks,
>> Luigi
>>
>> On Tue, Oct 16, 2012 at 8:39 PM, Peter Caspers <[hidden email]>
>> wrote:
>>>
>>> Hi Pepe,
>>>
>>> sure. I'll do the day counter and the last period thing in the fixed
>>> rate leg and create a new rate helper with accrual rebate. Then we can
>>> merge. Give me some days. I want to test against Bloomberg, the Markit
>>> calculator and perhaps also Murex.
>>>
>>> I guess Roland should approve the changes and the way they are done
>>> before they enter the library.
>>>
>>> Regards
>>> Peter
>>>
>>> Am 16.10.2012 12:31, schrieb [hidden email]:
>>>>
>>>> Hi,
>>>> shall we do anything about this? Do you want to implement the day
>>>> counter and I can
>>>> change the engines for the rebate?
>>>> Can anyone else give an opinion?
>>>> Best
>>>> Pepe
>>>>
>>>>
>>>> ----- Mail original -----
>>>> De: [hidden email]
>>>> À: "Peter Caspers" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Envoyé: Mercredi 10 Octobre 2012 18:59:28
>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>
>>>> Couldnt help it: The conventional spread conversion is a good proxy to
>>>> check
>>>> things like the accrual rebate or other features like the one you
>>>> mentioned
>>>> initially in this post.
>>>>
>>>> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for
>>>> the TS
>>>> (should have used yesterday though). These are my figures and Markits
>>>> quotes:
>>>>
>>>> Without and with accrual rebate in both bootstrapping and
>>>> pricing/conversion:
>>>>
>>>> Mkit 5Y conv QL NoR QL+Rebt
>>>> upfront=11 for 5Y lowest bid: 443 439.21 443.38
>>>> upfront=14.5 for 5Y highest ask: 506 499.28 504.30
>>>>
>>>> The correction you propose is still missing. With an artificil fix
>>>> (adding 1
>>>> day to the last coupon in the pricing):
>>>> 443.24
>>>> 504.15
>>>>
>>>> Regards
>>>> Pepe
>>>>
>>>>
>>>> ----- Mail original -----
>>>> De: [hidden email]
>>>> À: "Peter Caspers" <[hidden email]>
>>>> Cc: [hidden email]
>>>> Envoyé: Mercredi 10 Octobre 2012 13:43:14
>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>
>>>>
>>>> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
>>>> computed to T+1.
>>>>
>>>> Yes, thats what I think too. I have my engines patched to bootstrap that
>>>> way,
>>>> its not a big change. Small difference yes, still it can be seen as a 3M
>>>> oscillation.
>>>>
>>>> On the way Markit works that was my assumption for the upfront quotes,
>>>> Markit's 'standard cds contract converter specification' mentions
>>>> this on p.3, section 'solving for the constant hazard rate'; there it
>>>> says that the upfront does not include the rebate. So their quotes must
>>>> be that way.
>>>> A way to test minimum coherence is to compute with QL the conventional
>>>> spread Markit quotes alongside and I get agreement or 1bp difference
>>>> at max (for a ~100bp conventional level of spreads). Which is quite
>>>> decent
>>>> considering that it is not rare to see Markit converting the same
>>>> upfront
>>>> quote by two sources on the same day to two different conv spreads (by
>>>> 1bp).
>>>> Also when I did this I was using the yieldTS from T, not T-1 as the
>>>> converter
>>>> mandates. I was not far from the last standard coupon date though, that
>>>> makes
>>>> agreement easier; I was too lazy to follow this with time...
>>>>
>>>> Best regards
>>>> Pepe
>>>>
>>>>
>>>> ----- Mail original -----
>>>> De: "Peter Caspers" <[hidden email]>
>>>> À: [hidden email]
>>>> Cc: [hidden email]
>>>> Envoyé: Mardi 9 Octobre 2012 22:00:06
>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>
>>>> Hi,
>>>>
>>>> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
>>>> rebate can be handled via the upfront amount, i.e. if you provide the
>>>> dirty upfront amount you get what is standard now, don't you? So no need
>>>> for an extension unless (and that's what you are probably pointing at?)
>>>> you want automatic computation of the accrual rebate amount. Btw I
>>>> think the upfront payment is usually done on T + 3 open days (not T+1),
>>>> is that correct?
>>>>
>>>> What I planned however is to implement a CDS bootstrap helper which can
>>>> pay a full first coupon and an accrual rebate (computed from last roll
>>>> date to T+1) on T+3. In fact the spreads provided by markit are meant
>>>> using this convention rather than paying a short first coupon, at least
>>>> some guy working there told me so. Can you validate this? Admittedly
>>>> this makes only a little difference in the bootstrapped curve in
>>>> general, but why not do it correctly if you can.
>>>>
>>>> Kind regards
>>>> Peter
>>>>
>>>> Am 09.10.2012 13:05, schrieb [hidden email]:
>>>>>
>>>>> Hi,
>>>>> True; your solution looks good, it allows to use it in other places and
>>>>> it allows non-standard CDS
>>>>> contracts too.
>>>>>
>>>>> Also, apparently theres another flow not treated in the CDS. According
>>>>> to the same new rules the accrued
>>>>> amount on the first coupon is paid by the protection buyer on the
>>>>> coupon payment (or default) date but
>>>>> it is rebated by the protection seller on T+1 (together with the
>>>>> upfront payment). It would have the
>>>>> same effect as not paying the initial accrual except for the discount
>>>>> factor (which is at an uncertain
>>>>> time).
>>>>>
>>>>> See:
>>>>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract
>>>>> and North American Conventions;
>>>>> p.18 Markit March 2009
>>>>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April
>>>>> 2009 p.4
>>>>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>>>>
>>>>> Do you mind having a look on this too, pls? To have someone elses
>>>>> opinion.
>>>>>
>>>>> And another related point to the new convention intial accrual is that
>>>>> I have also patched the
>>>>> constructors moving this:
>>>>> QL_REQUIRE(protectionStart_ <= schedule[0],
>>>>> "protection can not start after accrual");
>>>>> which used to be true in the old convention,
>>>>> into this:
>>>>> QL_REQUIRE((protectionStart_ <= schedule[0])
>>>>> || (schedule.rule() == DateGeneration::Rule::CDS),
>>>>> "protection can not start after accrual");
>>>>> since now it can be the case that the protection period starts before
>>>>> T+1 (actually T-60) but
>>>>> rather than my hacks it might be better to leave it open completely;
>>>>>
>>>>> Best
>>>>> pp
>>>>>
>>>>> ----- Mail original -----
>>>>> De: "Peter Caspers" <[hidden email]>
>>>>> À: [hidden email]
>>>>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>>>>> Objet: [Quantlib-dev] CDS last period
>>>>>
>>>>> Hi,
>>>>>
>>>>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>>>>> i.e. including the first and the last date. I might miss something but
>>>>> this seems not possible in the current implementation of the credit
>>>>> default swap? This would be my plan to fix that:
>>>>>
>>>>> 1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
>>>>> 2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter()
>>>>> method
>>>>> to FixedRateLeg and extend the Leg() operator accordingly
>>>>> 3. Add a parameter const DayCounter& lastPeriodDayCounter =
>>>>> DayCounter() to the CreditDefaultSwap constructors and invoke
>>>>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>>>>> parameter is not empty
>>>>>
>>>>> Maybe one could also default the dayCounter to Actual360() and the
>>>>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>>>>> constructors already to match the usual use case?
>>>>>
>>>>> Does that make sense?
>>>>>
>>>>> Thank you
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Don't let slow site performance ruin your business. Deploy New Relic
>>>>> APM
>>>>> Deploy New Relic app performance management and know exactly
>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>> _______________________________________________
>>>>> QuantLib-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>> Deploy New Relic app performance management and know exactly
>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>> Deploy New Relic app performance management and know exactly
>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

Peter Caspers-4

Re: CDS last period

Yes. In fact I forgot to commit the adjusted curve calibration helpers
which I did now to make the picture complete.

https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168

Also I should mention that the extensions are defensive in the sense
that existing code will not change its behaviour. This is at the cost of
usability though since the arguments are not really in a logical order
any more. Also the default values will not represent the usual market
conventions. Both could be changed easily and should be done in my
opinion, but I leave this decision to Luigi and the other admins.

Thank you, Peter

Am 20.10.2012 23:20, schrieb Luigi Ballabio:

> Great. For those not familiar with github, Peter's changes are at
> <https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
> From the link above, it's also possible to add notes to the changes.
> As Peter says, it would be great if someone could have a look.
>
> Luigi
>
> On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers <[hidden email]> wrote:
>> Hi Luigi, Pepe, Roland,
>>
>> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
>> case below I added a test case comparing the conventional spread computed
>> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
>> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
>> without errors under the changes.
>>
>> I am neither a CDS nor a quantlib expert, so it would be great if someone
>> could have a look ...
>>
>> Peter
>>
>> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>>
>>> Hi all,
>>> sorry I've been sitting out of this one. Do go ahead (only one
>>> thing: with regard to the day counter, I'd prefer to have an
>>> additional parameter for the existing day counter, as in
>>> Actual360(IncludeLastDay), rather than an additional day counter).
>>>
>>> You're also correct when you say that we'll need some expert to look
>>> at the thing---speaking of which, how comfortable are you with git? If
>>> you forked the QuantLib mirror I've put on github and pushed your
>>> changes there, it would make it easier both to do a code review and to
>>> merge the changes afterwards. No big deal if you want to just post
>>> here though.
>>>
>>> Thanks,
>>> Luigi
>>>
>>> On Tue, Oct 16, 2012 at 8:39 PM, Peter Caspers <[hidden email]>
>>> wrote:
>>>> Hi Pepe,
>>>>
>>>> sure. I'll do the day counter and the last period thing in the fixed
>>>> rate leg and create a new rate helper with accrual rebate. Then we can
>>>> merge. Give me some days. I want to test against Bloomberg, the Markit
>>>> calculator and perhaps also Murex.
>>>>
>>>> I guess Roland should approve the changes and the way they are done
>>>> before they enter the library.
>>>>
>>>> Regards
>>>> Peter
>>>>
>>>> Am 16.10.2012 12:31, schrieb [hidden email]:
>>>>> Hi,
>>>>> shall we do anything about this? Do you want to implement the day
>>>>> counter and I can
>>>>> change the engines for the rebate?
>>>>> Can anyone else give an opinion?
>>>>> Best
>>>>> Pepe
>>>>>
>>>>>
>>>>> ----- Mail original -----
>>>>> De: [hidden email]
>>>>> À: "Peter Caspers" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> Envoyé: Mercredi 10 Octobre 2012 18:59:28
>>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>>
>>>>> Couldnt help it: The conventional spread conversion is a good proxy to
>>>>> check
>>>>> things like the accrual rebate or other features like the one you
>>>>> mentioned
>>>>> initially in this post.
>>>>>
>>>>> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for
>>>>> the TS
>>>>> (should have used yesterday though). These are my figures and Markits
>>>>> quotes:
>>>>>
>>>>> Without and with accrual rebate in both bootstrapping and
>>>>> pricing/conversion:
>>>>>
>>>>> Mkit 5Y conv QL NoR QL+Rebt
>>>>> upfront=11 for 5Y lowest bid: 443 439.21 443.38
>>>>> upfront=14.5 for 5Y highest ask: 506 499.28 504.30
>>>>>
>>>>> The correction you propose is still missing. With an artificil fix
>>>>> (adding 1
>>>>> day to the last coupon in the pricing):
>>>>> 443.24
>>>>> 504.15
>>>>>
>>>>> Regards
>>>>> Pepe
>>>>>
>>>>>
>>>>> ----- Mail original -----
>>>>> De: [hidden email]
>>>>> À: "Peter Caspers" <[hidden email]>
>>>>> Cc: [hidden email]
>>>>> Envoyé: Mercredi 10 Octobre 2012 13:43:14
>>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>>
>>>>>
>>>>> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
>>>>> computed to T+1.
>>>>>
>>>>> Yes, thats what I think too. I have my engines patched to bootstrap that
>>>>> way,
>>>>> its not a big change. Small difference yes, still it can be seen as a 3M
>>>>> oscillation.
>>>>>
>>>>> On the way Markit works that was my assumption for the upfront quotes,
>>>>> Markit's 'standard cds contract converter specification' mentions
>>>>> this on p.3, section 'solving for the constant hazard rate'; there it
>>>>> says that the upfront does not include the rebate. So their quotes must
>>>>> be that way.
>>>>> A way to test minimum coherence is to compute with QL the conventional
>>>>> spread Markit quotes alongside and I get agreement or 1bp difference
>>>>> at max (for a ~100bp conventional level of spreads). Which is quite
>>>>> decent
>>>>> considering that it is not rare to see Markit converting the same
>>>>> upfront
>>>>> quote by two sources on the same day to two different conv spreads (by
>>>>> 1bp).
>>>>> Also when I did this I was using the yieldTS from T, not T-1 as the
>>>>> converter
>>>>> mandates. I was not far from the last standard coupon date though, that
>>>>> makes
>>>>> agreement easier; I was too lazy to follow this with time...
>>>>>
>>>>> Best regards
>>>>> Pepe
>>>>>
>>>>>
>>>>> ----- Mail original -----
>>>>> De: "Peter Caspers" <[hidden email]>
>>>>> À: [hidden email]
>>>>> Cc: [hidden email]
>>>>> Envoyé: Mardi 9 Octobre 2012 22:00:06
>>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>>
>>>>> Hi,
>>>>>
>>>>> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
>>>>> rebate can be handled via the upfront amount, i.e. if you provide the
>>>>> dirty upfront amount you get what is standard now, don't you? So no need
>>>>> for an extension unless (and that's what you are probably pointing at?)
>>>>> you want automatic computation of the accrual rebate amount. Btw I
>>>>> think the upfront payment is usually done on T + 3 open days (not T+1),
>>>>> is that correct?
>>>>>
>>>>> What I planned however is to implement a CDS bootstrap helper which can
>>>>> pay a full first coupon and an accrual rebate (computed from last roll
>>>>> date to T+1) on T+3. In fact the spreads provided by markit are meant
>>>>> using this convention rather than paying a short first coupon, at least
>>>>> some guy working there told me so. Can you validate this? Admittedly
>>>>> this makes only a little difference in the bootstrapped curve in
>>>>> general, but why not do it correctly if you can.
>>>>>
>>>>> Kind regards
>>>>> Peter
>>>>>
>>>>> Am 09.10.2012 13:05, schrieb [hidden email]:
>>>>>> Hi,
>>>>>> True; your solution looks good, it allows to use it in other places and
>>>>>> it allows non-standard CDS
>>>>>> contracts too.
>>>>>>
>>>>>> Also, apparently theres another flow not treated in the CDS. According
>>>>>> to the same new rules the accrued
>>>>>> amount on the first coupon is paid by the protection buyer on the
>>>>>> coupon payment (or default) date but
>>>>>> it is rebated by the protection seller on T+1 (together with the
>>>>>> upfront payment). It would have the
>>>>>> same effect as not paying the initial accrual except for the discount
>>>>>> factor (which is at an uncertain
>>>>>> time).
>>>>>>
>>>>>> See:
>>>>>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract
>>>>>> and North American Conventions;
>>>>>> p.18 Markit March 2009
>>>>>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April
>>>>>> 2009 p.4
>>>>>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>>>>>
>>>>>> Do you mind having a look on this too, pls? To have someone elses
>>>>>> opinion.
>>>>>>
>>>>>> And another related point to the new convention intial accrual is that
>>>>>> I have also patched the
>>>>>> constructors moving this:
>>>>>> QL_REQUIRE(protectionStart_ <= schedule[0],
>>>>>> "protection can not start after accrual");
>>>>>> which used to be true in the old convention,
>>>>>> into this:
>>>>>> QL_REQUIRE((protectionStart_ <= schedule[0])
>>>>>> || (schedule.rule() == DateGeneration::Rule::CDS),
>>>>>> "protection can not start after accrual");
>>>>>> since now it can be the case that the protection period starts before
>>>>>> T+1 (actually T-60) but
>>>>>> rather than my hacks it might be better to leave it open completely;
>>>>>>
>>>>>> Best
>>>>>> pp
>>>>>>
>>>>>> ----- Mail original -----
>>>>>> De: "Peter Caspers" <[hidden email]>
>>>>>> À: [hidden email]
>>>>>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>>>>>> Objet: [Quantlib-dev] CDS last period
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>>>>>> i.e. including the first and the last date. I might miss something but
>>>>>> this seems not possible in the current implementation of the credit
>>>>>> default swap? This would be my plan to fix that:
>>>>>>
>>>>>> 1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
>>>>>> 2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter()
>>>>>> method
>>>>>> to FixedRateLeg and extend the Leg() operator accordingly
>>>>>> 3. Add a parameter const DayCounter& lastPeriodDayCounter =
>>>>>> DayCounter() to the CreditDefaultSwap constructors and invoke
>>>>>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>>>>>> parameter is not empty
>>>>>>
>>>>>> Maybe one could also default the dayCounter to Actual360() and the
>>>>>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>>>>>> constructors already to match the usual use case?
>>>>>>
>>>>>> Does that make sense?
>>>>>>
>>>>>> Thank you
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Don't let slow site performance ruin your business. Deploy New Relic
>>>>>> APM
>>>>>> Deploy New Relic app performance management and know exactly
>>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>>> _______________________________________________
>>>>>> QuantLib-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>>> Deploy New Relic app performance management and know exactly
>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>> _______________________________________________
>>>>> QuantLib-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>>> Deploy New Relic app performance management and know exactly
>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>> _______________________________________________
>>>>> QuantLib-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>> Deploy New Relic app performance management and know exactly
>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>

japari

Re: CDS last period

Hi,
sorry I took a holiday break and ignored email.

Thank you for the code, it works as we wanted. The agreement with the markit converter I get is always within 1bp for different spreads levels. Also i tested for two different dates (small and large rebates).
Theres only one problem I had not thought of, and it is comning from what we are doing in the constructor of a run only quoted CDS:
As a result if one bootstraps from market upfront cds and then reconstructs the run only cds helpers through the fair spreads of the cds-s (not the conventional of course) and rebootstrap with the new helpers... instead of obtaining the same hazard rates one gets differences in probabilities over 5%. This is because the run only CDS sets a fictitious upfront payment of zero amount on the schedule[0] date so the RPV01 of the upfront is zero since it lies in the past. The rebate amount uses this date and it is now multiplied by zero and therefore unaccounted for.
I have changed line 58 of 'creditdefaultswap.cpp' to
upfrontPayment_.reset(new SimpleCashFlow(0.0, protectionStart_));
another option might have to use the protection start for the RPV01 of the rebate since this solution is still wrong because the forward case has non zero probability of knocking out the cds (and then the rebate). Even better might be to have a separate cashflow meber for the rebate, maybe of boost::optional type (and possibly the upfront too should be optional).

Other minor comments: looks like theres a typo on the directionality sign of the rebate in 'integralcdsengine.cpp' and would it be better for performance to have the rebate accrual called within the upfPV01 calculation braces?

Pls, tell me what you think
Best
Pepe

----- Mail original -----
De: "Peter Caspers" <[hidden email]>
À: "Luigi Ballabio" <[hidden email]>
Cc: [hidden email], [hidden email]
Envoyé: Lundi 22 Octobre 2012 21:17:28
Objet: Re: [Quantlib-dev] CDS last period

Yes. In fact I forgot to commit the adjusted curve calibration helpers
which I did now to make the picture complete.

https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168

Also I should mention that the extensions are defensive in the sense
that existing code will not change its behaviour. This is at the cost of
usability though since the arguments are not really in a logical order
any more. Also the default values will not represent the usual market
conventions. Both could be changed easily and should be done in my
opinion, but I leave this decision to Luigi and the other admins.

Thank you, Peter

Am 20.10.2012 23:20, schrieb Luigi Ballabio:

Peter Caspers-4

Re: CDS last period

Hi Pepe,

thanks a lot for your review and the testing. Sounds promising to me?

I added some more things to account for your test case below. The main
idea is to identify standard cds by the date generation rule CDS and
treat all other cases with the old code. I think your case should work
now, I get exactly the same hazard rates in both termstructures. It
would be great if you could do some more testing and review the new
changes. I also corrected the sign typo in the engine.

I don't use CDS quotes with upfronts. Is the dirty upfront quoted or the
clean upfront (or is both possible) ? In the latter cases we'd have to
extend the upfront helper such that it can return the clean upfront in
impliedQuote, right ? Do we need this ?

Kind regards
Peter

Am 24.10.2012 19:13, schrieb [hidden email]:

> Hi,
> sorry I took a holiday break and ignored email.
>
> Thank you for the code, it works as we wanted. The agreement with the markit converter I get is always within 1bp for different spreads levels. Also i tested for two different dates (small and large rebates).
> Theres only one problem I had not thought of, and it is comning from what we are doing in the constructor of a run only quoted CDS:
> As a result if one bootstraps from market upfront cds and then reconstructs the run only cds helpers through the fair spreads of the cds-s (not the conventional of course) and rebootstrap with the new helpers... instead of obtaining the same hazard rates one gets differences in probabilities over 5%. This is because the run only CDS sets a fictitious upfront payment of zero amount on the schedule[0] date so the RPV01 of the upfront is zero since it lies in the past. The rebate amount uses this date and it is now multiplied by zero and therefore unaccounted for.
> I have changed line 58 of 'creditdefaultswap.cpp' to
> upfrontPayment_.reset(new SimpleCashFlow(0.0, protectionStart_));
> another option might have to use the protection start for the RPV01 of the rebate since this solution is still wrong because the forward case has non zero probability of knocking out the cds (and then the rebate). Even better might be to have a separate cashflow meber for the rebate, maybe of boost::optional type (and possibly the upfront too should be optional).
>
> Other minor comments: looks like theres a typo on the directionality sign of the rebate in 'integralcdsengine.cpp' and would it be better for performance to have the rebate accrual called within the upfPV01 calculation braces?
>
> Pls, tell me what you think
> Best
> Pepe
>
>
>
> ----- Mail original -----
> De: "Peter Caspers"<[hidden email]>
> À: "Luigi Ballabio"<[hidden email]>
> Cc:[hidden email],[hidden email]
> Envoyé: Lundi 22 Octobre 2012 21:17:28
> Objet: Re: [Quantlib-dev] CDS last period
>
> Yes. In fact I forgot to commit the adjusted curve calibration helpers
> which I did now to make the picture complete.
>
> https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168
>
> Also I should mention that the extensions are defensive in the sense
> that existing code will not change its behaviour. This is at the cost of
> usability though since the arguments are not really in a logical order
> any more. Also the default values will not represent the usual market
> conventions. Both could be changed easily and should be done in my
> opinion, but I leave this decision to Luigi and the other admins.
>
> Thank you, Peter
>
> Am 20.10.2012 23:20, schrieb Luigi Ballabio:
>> Great. For those not familiar with github, Peter's changes are at
>> <https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>> From the link above, it's also possible to add notes to the changes.
>> As Peter says, it would be great if someone could have a look.
>>
>> Luigi
>>
>> On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers<[hidden email]> wrote:
>>> Hi Luigi, Pepe, Roland,
>>>
>>> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
>>> case below I added a test case comparing the conventional spread computed
>>> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
>>> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
>>> without errors under the changes.
>>>
>>> I am neither a CDS nor a quantlib expert, so it would be great if someone
>>> could have a look ...
>>>
>>> Peter
>>>
>>> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>>>
>>>> Hi all,
>>>> sorry I've been sitting out of this one. Do go ahead (only one
>>>> thing: with regard to the day counter, I'd prefer to have an
>>>> additional parameter for the existing day counter, as in
>>>> Actual360(IncludeLastDay), rather than an additional day counter).
>>>>
>>>> You're also correct when you say that we'll need some expert to look
>>>> at the thing---speaking of which, how comfortable are you with git? If
>>>> you forked the QuantLib mirror I've put on github and pushed your
>>>> changes there, it would make it easier both to do a code review and to
>>>> merge the changes afterwards. No big deal if you want to just post
>>>> here though.
>>>>
>>>> Thanks,
>>>> Luigi
>>>>
>>>> On Tue, Oct 16, 2012 at 8:39 PM, Peter Caspers<[hidden email]>
>>>> wrote:
>>>>> Hi Pepe,
>>>>>
>>>>> sure. I'll do the day counter and the last period thing in the fixed
>>>>> rate leg and create a new rate helper with accrual rebate. Then we can
>>>>> merge. Give me some days. I want to test against Bloomberg, the Markit
>>>>> calculator and perhaps also Murex.
>>>>>
>>>>> I guess Roland should approve the changes and the way they are done
>>>>> before they enter the library.
>>>>>
>>>>> Regards
>>>>> Peter
>>>>>
>>>>> Am 16.10.2012 12:31, [hidden email]:
>>>>>> Hi,
>>>>>> shall we do anything about this? Do you want to implement the day
>>>>>> counter and I can
>>>>>> change the engines for the rebate?
>>>>>> Can anyone else give an opinion?
>>>>>> Best
>>>>>> Pepe
>>>>>>
>>>>>>
>>>>>> ----- Mail original -----
>>>>>> De:[hidden email]
>>>>>> À: "Peter Caspers"<[hidden email]>
>>>>>> Cc:[hidden email]
>>>>>> Envoyé: Mercredi 10 Octobre 2012 18:59:28
>>>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>>>
>>>>>> Couldnt help it: The conventional spread conversion is a good proxy to
>>>>>> check
>>>>>> things like the accrual rebate or other features like the one you
>>>>>> mentioned
>>>>>> initially in this post.
>>>>>>
>>>>>> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for
>>>>>> the TS
>>>>>> (should have used yesterday though). These are my figures and Markits
>>>>>> quotes:
>>>>>>
>>>>>> Without and with accrual rebate in both bootstrapping and
>>>>>> pricing/conversion:
>>>>>>
>>>>>> Mkit 5Y conv QL NoR QL+Rebt
>>>>>> upfront=11 for 5Y lowest bid: 443 439.21 443.38
>>>>>> upfront=14.5 for 5Y highest ask: 506 499.28 504.30
>>>>>>
>>>>>> The correction you propose is still missing. With an artificil fix
>>>>>> (adding 1
>>>>>> day to the last coupon in the pricing):
>>>>>> 443.24
>>>>>> 504.15
>>>>>>
>>>>>> Regards
>>>>>> Pepe
>>>>>>
>>>>>>
>>>>>> ----- Mail original -----
>>>>>> De:[hidden email]
>>>>>> À: "Peter Caspers"<[hidden email]>
>>>>>> Cc:[hidden email]
>>>>>> Envoyé: Mercredi 10 Octobre 2012 13:43:14
>>>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>>>
>>>>>>
>>>>>> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
>>>>>> computed to T+1.
>>>>>>
>>>>>> Yes, thats what I think too. I have my engines patched to bootstrap that
>>>>>> way,
>>>>>> its not a big change. Small difference yes, still it can be seen as a 3M
>>>>>> oscillation.
>>>>>>
>>>>>> On the way Markit works that was my assumption for the upfront quotes,
>>>>>> Markit's 'standard cds contract converter specification' mentions
>>>>>> this on p.3, section 'solving for the constant hazard rate'; there it
>>>>>> says that the upfront does not include the rebate. So their quotes must
>>>>>> be that way.
>>>>>> A way to test minimum coherence is to compute with QL the conventional
>>>>>> spread Markit quotes alongside and I get agreement or 1bp difference
>>>>>> at max (for a ~100bp conventional level of spreads). Which is quite
>>>>>> decent
>>>>>> considering that it is not rare to see Markit converting the same
>>>>>> upfront
>>>>>> quote by two sources on the same day to two different conv spreads (by
>>>>>> 1bp).
>>>>>> Also when I did this I was using the yieldTS from T, not T-1 as the
>>>>>> converter
>>>>>> mandates. I was not far from the last standard coupon date though, that
>>>>>> makes
>>>>>> agreement easier; I was too lazy to follow this with time...
>>>>>>
>>>>>> Best regards
>>>>>> Pepe
>>>>>>
>>>>>>
>>>>>> ----- Mail original -----
>>>>>> De: "Peter Caspers"<[hidden email]>
>>>>>> À:[hidden email]
>>>>>> Cc:[hidden email]
>>>>>> Envoyé: Mardi 9 Octobre 2012 22:00:06
>>>>>> Objet: Re: [Quantlib-dev] CDS last period
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
>>>>>> rebate can be handled via the upfront amount, i.e. if you provide the
>>>>>> dirty upfront amount you get what is standard now, don't you? So no need
>>>>>> for an extension unless (and that's what you are probably pointing at?)
>>>>>> you want automatic computation of the accrual rebate amount. Btw I
>>>>>> think the upfront payment is usually done on T + 3 open days (not T+1),
>>>>>> is that correct?
>>>>>>
>>>>>> What I planned however is to implement a CDS bootstrap helper which can
>>>>>> pay a full first coupon and an accrual rebate (computed from last roll
>>>>>> date to T+1) on T+3. In fact the spreads provided by markit are meant
>>>>>> using this convention rather than paying a short first coupon, at least
>>>>>> some guy working there told me so. Can you validate this? Admittedly
>>>>>> this makes only a little difference in the bootstrapped curve in
>>>>>> general, but why not do it correctly if you can.
>>>>>>
>>>>>> Kind regards
>>>>>> Peter
>>>>>>
>>>>>> Am 09.10.2012 13:05, [hidden email]:
>>>>>>> Hi,
>>>>>>> True; your solution looks good, it allows to use it in other places and
>>>>>>> it allows non-standard CDS
>>>>>>> contracts too.
>>>>>>>
>>>>>>> Also, apparently theres another flow not treated in the CDS. According
>>>>>>> to the same new rules the accrued
>>>>>>> amount on the first coupon is paid by the protection buyer on the
>>>>>>> coupon payment (or default) date but
>>>>>>> it is rebated by the protection seller on T+1 (together with the
>>>>>>> upfront payment). It would have the
>>>>>>> same effect as not paying the initial accrual except for the discount
>>>>>>> factor (which is at an uncertain
>>>>>>> time).
>>>>>>>
>>>>>>> See:
>>>>>>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract
>>>>>>> and North American Conventions;
>>>>>>> p.18 Markit March 2009
>>>>>>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April
>>>>>>> 2009 p.4
>>>>>>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>>>>>>
>>>>>>> Do you mind having a look on this too, pls? To have someone elses
>>>>>>> opinion.
>>>>>>>
>>>>>>> And another related point to the new convention intial accrual is that
>>>>>>> I have also patched the
>>>>>>> constructors moving this:
>>>>>>> QL_REQUIRE(protectionStart_ <= schedule[0],
>>>>>>> "protection can not start after accrual");
>>>>>>> which used to be true in the old convention,
>>>>>>> into this:
>>>>>>> QL_REQUIRE((protectionStart_ <= schedule[0])
>>>>>>> || (schedule.rule() == DateGeneration::Rule::CDS),
>>>>>>> "protection can not start after accrual");
>>>>>>> since now it can be the case that the protection period starts before
>>>>>>> T+1 (actually T-60) but
>>>>>>> rather than my hacks it might be better to leave it open completely;
>>>>>>>
>>>>>>> Best
>>>>>>> pp
>>>>>>>
>>>>>>> ----- Mail original -----
>>>>>>> De: "Peter Caspers"<[hidden email]>
>>>>>>> À:[hidden email]
>>>>>>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>>>>>>> Objet: [Quantlib-dev] CDS last period
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>>>>>>> i.e. including the first and the last date. I might miss something but
>>>>>>> this seems not possible in the current implementation of the credit
>>>>>>> default swap? This would be my plan to fix that:
>>>>>>>
>>>>>>> 1. Implement a new day counter Actual360Inc counting (d2-d1+1) days
>>>>>>> 2. Add a lastPeriodDC_ variable and withLastPeriodDayCounter()
>>>>>>> method
>>>>>>> to FixedRateLeg and extend the Leg() operator accordingly
>>>>>>> 3. Add a parameter const DayCounter& lastPeriodDayCounter =
>>>>>>> DayCounter() to the CreditDefaultSwap constructors and invoke
>>>>>>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>>>>>>> parameter is not empty
>>>>>>>
>>>>>>> Maybe one could also default the dayCounter to Actual360() and the
>>>>>>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>>>>>>> constructors already to match the usual use case?
>>>>>>>
>>>>>>> Does that make sense?
>>>>>>>
>>>>>>> Thank you
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Don't let slow site performance ruin your business. Deploy New Relic
>>>>>>> APM
>>>>>>> Deploy New Relic app performance management and know exactly
>>>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>>>> _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>> ------------------------------------------------------------------------------
>>>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>>>> Deploy New Relic app performance management and know exactly
>>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>>> _______________________________________________
>>>>>> QuantLib-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>>>> Deploy New Relic app performance management and know exactly
>>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>>> _______________________________________________
>>>>>> QuantLib-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>> ------------------------------------------------------------------------------
>>>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>>>> Deploy New Relic app performance management and know exactly
>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>> _______________________________________________
>>>>> QuantLib-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

japari

Re: CDS last period

Hi Peter,

Thank you again.
I never needed a clean helper, a conventional helper is yet another
exotic possibility.

Give me a few days to have a look at the code pls.

Regards
Pepe

----- Mail original -----
De: "Peter Caspers" <[hidden email]>
À: [hidden email]
Cc: [hidden email], "Luigi Ballabio" <[hidden email]>
Envoyé: Jeudi 25 Octobre 2012 21:37:23
Objet: Re: [Quantlib-dev] CDS last period

Hi Pepe,

thanks a lot for your review and the testing. Sounds promising to me?

I added some more things to account for your test case below. The main
idea is to identify standard cds by the date generation rule CDS and
treat all other cases with the old code. I think your case should work
now, I get exactly the same hazard rates in both termstructures. It
would be great if you could do some more testing and review the new
changes. I also corrected the sign typo in the engine.

I don't use CDS quotes with upfronts. Is the dirty upfront quoted or the
clean upfront (or is both possible) ? In the latter cases we'd have to
extend the upfront helper such that it can return the clean upfront in
impliedQuote, right ? Do we need this ?

Kind regards
Peter

Am 24.10.2012 19:13, schrieb [hidden email]:

------------------------------------------------------------------------------
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

japari

Re: CDS last period

Peter, hi, apologies for the long delay, too many hobbies...

The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).

I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.

Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter

Best regards
Pepe

PS1
These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:

QL mkit QL(no rebate)
6M 0.0013962 0.001391 0.0015124
1Y 0.0024018 0.002396 0.0025179
2Y 0.0066991 0.006683 0.0068754
3Y 0.0128463 0.012795 0.0130785
4Y 0.0227410 0.022554 0.0230541
5Y 0.0357163 0.035221 0.0361139
7Y 0.0610696 0.059787 0.0615613
10Y 0.1036803 0.100268 0.1042708
15Y 0.1578319 0.152918 0.1584299
20Y 0.1948182 0.192336 0.1953589

As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.

PS2
Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
Other points for the CDS:
-default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
-not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

newcode.tar.gz (13K) Download Attachment

Peter Caspers-4

Re: CDS last period

Hi Pepe,

thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.

Just a few comments why I did it how I did it:

If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.

If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).

However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.

Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.

Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.

Thanks again and kind regards

Peter

2012/11/19 <[hidden email]>

Peter, hi, apologies for the long delay, too many hobbies...

The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).

I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.

Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter

Best regards
Pepe

PS1
These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:

QL mkit QL(no rebate)
6M 0.0013962 0.001391 0.0015124
1Y 0.0024018 0.002396 0.0025179
2Y 0.0066991 0.006683 0.0068754
3Y 0.0128463 0.012795 0.0130785
4Y 0.0227410 0.022554 0.0230541
5Y 0.0357163 0.035221 0.0361139
7Y 0.0610696 0.059787 0.0615613
10Y 0.1036803 0.100268 0.1042708
15Y 0.1578319 0.152918 0.1584299
20Y 0.1948182 0.192336 0.1953589

As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.

PS2
Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
Other points for the CDS:
-default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
-not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

japari

Re: CDS last period

Hi Peter,
Great, thanks for setting up the code.
Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
Best regards
Pepe

----- Original Message -----
From: "Peter Caspers" <[hidden email]>
To: [hidden email]
Cc: [hidden email], "Luigi Ballabio" <[hidden email]>
Sent: Monday, 19 November, 2012 8:45:55 PM
Subject: Re: [Quantlib-dev] CDS last period

Hi Pepe,

thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.

Just a few comments why I did it how I did it:

If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.

If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).

However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.

Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.

Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.

Thanks again and kind regards
Peter

2012/11/19 < [hidden email] >

Peter, hi, apologies for the long delay, too many hobbies...

The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).

I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.

Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter

Best regards
Pepe

PS1
These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:

QL mkit QL(no rebate)
6M 0.0013962 0.001391 0.0015124
1Y 0.0024018 0.002396 0.0025179
2Y 0.0066991 0.006683 0.0068754
3Y 0.0128463 0.012795 0.0130785
4Y 0.0227410 0.022554 0.0230541
5Y 0.0357163 0.035221 0.0361139
7Y 0.0610696 0.059787 0.0615613
10Y 0.1036803 0.100268 0.1042708
15Y 0.1578319 0.152918 0.1584299
20Y 0.1948182 0.192336 0.1953589

As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.

PS2
Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
Other points for the CDS:
-default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
-not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

creditdefaultswap.cpp (20K) Download Attachment

Peter Caspers-4

Re: CDS last period

This is not forgotten, Pepe ... Right now however, I'd like to ask a
quick question:

The CdsHelper constructors take the maturity as a period p and compute
the maturity date of the CDS as the earliest IMM date on or after
evaluationDate+p (unadjusted). As a result on trade date = 20th
December, 2012 a 5Y helper will mature on 20th December, 2017. In BBG
the maturity already rolls on the 20th by 3 month to 20th March, 2018.
Also I see the "jump" in the CDS quotes we use (from Markit) on the IMM
dates. From that I assume that the maturity date should be computed
differently. Someone knows the exact convention ? Is it possibly
startDate+p (where startDate = evaluationDate + 1d unadjusted usually) ?
I tried to find that piece of convention in the different documents on
standard CDS, but failed.

Thanks for any help on this
Peter

Am 22.11.2012 10:03, schrieb [hidden email]:

> Hi Peter,
> Great, thanks for setting up the code.
> Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
> Best regards
> Pepe
>
>
> ----- Original Message -----
> From: "Peter Caspers" <[hidden email]>
> To: [hidden email]
> Cc: [hidden email], "Luigi Ballabio" <[hidden email]>
> Sent: Monday, 19 November, 2012 8:45:55 PM
> Subject: Re: [Quantlib-dev] CDS last period
>
>
> Hi Pepe,
>
> thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.
>
>
> Just a few comments why I did it how I did it:
>
>
> If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.
>
> If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).
>
> However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.
>
> Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.
>
> Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.
>
>
> Thanks again and kind regards
> Peter
>
>
>
> 2012/11/19 < [hidden email] >
>
>
> Peter, hi, apologies for the long delay, too many hobbies...
>
> The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
> The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).
>
> I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
> Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.
>
> Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter
>
> Best regards
> Pepe
>
>
> PS1
> These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
> Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:
>
> QL mkit QL(no rebate)
> 6M 0.0013962 0.001391 0.0015124
> 1Y 0.0024018 0.002396 0.0025179
> 2Y 0.0066991 0.006683 0.0068754
> 3Y 0.0128463 0.012795 0.0130785
> 4Y 0.0227410 0.022554 0.0230541
> 5Y 0.0357163 0.035221 0.0361139
> 7Y 0.0610696 0.059787 0.0615613
> 10Y 0.1036803 0.100268 0.1042708
> 15Y 0.1578319 0.152918 0.1584299
> 20Y 0.1948182 0.192336 0.1953589
>
>
> As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
> This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
> Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.
>
> PS2
> Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
> Other points for the CDS:
> -default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
> -not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).
>
>
>
>

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

japari

Re: CDS last period

Hello again,

I cant find documentation on exactly the maturity; I have (see below) on the first coupon date; which yes, as you say, uses Next20thIMM to T+1 (unadjusted) for the next coupon. Since the maturity follows from this date plus tenor then it should be that way.
Besides, if the jumps you see are timed on dates after the 20-s then that must be it, and the code is wrongly not including the settlement delay.

Changing the end date to include the settlement days might fix it:
Date endDate = protectionStart_ + tenor_;
in "void CdsHelper::initializeDates()"
Passing this date to the schedule creation with the CDS rule will change the maturity in that way.

see sect 5 of 'Standardizing coupon dates':
http://www.cdsmodel.com/assets/cds-model/docs/Standard%20CDS%20Examples.pdf
All other docs I know treat the maturity date as given.

Thank you for taking the trouble of checking these things
Pepe

----- Original Message -----
From: "Peter Caspers" <[hidden email]>
To: [hidden email]
Cc: [hidden email], "Luigi Ballabio" <[hidden email]>
Sent: Saturday, 19 January, 2013 7:02:09 PM
Subject: Re: [Quantlib-dev] CDS last period

This is not forgotten, Pepe ... Right now however, I'd like to ask a
quick question:

The CdsHelper constructors take the maturity as a period p and compute
the maturity date of the CDS as the earliest IMM date on or after
evaluationDate+p (unadjusted). As a result on trade date = 20th
December, 2012 a 5Y helper will mature on 20th December, 2017. In BBG
the maturity already rolls on the 20th by 3 month to 20th March, 2018.
Also I see the "jump" in the CDS quotes we use (from Markit) on the IMM
dates. From that I assume that the maturity date should be computed
differently. Someone knows the exact convention ? Is it possibly
startDate+p (where startDate = evaluationDate + 1d unadjusted usually) ?
I tried to find that piece of convention in the different documents on
standard CDS, but failed.

Thanks for any help on this
Peter

Am 22.11.2012 10:03, schrieb [hidden email]:

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Peter Caspers-4

Re: CDS last period

yes, that's how I fixed it and then it is consistent with BBG. Thanks a
lot for cross checking.
Peter

Am 21.01.2013 19:08, schrieb [hidden email]:

> Hello again,
>
> I cant find documentation on exactly the maturity; I have (see below) on the first coupon date; which yes, as you say, uses Next20thIMM to T+1 (unadjusted) for the next coupon. Since the maturity follows from this date plus tenor then it should be that way.
> Besides, if the jumps you see are timed on dates after the 20-s then that must be it, and the code is wrongly not including the settlement delay.
>
> Changing the end date to include the settlement days might fix it:
> Date endDate = protectionStart_ + tenor_;
> in "void CdsHelper::initializeDates()"
> Passing this date to the schedule creation with the CDS rule will change the maturity in that way.
>
> see sect 5 of 'Standardizing coupon dates':
> http://www.cdsmodel.com/assets/cds-model/docs/Standard%20CDS%20Examples.pdf
> All other docs I know treat the maturity date as given.
>
> Thank you for taking the trouble of checking these things
> Pepe
>
>
> ----- Original Message -----
> From: "Peter Caspers" <[hidden email]>
> To: [hidden email]
> Cc: [hidden email], "Luigi Ballabio" <[hidden email]>
> Sent: Saturday, 19 January, 2013 7:02:09 PM
> Subject: Re: [Quantlib-dev] CDS last period
>
> This is not forgotten, Pepe ... Right now however, I'd like to ask a
> quick question:
>
> The CdsHelper constructors take the maturity as a period p and compute
> the maturity date of the CDS as the earliest IMM date on or after
> evaluationDate+p (unadjusted). As a result on trade date = 20th
> December, 2012 a 5Y helper will mature on 20th December, 2017. In BBG
> the maturity already rolls on the 20th by 3 month to 20th March, 2018.
> Also I see the "jump" in the CDS quotes we use (from Markit) on the IMM
> dates. From that I assume that the maturity date should be computed
> differently. Someone knows the exact convention ? Is it possibly
> startDate+p (where startDate = evaluationDate + 1d unadjusted usually) ?
> I tried to find that piece of convention in the different documents on
> standard CDS, but failed.
>
> Thanks for any help on this
> Peter
>
> Am 22.11.2012 10:03, schrieb [hidden email]:
>> Hi Peter,
>> Great, thanks for setting up the code.
>> Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
>> Best regards
>> Pepe
>>
>>
>> ----- Original Message -----
>> From: "Peter Caspers" <[hidden email]>
>> To: [hidden email]
>> Cc: [hidden email], "Luigi Ballabio" <[hidden email]>
>> Sent: Monday, 19 November, 2012 8:45:55 PM
>> Subject: Re: [Quantlib-dev] CDS last period
>>
>>
>> Hi Pepe,
>>
>> thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.
>>
>>
>> Just a few comments why I did it how I did it:
>>
>>
>> If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.
>>
>> If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).
>>
>> However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.
>>
>> Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.
>>
>> Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.
>>
>>
>> Thanks again and kind regards
>> Peter
>>
>>
>>
>> 2012/11/19 < [hidden email] >
>>
>>
>> Peter, hi, apologies for the long delay, too many hobbies...
>>
>> The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
>> The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).
>>
>> I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
>> Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.
>>
>> Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter
>>
>> Best regards
>> Pepe
>>
>>
>> PS1
>> These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
>> Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:
>>
>> QL mkit QL(no rebate)
>> 6M 0.0013962 0.001391 0.0015124
>> 1Y 0.0024018 0.002396 0.0025179
>> 2Y 0.0066991 0.006683 0.0068754
>> 3Y 0.0128463 0.012795 0.0130785
>> 4Y 0.0227410 0.022554 0.0230541
>> 5Y 0.0357163 0.035221 0.0361139
>> 7Y 0.0610696 0.059787 0.0615613
>> 10Y 0.1036803 0.100268 0.1042708
>> 15Y 0.1578319 0.152918 0.1584299
>> 20Y 0.1948182 0.192336 0.1953589
>>
>>
>> As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
>> This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
>> Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.
>>
>> PS2
>> Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
>> Other points for the CDS:
>> -default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
>> -not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).
>>
>>
>>
>>

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev