I am trying to implement Andersen's method (All your hedges in one basket) to calculate delta for each underlying name. So once the survival probabilities are calculated, one name can be removed and then added back in with 1 bp higher spread. This method of removing and adding names is numerically unstable, especially when probability of default for that name is very high as compared to the rest. For example, if I remove a name and add it back in without changing the spread, my probabilities are slightly different.Has anyone implemented this method and faced a similar problem?

Could it be that the problem arises from the fact that in that procedure we end up taking the inverse cumulative normal of numbers in (0,1) and then again the cumulative normal of numbers nearby (or vice versa), thus losing resolution for Gaussians that are significantly positive? This is a common problem raising its head in many areas, so maybe it is what gives rise to the instabilities you observe. The workaround I have been using in this context for years is as follows: Whenever I need to do something like Phi^-1( Prob(z<x) ) for given x and known distribution of z, I branch switch. If P = Prob(z<x)<1/2, I compute straightaway Phi^-1(P), else, I compute Q=Prob(z>x) directly from the law of z, and then evaluate -Phi^-1(Q). The key is to compute the complementary term Q directly without ever subtracting two numbers, that are both near one, from each other. I have yet not seen an application where this approach was not applicable. One must, of course, not simply call a library function for all the required terms, though: you have to step through and ensure that the involved algorithms do at no point use similar complementary expressions such as Q=1-P. In other words, in terms of standard option theory, you must never use put-call parity as an aid behind the scenes of your calculation. By the way: this is why I would never advocate using put-call parity in an implementation; sooner or later the loss of accuracy in the wings will come to haunt you ;-(, especially during calibration to implied volatilities in the far-away tails.Does this possibly help for your common-factor-copula-cdo-delta calculations?Best regards,pj

pj, thanks for your comments. Your point is valid that it is because of multiple equal and opposite operations (such as multiply and divide by same number which may be very large or small) but not becuase of repeated application of cummulative normal and its inverse. Cummulative normals are involved only with probabilities conditioned on the common factor. Here the problem is with the part when I calculation unconsitional loss distribution from conditional probablities.

I'm using this approach and it works fine. Could you be running into floating point calculations issues for the language you use ? My code is in java.

I am using C#. I implemented a part of the calculations in excel and I get exactly same (wrong) results as my program. So may be it is a floating point calculation issue with microsoft. Also, it works fine for the names with spreads close to the average. If a name has very high spread, I end up having negative probabilities. Here is the gist of the algorithm that I am using -To add a name in the basket, I am using this recursive relation from i = 0 to kP(i, k) = q(k) * P(i-1, k-1) + (1 - q(k)) * P(i, k-1)Where P(i, k) is the probability of i defaults k names in the basket.q(k) is the probability of default for the kth name conditioned on the common factor.To remove a name, I use the following -P(i-1, k-1) = (P(i, k) - (1 - q(k)) * P(i, k-1))/q(k) for i = k to 1. Note that for i = k, P(k, k-1) = 0I think the repeated multiplication and division by q(k) is killing me. Do you think I am using the approach correctly?

the unstability is caused by dividing by a small number (a survial or default prob). you can fix this problem by solving the linear equation forward/backward depending on the particular name's (conditional) prob bigger or less than 0.5. Sovling the linear equation in these two manners are completely equivalent, i.e. giving you the same answer mathematically. However, dynamically chosing one over the other alleviates the precision strain on (any) programming language. Hope this helps.By the way, when a loss given default has many states (>2), this corner-cutting trick does not work anymore. The easier way (and more generic) is to use charastiristic function multiplication/division. There everything is stable since you are always on the unit circle.

Related question. I think that the delta of a specific name is very much dependent on the correlation of that name with the market. The use of implied (base) correlation would not give the desired effect. But if I am using historical asset correlation vector, am I then still pricing risk-neutral?

Hi Delta Experts,I have the following question regarding the calculation of CDO tranche delta and I would really appreciate if some expert could shed me some lights:To calculate the Delta, one would need to manually shift the CDS spreads of the underlying reference entities in order to compute the MTM change of the tranche NPV. However, I am not too sure how exactly the shifting is done. Do I simply need to add some small but fixed amount (say 1 or 2 or 5 bps) to each spread or perform a proportional shift (i.e. increase each spread by 1%) or some other shifting scheme? I personally found the resulting delta quite sensitive to what shifting scheme is used and I am having a hard time calibrating my delta to the market (for example, the US equity tranche typically has a Delta around 15x). Has anyone encountered similiar issues before or could some dealer side people provide some information.Thank you very much.Ted

Check out this paper:http://www.defaultrisk.com/pp_crdrv_79.htmIt is uses likelihood ratio in the computation of the deltas.

Usually people shift by a fixed amount and not by %. if you shift by %, delta hedging is not same as "Duration Neutral" or hedging against parallel shift.

Thanks for the replies, guys.The delta I calculated for the equity tranche is just too big comparing to the market quoted delta (which is around 15x) for CDX DJ IG4...I am looking for possible causes of this discrepency and my question is: does the practice of having an upfront payment and a running coupon for the equity tranche have any impact on calculating its delta?Thanks,Ted

yes, it does. Delta is lower for the upfront payment.

Hey Gulati,Thanks for your reply.Could you please provide a little bit more details? In other words, how would you calculate the tranche delta of the equity tranche with the 'upfront payment' factored in.I am having some trouble understanding (intuitively) why and how 'upfront payment' would affect the tranche delta.Thanks again,Ted

Ted,The whole purpose of pricing with an upfront is to de-lever the structure. If you get a fixed cashflow up front, it's value is insensitive w.r.t. future spread movements, thus it decreases the DV01 of the CDO tranche. Since the delta is simply the (Tranche DV01)/(Index DV01) it follows that the delta would be lower.Jamey

Hello!I'm a student and i'm trying to implement a very basic model in VBA for the recursive procedure of Andersen, Sidenius and Basu (All your hedges in one basket, eq 10) mentioned in eq (4) of paper Understanding the Risk of Synthetic CDOs (by Gibson).Can somebody help me?Thanks in advance