QuantLib › quantlib-users

credit modeling, Issuer, etc.

Classic

List

Threaded

5 messages Options

Chris Kenyon-2

credit modeling, Issuer, etc.

Dear All,

I'd like to start a bit of a discussion about credit modeling in QL given that it is starting to appear and that the credit crisis has done some very effective stress-testing of assumptions. So I'll divide this into high-level and technical sections.

High-Level

Term structures are one of the fundamental things in QL, but I'm not sure that QL has the right ones for credit. In the market I can trade a CDS and find quotes on Bloomberg. However, I cannot directly trade a recovery rate (except OTC via digital default swaps, or recovery swaps as they are sometimes know). Since the tradelable numbers should, IMNSHO, be fundamental QL needs:
    CdsTermStructure
and (maybe)
    RecoveryRateTermStructure
Only then can we get on with defining default probability term structures. Yes, you can argue that the CDS quotes themselves provide the term structure (if you add recoveries ...) ... but that is not the same as packaging this info up in a useful way.
    Also, if you want an instrument-based probability of default term structure then you should give it recovery swaps as well as CDSs - giving it a recovery rate doesn't specify what observable it came from (assumptions anyone?).

Technical

The class Issuer currently holds a default probability term structure and a recovery rate. However, if you look on Markit (or one of its competitors) then you see that a legal entity can have up to about 10 different CDS spread curves quoted - these come from different currencies, seniorities, and restructuring/default clauses.

I suggest that the Issuer class should be polymorphic (i.e. lots of virtual's) and that it also inherit from Observer/Observable for ease of use with the rest of QL. Then users can add as much complexity as they want for different situations.

Well, that's my contribution to starting the dicussion ... all replies encouraged!

Best regards,
Chris

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

japari

Re: credit modeling, Issuer, etc.

Hi,
The recovery is treated as a parameter and not modelled.
But without thinking of calibration of the recovery model, even kept as a
parameter I agree that there are incoherences:

----<Technical>-------
The same name has different curves by seniority and as such an issuer in the
lib could be representing a name/seniority couple. But it is not because the
events register by issuer, and all seniorities should be registered with the
same event. I believe theres an issue here; one issuer can have different
recoveries (seniorities) but only one default probability.

----<Market>----------
At least conceptually, the market might think otherwise: These are quotes for
Abbey Nat. on April, 24, 2006 with respective recovery rates of 0.2, 0.15, 0.4
and 0.2 (i.e. quotes during "quiet times")

6 1 2 3 4 5 7 10
M Y Y Y Y Y Y Y
JRSUBUT2 0 0 0 0.000782933 0 0.001275 0 0.002430464

PREFT1 0 0 0.0014 0 0 0.0036 0.0044 0.0054

SNRFOR 0.000174507 0.000233197 0.000314393 0.000428969 0.000617 0.000729813
0.000920194 0.001219621

SUBLT2 0.0002194 0.000350379 0.000574109 0.000712179 0.000965 0.001210217
0.001680983 0.002361352

If one calibrates HRs and computes the probability of default 10Y ahead one
gets values ranging from 7 to 2 percent. Now, we can blame liquidity (two last
curves are close and are more liquid, they are rated curves) but maybe the
model is not good enough. The problem with constant/parametric RR is that once
you fix one theres no way your going to be able to get a second coherent curve,
you could as much fix another recovery for a single tenor curve.

So the concept of a constant RR for all tenors is flawed..... (still the
library should provide IMHO the probability model that is a standard)

This brings in your point of a term structure for the recovery rate. Again we
should eventually have a model of the recovery rate. But lets first fix the
issuer point (a data/problem representation problem). The recovery rate is not
an issuer property; maybe an issuer-seniority, maybe a model parameter. And we
should not allow calibration of HR curves with helpers from different
seniorities (mea culpa).

Regards
pepe

Quoting Chris Kenyon <[hidden email]>:

> Dear All,
>
> I'd like to start a bit of a discussion about credit modeling in QL given
> that it is starting to appear and that the credit crisis has done some very
> effective stress-testing of assumptions. So I'll divide this into high-level
> and technical sections.
>
> High-Level
>
> Term structures are one of the fundamental things in QL, but I'm not sure
> that QL has the right ones for credit. In the market I can trade a CDS and
> find quotes on Bloomberg. However, I cannot directly trade a recovery rate
> (except OTC via digital default swaps, or recovery swaps as they are
> sometimes know). Since the tradelable numbers should, IMNSHO, be fundamental
> QL needs:
> CdsTermStructure
> and (maybe)
> RecoveryRateTermStructure
> Only then can we get on with defining default probability term structures.
> Yes, you can argue that the CDS quotes themselves provide the term structure
> (if you add recoveries ...) ... but that is not the same as packaging this
> info up in a useful way.
> Also, if you want an instrument-based probability of default term
> structure then you should give it recovery swaps as well as CDSs - giving it
> a recovery rate doesn't specify what observable it came from (assumptions
> anyone?).
>
> Technical
>
> The class Issuer currently holds a default probability term structure and a
> recovery rate. However, if you look on Markit (or one of its competitors)
> then you see that a legal entity can have up to about 10 different CDS spread
> curves quoted - these come from different currencies, seniorities, and
> restructuring/default clauses.
>
> I suggest that the Issuer class should be polymorphic (i.e. lots of
> virtual's) and that it also inherit from Observer/Observable for ease of use
> with the rest of QL. Then users can add as much complexity as they want for
> different situations.
>
> Well, that's my contribution to starting the dicussion ... all replies
> encouraged!
>
> Best regards,
> Chris

japari

Re: [Quantlib-dev] credit modeling, Issuer, etc.

In reply to this post by Chris Kenyon-2

Hi Chris, all
With such a great tool is easy to copy/paste a calibrator in one evening. I
would take the code with a pinch of salt then... :-)
Its not intended to be added to the lib as it is.

