Bootstrapping default probabilities

[leibniz777]

Hi,

I have two questions/suggestions on the bootstrapping framework for credit curves.

1.) In the bootstrapping framework one has to use one of the classes SpreadCdsHelper or UpfrontCdsHelper. The pricing engine for the CDS valuation in the bootstrapping framework is set to MidPointCdsEngine in the method SpreadCdsHelper::resetEngine() resp. UpfrontCdsHelper::resetEngine(). Is there an easy way to use a different pricing engine, for example IntegralCdsEngine? If not I would suggest to extend the implementation so that the user would be able to choose the pricing engine.

2.)  The new upfront quoting mechanism suggested by ISDA assumes that the first premium coupon paid is a full coupon regardless when the start date is. When using the QuantLib CdsHelper classes one always gets the fractional coupon which depends on the start date. This is forced by the CdsHelper::initializeDates() method. Is there an easy way to use CDS in the bootstrapping algorithm that have a full first coupon? If not I would suggest to add an additional method to the CdsHelper class that can be used to set a full coupon.

[japari]

Hi,
on your first point; yes that would be nice. Thought of templates but the
initialization is a problem unless all engines have a 'setup' method. Other
people here know loads more on this.
I guess the helpers should always own the engine but in general I am short of
ideas.

On the second point; that is delegated to the rule. They were modified recently
for this, but for the old rule. A new rule might be needed, I am about to send
a CDX rule which matches what you mention.
Damn! there it goes my New Years surprise...

Best regards
Pepe

Quoting leibniz777 <[hidden email]>:

>
> Hi,
>
> I have two questions/suggestions on the bootstrapping framework for credit
> curves.
>
> 1.) In the bootstrapping framework one has to use one of the classes
> SpreadCdsHelper or UpfrontCdsHelper. The pricing engine for the CDS
> valuation in the bootstrapping framework is set to MidPointCdsEngine in the
> method SpreadCdsHelper::resetEngine() resp. UpfrontCdsHelper::resetEngine().
> Is there an easy way to use a different pricing engine, for example
> IntegralCdsEngine? If not I would suggest to extend the implementation so
> that the user would be able to choose the pricing engine.
>
> 2.)  The new upfront quoting mechanism suggested by ISDA assumes that the
> first premium coupon paid is a full coupon regardless when the start date
> is. When using the QuantLib CdsHelper classes one always gets the fractional
> coupon which depends on the start date. This is forced by the
> CdsHelper::initializeDates() method. Is there an easy way to use CDS in the
> bootstrapping algorithm that have a full first coupon? If not I would
> suggest to add an additional method to the CdsHelper class that can be used
> to set a full coupon.
> --
> View this message in context:
>

http://old.nabble.com/Bootstrapping-default-probabilities-tp26795832p26795832.html

> Sent from the quantlib-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[japari]

Hi again,

Quoting leibniz777 <[hidden email]>:

> 2.)  The new upfront quoting mechanism suggested by ISDA assumes that the
> first premium coupon paid is a full coupon regardless when the start date
> is. When using the QuantLib CdsHelper classes one always gets the fractional
> coupon which depends on the start date. This is forced by the
> CdsHelper::initializeDates() method. Is there an easy way to use CDS in the
> bootstrapping algorithm that have a full first coupon? If not I would
> suggest to add an additional method to the CdsHelper class that can be used
> to set a full coupon.

Do you mind testing if this CDX rules does what you expect please?, is part of
the stuff I am working on. I am using it for CDX and haven't feed it into the
bootstrapper. Maybe a more generic name would be better.

Best regards
Pepe

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[leibniz777]

Hi,

thanks for the quick answer and the files with the new "CDSIndex" rule. I have tested the rule and we now get a full coupon.

However the accrual begin date is the latest adjusted CDS date on or before T+1 calendar. The new rule gives the latest unadjusted CDS date as accrual begin date of the first coupon.

Example: if the evaluation is today (16/12/09) the accrual begin date should be using ISDA rules Monday 21/09/09. The CDSIndex rule gives Sunday 20/09/09.

Best regards


<quote author="Jose Aparicio-Navarro">

Do you mind testing if this CDX rules does what you expect please?, is part of
the stuff I am working on. I am using it for CDX and haven't feed it into the
bootstrapper. Maybe a more generic name would be better.

[japari]

Hi
Oliver, your right, the unadjustment is only on the last accrual date. The line
to remove of course is the test on the rule in:

