Re: [Quantlib-dev] CDS last period

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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 ja...@fr...:
> 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: ja...@fr...
> À: "Peter Caspers" <pca...@gm...>
> Cc: qua...@li...
> 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: ja...@fr...
> À: "Peter Caspers" <pca...@gm...>
> Cc: qua...@li...
> 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" <pca...@gm...>
> À: ja...@fr...
> Cc: qua...@li...
> 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 ja...@fr...:
>> 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" <pca...@gm...>
>> À: qua...@li...
>> 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
>> Qua...@li...
>> 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
> Qua...@li...
> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev