Posted by
Peter Caspers-4 on
Oct 09, 2012; 8:00pm
URL: http://quantlib.414.s1.nabble.com/CDS-last-period-tp13598p13600.html
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