Re: [Quantlib-dev] CDS last period

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

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 <pca...@gm...> 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 <pca...@gm...>
>> 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 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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>
>