I put my changes on a github (pcaspers) forked from Luigis. Following
431.6945 bp in ql versus 431.6329 bp in BBG which seems quite good). The
> 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-devEveryone hates slow websites. So do we.