From: <ja...@fr...> - 2012-10-16 10:31:42
|
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 |