Login  Register

Re: CDS last period

Posted by Peter Caspers-4 on Oct 22, 2012; 7:17pm
URL: http://quantlib.414.s1.nabble.com/CDS-last-period-tp13598p13608.html

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
>>


------------------------------------------------------------------------------
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