thanks a lot for your review and the testing. Sounds promising to me?
I added some more things to account for your test case below. The main
treat all other cases with the old code. I think your case should work
now, I get exactly the same hazard rates in both termstructures. It
changes. I also corrected the sign typo in the engine.
I don't use CDS quotes with upfronts. Is the dirty upfront quoted or the
> Hi,
> sorry I took a holiday break and ignored email.
>
> Thank you for the code, it works as we wanted. The agreement with the markit converter I get is always within 1bp for different spreads levels. Also i tested for two different dates (small and large rebates).
> Theres only one problem I had not thought of, and it is comning from what we are doing in the constructor of a run only quoted CDS:
> As a result if one bootstraps from market upfront cds and then reconstructs the run only cds helpers through the fair spreads of the cds-s (not the conventional of course) and rebootstrap with the new helpers... instead of obtaining the same hazard rates one gets differences in probabilities over 5%. This is because the run only CDS sets a fictitious upfront payment of zero amount on the schedule[0] date so the RPV01 of the upfront is zero since it lies in the past. The rebate amount uses this date and it is now multiplied by zero and therefore unaccounted for.
> I have changed line 58 of 'creditdefaultswap.cpp' to
> upfrontPayment_.reset(new SimpleCashFlow(0.0, protectionStart_));
> another option might have to use the protection start for the RPV01 of the rebate since this solution is still wrong because the forward case has non zero probability of knocking out the cds (and then the rebate). Even better might be to have a separate cashflow meber for the rebate, maybe of boost::optional type (and possibly the upfront too should be optional).
>
> Other minor comments: looks like theres a typo on the directionality sign of the rebate in 'integralcdsengine.cpp' and would it be better for performance to have the rebate accrual called within the upfPV01 calculation braces?
>
> Pls, tell me what you think
> Best
> Pepe
>
>
>
> ----- Mail original -----
> De: "Peter Caspers"<
[hidden email]>
> À: "Luigi Ballabio"<
[hidden email]>
> Cc:
[hidden email],
[hidden email]
> Envoyé: Lundi 22 Octobre 2012 21:17:28
> Objet: Re: [Quantlib-dev] CDS last period
>
> Yes. In fact I forgot to commit the adjusted curve calibration helpers
> which I did now to make the picture complete.
>
>
https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168>
> Also I should mention that the extensions are defensive in the sense
> that existing code will not change its behaviour. This is at the cost of
> usability though since the arguments are not really in a logical order
> any more. Also the default values will not represent the usual market
> conventions. Both could be changed easily and should be done in my
> opinion, but I leave this decision to Luigi and the other admins.
>
> Thank you, Peter
>
> Am 20.10.2012 23:20, schrieb Luigi Ballabio:
>> Great. For those not familiar with github, Peter's changes are at
>> <
https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>> From the link above, it's also possible to add notes to the changes.
>> As Peter says, it would be great if someone could have a look.
>>
>> Luigi
>>
>> On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers<
[hidden email]> wrote:
>>> Hi Luigi, Pepe, Roland,
>>>
>>> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
>>> case below I added a test case comparing the conventional spread computed
>>> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
>>> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
>>> without errors under the changes.
>>>
>>> I am neither a CDS nor a quantlib expert, so it would be great if someone
>>> could have a look ...
>>>
>>> Peter
>>>
>>> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>>>
>>>> Hi all,
>>>> sorry I've been sitting out of this one. Do go ahead (only one
>>>> thing: with regard to the day counter, I'd prefer to have an
>>>> additional parameter for the existing day counter, as in
>>>> Actual360(IncludeLastDay), rather than an additional day counter).
>>>>
>>>> You're also correct when you say that we'll need some expert to look
>>>> at the thing---speaking of which, how comfortable are you with git? If
>>>> you forked the QuantLib mirror I've put on github and pushed your
>>>> changes there, it would make it easier both to do a code review and to
>>>> merge the changes afterwards. No big deal if you want to just post
>>>> here though.
>>>>
>>>> Thanks,
>>>> Luigi
>>>>
>>>> On Tue, Oct 16, 2012 at 8:39 PM, Peter Caspers<
[hidden email]>
>>>> wrote:
>>>>> Hi Pepe,
>>>>>
>>>>> sure. I'll do the day counter and the last period thing in the fixed
>>>>> rate leg and create a new rate helper with accrual rebate. Then we can
>>>>> merge. Give me some days. I want to test against Bloomberg, the Markit
>>>>> calculator and perhaps also Murex.
>>>>>
>>>>> I guess Roland should approve the changes and the way they are done
>>>>> before they enter the library.
>>>>>
>>>>> Regards
>>>>> Peter
>>>>>
>>>>> Am 16.10.2012 12:31,
[hidden email]:
>>>>>> 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,
[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