Rather than pricing a digital, which would left me with the problem of finding
data, I have first calibrated the most senior curve hazard rates with a flat
recovery and then switched to a recovery rate term structure calibration for
the remining sniorities.

What I have done is a shortcut to have quick numbers, this is not a
bootstrapping problem but a more complex optimization. A problem that this
library can tackle by the way.
I havent tried but I wonder if I had calibrated in a different order, i.e.
junior
flat RR first I would have obtained curves more often. The "flatteness" impossed
on the first calibration is a huge restriction.

Initially the curves were quoted with these RRs:
SNRFOR 0.4
SUBLT2 0.2
JRSUBUT2 0.2
PREFT1 0.15

Output for the example previously posted (inputs are in the source, it doesn't
dump, this is from the debugger):

38831 39071 39253 39619 39986 40350 40714 41445 42541
TODAY
0.0017 0.0017 0.0031 0.0041 0.0069 0.0128 0.0127 0.0152 0.0221 HRs
6M 1Y 2Y 3Y 4Y 5Y 7Y 10Y
SNRFOR 0.9 0.9 0.9 0.9 0.9 0.9 0.9 0.9 0.9
RRs
SUBLT2 0.87 0.87 0.79 0.80 0.90 0.81 0.82 0.77 0.82 RRs
JRSUBUT2 0.82 0.82 0.84 0.73 RRs
PREFT1 0.55 0.55 0.45 0.65 0.56 RRs

38831 39071 39253 39619 39986 40350 40714 41445 42541
TODAY
0.0012 0.0012 0.0021 0.0027 0.0046 0.0085 0.0084 0.0101 0.0145 HRs
6M 1Y 2Y 3Y 4Y 5Y 7Y 10Y
SNRFOR 0.85 0.85 0.85 0.85 0.85 0.85 0.85 0.85 0.85 RRs
SUBLT2 0.81 0.81 0.68 0.70 0.85 0.71 0.73 0.65 0.73 RRs
JRSUBUT2 0.73 0.73 0.76 0.60 RRs
PREFT1 0.33 0.33 0.17 0.47 0.34 RRs

38831 39071 39253 39619 39986 40350 40714 41445 42541
TODAY
0.0009 0.0009 0.0016 0.0021 0.0035 0.0064 0.0063 0.0076 0.0108 HRs
6M 1Y 2Y 3Y 4Y 5Y 7Y 10Y
SNRFOR 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 0.8 RRs
SUBLT2 0.75 0.75 0.58 0.61 0.80 0.62 0.63 0.53 0.64 RRs
JRSUBUT2 0.63 0.63 0.69 0.47 RRs
PREFT1 NO CALIBRATION RRs

38831 39071 39253 39619 39986 40350 40714 41445 42541
TODAY
0.0004 0.0004 0.0008 0.0010 0.0017 0.0032 0.0032 0.0038 0.0054 HRs
6M 1Y 2Y 3Y 4Y 5Y 7Y 10Y
SNRFOR 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 0.6 RRs
SUBLT2 0.50 0.50 0.15 0.21 0.60 0.23 0.27 0.07 0.27 RRs
JRSUBUT2 NO CALIBRATION RRs
PREFT1 NO CALIBRATION RRs

38831 39071 39253 39619 39986 40350 40714 41445 42541
TODAY
0.0003 0.0003 0.0005 0.0007 0.0012 0.0021 0.0021 0.0025 0.0036 HRs
6M 1Y 2Y 3Y 4Y 5Y 7Y 10Y
SNRFOR 0.4 0.4 0.4 0.4 0.4 0.4 0.4 0.4 0.4 RRs
SUBLT2 NO CALIBRATION RRs
JRSUBUT2NO CALIBRATION RRs
PREFT1 NO CALIBRATION RRs

