Template:M gen 2002 ISDA 5(a)(v): Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
===[[Acceleration]], not [[Default]]=== | ===[[Acceleration]], not [[Default]]=== | ||
{{ | {{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. | 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=== | ===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''. | {{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: | 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 | :“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 same [[master agreement]].” | ||
===Final payments=== | ===Final payments=== |
Latest revision as of 10:13, 7 April 2021
Acceleration, not Default
DUST is triggered by an acceleration following an event of default under the Specified Transaction, not upon the default itself[1]. Since the Specified Transaction is between you and the other party to the ISDA Master Agreement, 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 Cross Default provision, which imports all the Events of Default from all Specified Indebtedness into the present one[2], even if the counterparty to the defaulted contract has itself waived its rights to exercise.
Default under any Specified Transaction, and the question of overreach
DUST attaches to a “default” (not defined) under any Specified Transaction, and (other than under Section 5(a)(v)(3) for delivery failures) not all Specified Transactions. 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 ISDA’s crack drafting squad™ 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 Non-Defaulting Party to have closed out the whole arrangement, not just the 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 5(a)(v) where any Specified Transaction is governed by a master agreement, an event will only be a Default Under Specified Transaction where it results in an early termination of all transactions outstanding under the same master agreement.”
Final payments
The reason for the second limb of the definition is to catch final payments, which can’t be accelerated as such, since they’re already due.
Differences between cross default and DUST
Ideally, cross default and DUST should be mutually exclusive. They are meant to dovetail with each other, not cross over. This will not stop mission creep from over-zealous credit departments, who will try to expand the scope of each, leading to all kinds of cognitive dissonances and righteous[3] indignation from the counterparty’s negotiator. As ammunition for your fruitless attempts to persuade the credit department to live in the real world for once, try these:
- Cross default generally references indebtedness where the exercising counterparty has significant loan-type exposure to the defaulter; DUST references bilateral derivative and trading transactions which tend not to be in the nature of indebtedness (it is true to say that the line between these can be gray, especially in the case of uncollateralised derivative relationships;
- Cross default is only triggered once a certain threshold amount of indebtedness is defaulted upon; DUST is triggered upon any breach;
- Cross default references your Counterparty owes to a third party outside your control; DUST references other obligations your counterparty owes you or an affiliate you can reasonably be expected to be in league with. (ie you can't generally trigger if your counterparty defaults on Specified Transactions it has on with third parties)
- DUST only comes about if the Specified Transaction in question has been actually accelerated, whereas cross default is available whether the primary creditor has accelerated or not. (A cross default which requires acceleration is called “cross acceleration”.)
- ↑ Except where that happens on maturity: see drafting point below.
- ↑ 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.)
- ↑ And, to be candid, rightful.