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

[Jose Aparicio-N. <ja...@fr...>]

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 <chr...@ya...>:

> 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