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

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

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 <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