Re: [Quantlib-dev] CDS last period

[Peter C. <pca...@gm...>]

yes, that's how I fixed it and then it is consistent with BBG. Thanks a 
lot for cross checking.
Peter

Am 21.01.2013 19:08, schrieb ja...@fr...:
> Hello again,
>
> I cant find documentation on exactly the maturity; I have (see below) on the first coupon date; which yes, as you say, uses Next20thIMM to T+1 (unadjusted) for the next coupon. Since the maturity follows from this date plus tenor then it should be that way.
> Besides, if the jumps you see are timed on dates after the 20-s then that must be it, and the code is wrongly not including the settlement delay.
>
> Changing the end date to include the settlement days might fix it:
> Date endDate = protectionStart_ + tenor_;
> in "void CdsHelper::initializeDates()"
> Passing this date to the schedule creation with the CDS rule will change the maturity in that way.
>
> see sect 5 of 'Standardizing coupon dates':
> http://www.cdsmodel.com/assets/cds-model/docs/Standard%20CDS%20Examples.pdf
> All other docs I know treat the maturity date as given.
>
> Thank you for taking the trouble of checking these things
> Pepe
>
>
> ----- Original Message -----
> From: "Peter Caspers" <pca...@gm...>
> To: ja...@fr...
> Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
> Sent: Saturday, 19 January, 2013 7:02:09 PM
> Subject: Re: [Quantlib-dev] CDS last period
>
> This is not forgotten, Pepe ... Right now however, I'd like to ask a
> quick question:
>
> The CdsHelper constructors take the maturity as a period p and compute
> the maturity date of the CDS as the earliest IMM date on or after
> evaluationDate+p (unadjusted). As a result on trade date = 20th
> December, 2012 a 5Y helper will mature on 20th December, 2017. In BBG
> the maturity already rolls on the 20th by 3 month to 20th March, 2018.
> Also I see the "jump" in the CDS quotes we use (from Markit) on the IMM
> dates. From that I assume that the maturity date should be computed
> differently. Someone knows the exact convention ? Is it possibly
> startDate+p (where startDate = evaluationDate + 1d unadjusted usually) ?
> I tried to find that piece of convention in the different documents on
> standard CDS, but failed.
>
> Thanks for any help on this
> Peter
>
> Am 22.11.2012 10:03, schrieb ja...@fr...:
>> Hi Peter,
>> Great, thanks for setting up the code.
>> Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
>> Best regards
>> Pepe
>>
>>
>> ----- Original Message -----
>> From: "Peter Caspers" <pca...@gm...>
>> To: ja...@fr...
>> Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
>> Sent: Monday, 19 November, 2012 8:45:55 PM
>> Subject: Re: [Quantlib-dev] CDS last period
>>
>>
>> Hi Pepe,
>>
>> thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons.
>>
>>
>> Just a few comments why I did it how I did it:
>>
>>
>> If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too.
>>
>> If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ).
>>
>> However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that.
>>
>> Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important.
>>
>> Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not.
>>
>>
>> Thanks again and kind regards
>> Peter
>>
>>
>>
>> 2012/11/19 < ja...@fr... >
>>
>>
>> Peter, hi, apologies for the long delay, too many hobbies...
>>
>> The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date.
>> The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).
>>
>> I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
>> Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.
>>
>> Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter
>>
>> Best regards
>> Pepe
>>
>>
>> PS1
>> These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
>> Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:
>>
>> QL mkit QL(no rebate)
>> 6M 0.0013962 0.001391 0.0015124
>> 1Y 0.0024018 0.002396 0.0025179
>> 2Y 0.0066991 0.006683 0.0068754
>> 3Y 0.0128463 0.012795 0.0130785
>> 4Y 0.0227410 0.022554 0.0230541
>> 5Y 0.0357163 0.035221 0.0361139
>> 7Y 0.0610696 0.059787 0.0615613
>> 10Y 0.1036803 0.100268 0.1042708
>> 15Y 0.1578319 0.152918 0.1584299
>> 20Y 0.1948182 0.192336 0.1953589
>>
>>
>> As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
>> This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
>> Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.
>>
>> PS2
>> Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg.
>> Other points for the CDS:
>> -default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
>> -not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).
>>
>>
>>
>>