Re: [Quantlib-dev] credit modeling, Issuer, etc.
Posted by japari on
URL: http://quantlib.414.s1.nabble.com/credit-modeling-Issuer-etc-tp7165p7166.html
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]>:
> 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
URL: http://quantlib.414.s1.nabble.com/credit-modeling-Issuer-etc-tp7165p7166.html
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]>:
> 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
recoveryrate_ts.zip (18K) | Free forum by Nabble | Edit this page |