CDS ISDA pricing engine

[thrasibule]

Comments/reviews welcome! This closes #108 .

[tangent360]

I know this pull request has been dormant for some time but I wanted to run some tests and hopefully reignite the discussion on merging the changes into the master branch. However, I'm getting several compile errors (VS2015 Comm) which appear to be caused by the changes to ql/time/daycounters/actual360.hpp

They are all of the following nature:

ql/time/daycounters/actual360.hpp(46): error C2555: 'QuantLib::Actual360::Impl::dayCount': overriding virtual function return type differs and is not covariant from 'QuantLib::DayCounter::Impl::dayCount' (compiling source file ql\indexes\ibor\euribor.cpp)

Anyone else getting this?

[lballabio]

@thrasibule , may you give me permission to push a few commits to this PR? Instructions at https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/

[thrasibule]

@lballabio done! Let me know if this doesn't work.

[lballabio]

Yes, it worked. Let me know if the treatment of the NPV date in RiskyBond makes sense.

[lballabio]

The default is HalfDayBias everywhere except here. Is this on purpose?

[pcaspers]

It's been a while, but looking at the ISDA engine ctor we have a comment there

 +            AccrualBias / ForwardsInCouponPeriod corresponding
 +            to the standard model implementation C code are
 +
 +            prior 1.8.2    HalfDayBias / Flat
 +            1.8.2          NoBias / Flat
 +
 +            The theoretical correct setting would be NoBias / Piecewise
 +
 +            Todo: Clarify in which version of the standard model
 +            implementation C code the numerical problem of zero denominators
 +            is solved and how exactly.

so I'd say the default values should be "HalfDayBias / Flat / Taylor" everywhere to match the current actual standard implementation (assuming it has the "Taylor" fix). @thrasibule, @japari what do you think? Do you an updated information on what is actually implemented?

[thrasibule]

As far as I can see, the latest version of the isda model C code (1.8.2) implements HalfDayBias/Piecewise/Taylor.
The Taylor numerical fix was introduced in 1.7.2. Actually they do both None and Taylor (add 1e-50 and do a Taylor expansion for small values).
The Piecewise/Flat toggle is pretty useless at the moment. The ISDA code always did piecewise. Markit published a fix, which is an incorrect way of doing piecewise. The code got added as a comment but is not turned on. As far as I can see Flat doesn't correspond to any published code. We could add PiecewiseFix enum to the possible values, which implements the above pdf, and set Piecewise as default.
We can also change it to always also add 1e-50 when doing Taylor which would be closer to the official code, what do you think?

[lballabio]

Ok, how about I hard-code HalfDayBias/Piecewise/Taylor for this release so it covers the latest model, get it out, and then we think about how to extend it?

[thrasibule]

Fine by me!

[pcaspers]

Ok!

[lballabio]

Done. Please check that you get the output you expect from the CDS example.

[codingyesiamalway]

I am wondering if anyone can match ISDA calculation with this change. I could match the pv of the coupon/premium leg exactly, but the protection leg is off by about $200 for the $10mm notional cds I am testing. Anyone else had any luck?

[thrasibule]

I can match to the dollar usually. What are the swap settings you're trying to match, and what are you comparing it too? On Jan 2, 2018 02:41, "yuzhao88" <notifications@github.com> wrote: I am wondering if anyone can match ISDA calculation with this change. I could match the pv of the coupon/premium leg exactly, but the protection leg is off by about $200 for the $10mm notional cds I am testing. Anyone else had any luck? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#112 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeKqH2bXU7JIoU27b5uk7DcX0X8mr4qks5tGYlEgaJpZM4JQQNS> .

[codingyesiamalway]

I am comparing with bloomberg, but couldnt match the numbers. The discount curve matches bloomberg exactly, but the default probability from credit curve is off. I posted the code in here. I have spent many hours on this, and couldnt figure what is causing the difference. Also as I am looking for documentations, I couldnt find much info related to the Bootstraperror class. Specifically, what does curve -> data (used in the operator()) represent? Is the ith element the ith iteration of something like a hazard rate?

[lballabio]

@thrasibule , any chance you can enter the discussion on the mailing list and compare figures? Thanks!

[thrasibule]

@lballabio and @codingyesiamalway Just got back from vacation, I'll try to check the numbers later today and chime in on the mailing list.

[lballabio]

Thanks!

[codingyesiamalway]

@lballabio @thrasibule Many thanks!

[laj007]

Hi guys - i've just built a similar code trying to replicate BBG / ISDA Fair Value model (based on piecewise flat hazard curve from a CDS curve, which pass into the ISDA CDS engine) - same issue; I get close but not really on it.

If I build on a 6m tenor only (i.e. just one point on the curve), I'm dead on. The moment I add another tenor, it starts deviating.

It's surprising given that the similar implied-hazard rate toolkit works perfectly from points upfront to conventional spread (and vice-versa).

Were there any recent developments / fixes ?

Thanks!

[thrasibule]

There is no such thing as a curved ISDA model, Markit spreads are built one at a time ignoring the previous tenors. If you can share your code, and what you're comparing too exactly, I can try to see if I can help you reconcile it with bloomberg.