This last case corresponds to the quoted data and the calibration fails since it
is
not possible to find a RR in the range 0-1 for those probabilities for the given
spread.

A back of envelope calc is possible, since we are freezing the probabilities if
we had one coupon only this would hold: RR_2 = 1-(1-RR_1) S_2/S_1
S_1 is the spread of the curve we use for HR calibration for that tenor and RR_1
is the flat RR.
if one uses this as an approximation RR_2 becomes negative around the points
where
the calibration fails. Since the helpers impose the domain [0-1] it does not cut
the axis.

Using the most junior as a digital (RR close to zero) I cant calibrate any of
the
RR curves unless I increase the RR. I interpret
this as due to the small number of points for that curve combined to the linear
interpolation in the HRs. I have to put this into a wsheet to play easily with
it.

----
The other subject was the data structure, am I the only one having a problem
with
a one to one reltaion between issuer and recovery? Shouldnt we have a
std::map<Seniority, Real-TS-model? > Issuer::recoveryRates and a method
Issuer::getRecovery(date,...) ? This does not include the currency though, since
it will get complex and we are not sure it would include every 'key' to index
the recovery rate. I agree that a class interface is the answer.

Shouldnt we also have (rather than a different engine) a digital flag for the
CDSs and the corresponding argument?

Another point that I think it was Simon who raised a few months ago is to
include the CDSs upfronts.

Regards
Pepe

Quoting Chris Kenyon <[hidden email]>:

recoveryrate_ts.zip (18K) Download Attachment

Luigi Ballabio

Re: [Quantlib-dev] credit modeling, Issuer, etc.

On Fri, 2009-02-20 at 08:30 +0100, Jose Aparicio-Navarro wrote:
> The other subject was the data structure, am I the only one having a problem
> with a one to one reltaion between issuer and recovery?

No, you're not the only one. The data structure is wrong.

However, I'm not sure that I would commit to a given class interface at
this time. It would probably take some trials to get it right, and
since I'd like to get release 1.0 out in a few months (and doing so, to
freeze the existing interfaces) I don't think we have the time for that.

Then again, the current Issuer class is wrong and should not go into
release 1.0 either. What I would do at this time is to remove the class
from the library and pass its components to the methods that were
accepting it. For instance, instead of

MidPointCdsEngine(const Issuer& issuer,
const Handle<YieldTermStructure>& discountCurve);

I would write

MidPointCdsEngine(
const Handle<DefaultProbabilityTermStructure>& probability,
Real recoveryRate,
const Handle<YieldTermStructure>& discountCurve,
const std::vector<boost::shared_ptr<DefaultEvent> >& events);

which is no longer so wrong---it just assumes that the correct
probability curve and recovery rate were chosen externally. Once we
experiment a bit and settle on an Issuer design, we can add the old
constructor back without breaking existing code.

Thoughts?

Luigi

--

Every solution breeds new problems.
-- unknown

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Chris Kenyon-2

Re: [Quantlib-dev] credit modeling, Issuer, etc.

Makes sense - better not to have it in the current form and maybe not enough time to get it right before 1.0. Your suggestion on the interfaces arranges so no breakage later. I really need it - but not in its current form.

Regards,
Chris

From: Luigi Ballabio <[hidden email]>
To: Jose Aparicio-Navarro <[hidden email]>
Cc: Chris Kenyon <[hidden email]>; Roland Lichters <[hidden email]>; Simon Ibbotson <[hidden email]>; [hidden email]; [hidden email]
Sent: Friday, February 20, 2009 5:15:20 PM
Subject: Re: [Quantlib-dev] credit modeling, Issuer, etc.

On Fri, 2009-02-20 at 08:30 +0100, Jose Aparicio-Navarro wrote:
> The other subject was the data structure, am I the only one having a problem
> with a one to one reltaion between issuer and recovery?

No, you're not the only one. The data structure is wrong.

However, I'm not sure that I would commit to a given class interface at
this time. It would probably take some trials to get it right, and
since I'd like to get release 1.0 out in a few months (and doing so, to
freeze the existing interfaces) I don't think we have the time for that.

Then again, the current Issuer class is wrong and should not go into
release 1.0 either. What I would do at this time is to remove the class
from the library and pass its components to the methods that were
accepting it. For instance, instead of

MidPointCdsEngine(const Issuer& issuer,
const Handle<YieldTermStructure>& discountCurve);

I would write

MidPointCdsEngine(
const Handle<DefaultProbabilityTermStructure>& probability,
Real recoveryRate,
const Handle<YieldTermStructure>& discountCurve,
const std::vector<boost::shared_ptr<DefaultEvent> >& events);

which is no longer so wrong---it just assumes that the correct
probability curve and recovery rate were chosen externally. Once we
experiment a bit and settle on an Issuer design, we can add the old
constructor back without breaking existing code.

Thoughts?

Luigi

--

Every solution breeds new problems.
-- unknown