Hi all,
The long/short stub CDS rule (since the "big bang" aka 'old' CDS rule) states that: (quoting MarkIt docs) << If the trade date falls before 30 days before the first coupon date, the accrual is due on the first coupon date for the number of days of effective protection during the period. This is called a short stub period. If the trade date is within 30 days before the first coupon date, there is a long stub period. No accrual of premium is paid on this first IMM coupon date, rather the long stub is paid on the following coupon date. That payment will include the portion of premium owed for protection in the first period plus the full premium for the second period. >> Long stub meaning then a coupon larger thant the CDS tenor. Ironically, with the big bang, this will no longer be the way the quoted CDS will have the coupons generated in the US. Still, it is relevant for on the run positions and non-US ones (though they might change too). But thats another issue for another post. This rule makes fwd spreads jump around the cds imm dates, with the effect on options. So far I have been using the 20thIMM rule which matches this rule in the short stub case only. I have added a new rule to account for the long stub. For frequencies other than the 'usual' ones I do not think the rule makes sense (think say, 10days). The stub rule was intended to make the coupon dates homogeneous. So I have (arbitrarily) chosen to revert to the short stub in that case. Another alternative is a QL_REQUIRE at the beginning of the Schedule creation method refusing to take that combination. I have also forced unadjustment on the first schedule date in this case since theres no particular convention variable for that date. If we want a convention on the startDate we pass it already adjusted (as it is done in the helpers). Another small change I would like to request is for the cds helpers not to adjust the final protection date accrual, which is the default convention (the swaps will still adjust the final payment date when building the leg). They would look like this: 96 void CdsHelper::initializeDates() { 97 Date protectionStart_ = evaluationDate_ + settlementDays_; 98 Date startDate = calendar_.adjust(protectionStart_, 99 paymentConvention_); 100 Date endDate = evaluationDate_ + tenor_; 101 102 schedule_ = 103 MakeSchedule().from(startDate) 104 .to(endDate) 105 .withFrequency(frequency_) 106 .withCalendar(calendar_) 107 .withConvention(paymentConvention_) >>>>>>>>> .withTerminationDateConvention(Unadjusted) <<<< 108 .withRule(rule_); 109 earliestDate_ = schedule_.dates().front(); 110 latestDate_ = schedule_.dates().back(); 111 } Alternatively we could have another convention variable in the helper constructor. Maybe the rule should be called 20thCDSstub or something different.... Tell me what you think. Best regards Pepe -- Impacted files: dategenerationrule.Xpp schedule.cpp ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev files.zip (7K) Download Attachment |
On Tue, 2009-09-22 at 08:13 +0200, Jose Aparicio-Navarro wrote:
> I have added a new rule to account for the long stub. > > I have also forced unadjustment on the first schedule date in this case since > theres no particular convention variable for that date. If we want a convention > on the startDate we pass it already adjusted (as it is done in the helpers). > > Another small change I would like to request is for the cds helpers not to > adjust the final protection date accrual, which is the default convention. Ok. As they used to say, if anybody is against this, speak now or forever hold your peace. Or at least hold it until some future release. Luigi -- Cogito ergo I'm right and you're wrong. -- Blair Houghton ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Free forum by Nabble | Edit this page |