Template:M gen 1992 ISDA 5(a)(v): Difference between revisions

{{isdaprov|DUST}} is triggered by an ''[[acceleration]] following an'' [[event of default]] under the {{isdaprov|Specified Transaction}}, not upon the default itself<ref>Except where that happens on [[maturity]]: see drafting point below.</ref>. Since the {{isdaprov|Specified Transaction}} is between you and the other party to the {{isdama}}, there is no great loss — it is within your gift to accelerate the other contract — and to achieve [[set-off]] you would have to do so anyway.  

This is less drastic than the corresponding {{isdaprov|Cross Default}} provision, which imports all the {{isdaprov|Events of Default}} from all {{isdaprov|Specified Indebtedness}} into the present one<ref>I should say I am grateful to my correspondent Nick for his helpful suggestion here. I don’t get many correspondents so it is extra special when one writes in with actual useful feedback. Thanks Nick! (To my other correspondents: hi, nice to hear from you too, but no I have not been in a car accident recently.) </ref>, even if the counterparty to the defaulted contract has itself waived its rights to exercise.

===Default under ''any'' {{isdaprov|Specified Transaction}}, and the question of overreach===

{{isdaprov|DUST}} attaches to a “default” (not defined) under ''any'' {{isdaprov|Specified Transaction}}, and (other than under Section {{isdaprov|5(a)(v)}}(3) for delivery failures) not '''''all''''' {{isdaprov|Specified Transaction}}s. But if you have a credit concern with a counterparty under a derivative-like master agreement — even on a failure to pay — you are hardly likely to be closing out some, but not other transactions. Especially not now in these days of compulsory regulatory [[variation margin]]. You’ll be closing out the lot. Yet, with different rules depending on whether its a failure to pay (before or at maturity), failure to deliver or repudiation, we think {{icds}} has made it all a bit fiddly. They may be strictly correct, but come ''on''.  

So we have a lot of sympathy with the point, pedantic though it may be, that the [[DUST]] formulation could be simplified for transactions under any master agreement — even for repudiation — by requiring the {{isdaprov|Non-Defaulting Party}} to have closed out the whole arrangement, not just the {{isdaprov|Specified Transaction}} itself. An amendment to the following effect, rendered in ISDA’s leaden prose, wouldn’t be out of the question:

:“For the purposes of Section {{isdaprov|5(a)(v)}} where any {{isdaprov|Specified Transaction}} is governed by a [[master agreement]], an event will only be a {{isdaprov|Default Under Specified Transaction}} where it results in an early termination of all transactions outstanding under the documentation applicable to that {{isdaprov|Specified Transaction}}.”