[.....]
        // first date not adjusted for CDS schedules
        if (rule_ != DateGeneration::OldCDS /*&&
            rule_ != DateGeneration::CDSIndex*/) // <<<<<<<<<<<<<<<<<<<
            dates_[0] = calendar.adjust(dates_[0], convention);
        for (Size i=1; i<dates_.size()-1; ++i)
            dates_[i] = calendar.adjust(dates_[i], convention);
[.....]

Since the change in the standard rule is to make CDS work like the index maybe
we should change the name of the rule; "NewCDS" would eventually sound
obsolete. Any other ideas? "CreditBigBang"?, ...kidding.

Oliver, have you given a thought to the other points of the new conventions? I
havent googled what other people are doing about the 60 days lookback (forget
about succession by now) but setting up T-60 to be the P_{surv}=1 might give
unrealistic default probabilities.

Luigi, I am proposing patches to add cds index and relatives soon, but it also
contains a few minor changes that could go in 1.0 if its not too late. Aside
for the bug I filed (I also added some functionality now) theres nothing
important. The only files impacted and not in experimental would be: imm.*pp
dategenerationrule.*pp and schedule.cpp

Best regards
Pepe


Quoting leibniz777 <[hidden email]>:

>
> Hi,
>
> thanks for the quick answer and the files with the new "CDSIndex" rule. I
> have tested the rule and we now get a full coupon.
>
> However the accrual begin date is the latest adjusted CDS date on or before
> T+1 calendar. The new rule gives the latest unadjusted CDS date as accrual
> begin date of the first coupon.
>
> Example: if the evaluation is today (16/12/09) the accrual begin date should
> be using ISDA rules Monday 21/09/09. The CDSIndex rule gives Sunday
> 20/09/09.
>
> Best regards
>
>
>
>
> Do you mind testing if this CDX rules does what you expect please?, is part
> of
> the stuff I am working on. I am using it for CDX and haven't feed it into
> the
> bootstrapper. Maybe a more generic name would be better.
>
>
> --
> View this message in context:
>

http://old.nabble.com/Bootstrapping-default-probabilities-tp26795832p26811942.html

> Sent from the quantlib-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[leibniz777]

Hi Pepe,

of course all works fine after removing the test on the rule.

In the ISDA converter specification they use T+1 as protection effective date. I'm not sure that I understand the rule T - 60. What does this exactly mean that a credit event occured before trade date?


Best regards
Oliver


<quote author="Jose Aparicio-Navarro">
Hi
Oliver, your right, the unadjustment is only on the last accrual date. The line
to remove of course is the test on the rule in:

[.....]
        // first date not adjusted for CDS schedules
        if (rule_ != DateGeneration::OldCDS /*&&
            rule_ != DateGeneration::CDSIndex*/) // <<<<<<<<<<<<<<<<<<<
            dates_[0] = calendar.adjust(dates_[0], convention);
        for (Size i=1; i<dates_.size()-1; ++i)
            dates_[i] = calendar.adjust(dates_[i], convention);
[.....]

Since the change in the standard rule is to make CDS work like the index maybe
we should change the name of the rule; "NewCDS" would eventually sound
obsolete. Any other ideas? "CreditBigBang"?, ...kidding.

Oliver, have you given a thought to the other points of the new conventions? I
havent googled what other people are doing about the 60 days lookback (forget
about succession by now) but setting up T-60 to be the P_{surv}=1 might give
unrealistic default probabilities.


</quote>

[japari]

Hi,
It is a "settlement problem" if you want. In a CDS contract any of the parties
was able to claim triggering of the contract for an 'unnoticed event' that took
place between T+1 and today. To be able to solve the hedge problem this
situation poses a 60 days lookback window only is now set. ok, the timing of
the claim on an event is not in the models. Except for the quotes today. They
mean now they will cover events that might have taken place 60 days before so
one finds asking himself what is the prob that an event happened say a week ago
but it is not public yet.
Not being able to claim defaults from T+1 is what solves the hedge problem. But
it paves the way for clearing house CDS trading since now you have a limit date
to claim; "use it or loose it" now, which removes uncertainty.

If understood correctly this means that during T+1 to T+61 you have 'more
time' for an event triggering your contract than you used to have [or better..
your event phase space has larger critical mass than before the Bing Bang...
:-) ] and from T+61 now you have less (you do not go back to T+1) mass to
trigger you contract.

Should that reflect in the probabilities? The second situation does not show in
the models, one assumes if the event happens everyone knows and one of the
parties claims it inmediately (nothing to do with settlement), maybe this is
not correct now. But what do we do about the first situation? ignoring it (i.e.
continue assuming total information) would be one possibility, in line with the
previous. But who is not left with the feeling there is more risk than before
now during this first period? And the hedge?, one would miss the overlapping
periods. And what happens now when the CDS does not hedge an existing CDS but a
bond?