…

On Wed, Mar 3, 2021 at 9:47 PM laj007 ***@***.***> wrote: Hi guys - i've just built a similar code trying to replicate BBG / ISDA Fair Value model (based on piecewise flat hazard curve from a CDS curve, which pass into the ISDA CDS engine) - same issue; I get close but not really on it. If I build on a 6m tenor only (i.e. just one point on the curve), I'm dead on. The moment I add another tenor, it starts deviating. It's surprising given that the same toolkit works perfectly from points upfront to conventional spread (and vice-versa). Were there any recent developments / fixes ? Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#112 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYVKFQR6ELPTOJOSGZ3X3TB3YFDANCNFSM4CKBANJA> .

[laj007]

Yes - exactly - from the par spread curve (each separate tenors, agree), the goal is to use piecewise flat hazard rates and come up with points upfront (PV).

Here I'm using 6m to 10y points, trying to price a 5Y CDS (termDate = 12/20/2025) on tradeDate = 3/3/2021, with the traditional ISDA discount curve (discCurve). Bloomberg would return value of -2.60 but I consistently land in the -2.74 to -2.76 range.

Do you see anything wrong in the code structure / use of classes ?

Many thanks.

`
cdsSchedule = ql.Schedule(tradeDate, termDate,
3*ql.Period(ql.Monthly),
ql.WeekendsOnly(),
ql.Following, ql.Unadjusted,
ql.DateGeneration.CDS, False)

cdsTenors = [ql.Period(6, ql.Months), ql.Period(1, ql.Years), ql.Period(2, ql.Years), ql.Period(3, ql.Years),
              ql.Period(4, ql.Years), ql.Period(5, ql.Years),ql.Period(7, ql.Years),ql.Period(10, ql.Years)]

cdsCurve = [6.68, 8.82, 12.85, 21.26, 32.28, 45.28, 63.45, 84.94]

cdsHelpers = [ql.SpreadCdsHelper((CDS_spread/1e4), CDS_tenor, 0, ql.TARGET(), ql.Quarterly, ql.Following,
              ql.DateGeneration.TwentiethIMM, ql.Actual365Fixed(), recovery, discCurve)
              for CDS_spread, CDS_tenor in zip(cdsCurve, cdsTenors)]

pdCurve = ql.PiecewiseFlatHazardRate(tradeDate, cdsHelpers, ql.Actual365Fixed())
probabilityCurve = ql.RelinkableDefaultProbabilityTermStructureHandle()
probabilityCurve.linkTo(pdCurve)

engine = ql.IsdaCdsEngine(probabilityCurve,recovery,discCurve)

conventionalTrade = ql.CreditDefaultSwap(ql.Protection.Seller,100,0,cpn,cdsSchedule,
                                         ql.Following,ql.Actual360(),True,True,tradeDate+1,
                                         ql.WeekendsOnly().advance(tradeDate,3*ql.Period(ql.Daily)),
                                         ql.FaceValueClaim(), ql.Actual360(True))

conventionalTrade.setPricingEngine(engine)

p = conventionalTrade.notional() * conventionalTrade.fairUpfront()`

[thrasibule]

First your yield curve needs to match with the ISDA yield curve on bloomberg, which would be the first thing to check.
Then you're building your cdshelpers wrong. See this example. And actually needs to use CDS2015, not CDS. But this would be a better discussion for the mailing list.

[laj007]

Thanks for helping out with this - really appreciated.

First, when I follow your example - using Python - I get a function overload problem (TypeError: new_SpreadCdsHelper expected at most 12 arguments, got 16). Further, my function above has 10 arguments and, if I try adding only one, the most important I believe (model = ql.CreditDefaultSwap.ISDA), the Python function does not recognize the keyword argument (even if explicitly used here : https://quantlib-python-docs.readthedocs.io/en/latest/helpers/credit.html). How could it be fixed it in a Python context ?

Second, when I do use CDS2015, it gets me almost very very close to the BBG number, so perhaps solving my first question won't impact much.

Thanks again!

[thrasibule]

It seems it was committed recently see here: lballabio/QuantLib-SWIG@93cc887#diff-18b6c473a5106cdeafc43b2ddbd1c2041cb4ecb011cecfe6215ca7119b82ad20. So I would suggests updating you quantlib swig bindings.

…

On Wed, Mar 10, 2021 at 4:14 PM laj007 ***@***.***> wrote: Thanks for helping out with this - really appreciated. First, when I follow your example - using Python - I get a function overload problem (TypeError: new_SpreadCdsHelper expected at most 12 arguments, got 16). Further, my function above has 10 arguments and, if I try adding only one, the most important I believe (model = ql.CreditDefaultSwap.ISDA), the Python function does not recognize the keyword argument (even if explicitly used here : https://quantlib-python-docs.readthedocs.io/en/latest/helpers/credit.html). How could it be fixed it in a Python context ? Second, when I do use CDS2015, it gets me almost very very close to the BBG number, so perhaps solving my first question won't impact much. Thanks again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#112 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYVKFJWWG4W4KYLHKSVEDTC7HK3ANCNFSM4CKBANJA> .