Re: Bootstrapping default probabilities

Posted by japari on
URL: http://quantlib.414.s1.nabble.com/Bootstrapping-default-probabilities-tp8376p8384.html

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