Have the feeling some arbitrage argument lurks there, havent given it
much time but I would like other peoples opinions/ideas.

My reading on this (all online):

The Big Bang: A Guide to the Standardized CDS Contract, Bank of America-Merrill
Lynch Research , February 2009
CDS Small Bang: Understanding the Global Contract & European Convention Changes
, Markit , July 20th, 2009
The CDS Big Bang , Otis Casey, Markit Magazine Spring 2009
The CDS Big Bang: Understanding the Changes to the Global CDS Contract and
North American Conventions , Markit , March 13, 2009
CDS 'big bang' could see 18% increase in tear-ups, Markit says. Risk Magazine,
April 2009

Best regards
Pepe




Quoting leibniz777 <[hidden email]>:

>
> Hi Pepe,
>
> of course all works fine after removing the test on the rule.
>
> In the ISDA converter specification they use T+1 as protection effective
> date. I'm not sure that I understand the rule T - 60. What does this exactly
> mean that a credit event occured before trade date?
>
>
> Best regards
> Oliver
>
>
>
> Jose Aparicio-Navarro wrote:
> >
> > Hi
> > Oliver, your right, the unadjustment is only on the last accrual date. The
> > line
> > to remove of course is the test on the rule in:
> >
> > [.....]
> >         // first date not adjusted for CDS schedules
> >         if (rule_ != DateGeneration::OldCDS /*&&
> >             rule_ != DateGeneration::CDSIndex*/) // <<<<<<<<<<<<<<<<<<<
> >             dates_[0] = calendar.adjust(dates_[0], convention);
> >         for (Size i=1; i<dates_.size()-1; ++i)
> >             dates_[i] = calendar.adjust(dates_[i], convention);
> > [.....]
> >
> > Since the change in the standard rule is to make CDS work like the index
> > maybe
> > we should change the name of the rule; "NewCDS" would eventually sound
> > obsolete. Any other ideas? "CreditBigBang"?, ...kidding.
> >
> > Oliver, have you given a thought to the other points of the new
> > conventions? I
> > havent googled what other people are doing about the 60 days lookback
> > (forget
> > about succession by now) but setting up T-60 to be the P_{surv}=1 might
> > give
> > unrealistic default probabilities.
> >
> >
> >
>
> --
> View this message in context:
>

http://old.nabble.com/Bootstrapping-default-probabilities-tp26795832p26829146.html

> Sent from the quantlib-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[leibniz777]

Hi,

I think one should use T or T+1 as protection start date for calculations which means that we set the value of a protection payment of a credit event taking place between T-60 and today to zero. Obviously this value is not equal to zero so that one would make an error.

One the other hand in the risk neutral valuation framework it is assumed that all traders have complete market information up to the valuation date. This means that all credit events in the past are known to the traders (which in reality is not the case). By arbitrage arguments this means that one has to set the non default probability at t=0 to 1. Setting the probability to a different value would mean violating the risk neutral valuation framework this doesn't hold?

Best regards
Oliver

[Luigi Ballabio]

On Thu, 2009-12-17 at 11:42 +0100, Jose Aparicio-Navarro wrote:
> Luigi, I am proposing patches to add cds index and relatives soon, but it also
> contains a few minor changes that could go in 1.0 if its not too late.

Ok for 1.0---I'd have the correct new CDS rules in there rather than the
old ones.  Send me a patch when you have the final version.

Thanks,
        Luigi


--

The surest way to make a monkey of a man is to quote him.
-- Robert Benchley



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[japari]

Quoting Luigi Ballabio <[hidden email]>:

> On Thu, 2009-12-17 at 11:42 +0100, Jose Aparicio-Navarro wrote:
> > Luigi, I am proposing patches to add cds index and relatives soon, but it
> also
> > contains a few minor changes that could go in 1.0 if its not too late.
>
> Ok for 1.0---I'd have the correct new CDS rules in there rather than the
> old ones.  Send me a patch when you have the final version.
>
> Thanks,
> Luigi
>

The name might not be the best of all, "CreditStd" instead?
I kept the old CDS rule, even if that period might be in the past there will be
outstanding contracts with that rule.

The patches werent generated with a svn client but with diff directly. Hope
thats all right. Test-suite passes.

This is a patch just for the rules, I am sending the other stuff through
sourceforge.

Best regards
Pepe
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Wed, 2009-12-23 at 08:18 +0100, Jose Aparicio-Navarro wrote:
> This is a patch just for the rules, I am sending the other stuff through
> sourceforge.

Done, thanks.

Luigi


--

The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users