Re: [Quantlib-dev] CDS last period

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

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... <mailto: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).