Posted by
japari on
Oct 16, 2012; 10:31am
URL: http://quantlib.414.s1.nabble.com/CDS-last-period-tp13598p13603.html
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:
[hidden email]
À: "Peter Caspers" <
[hidden email]>
Cc:
[hidden email]
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:
[hidden email]
À: "Peter Caspers" <
[hidden email]>
Cc:
[hidden email]
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" <
[hidden email]>
À:
[hidden email]
Cc:
[hidden email]
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
[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------------------------------------------------------------------------------
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