sorry I've been sitting out of this one. Do go ahead (only one
merge the changes afterwards. No big deal if you want to just post
> 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.