82,891
edits
Default Under Specified Transaction - ISDA Provision: Difference between revisions
Default Under Specified Transaction - ISDA Provision (view source)
Revision as of 18:23, 8 March 2018
, 8 March 2018no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 6: | Line 6: | ||
If a [[Counterparty]] (or its {{isdaprov|Credit Support Provider}} or {{isdaprov|Specified Entity}}) experiences an {{isdaprov|Event of Default}} under a [[swap]] agreement (or other transaction falling within the definition of {{isdaprov|Specified Transaction}}, which is typically wide - but check the Agreement!) with you, this constitutes an {{isdaprov|Event of Default}} under the {{isdama}}. | If a [[Counterparty]] (or its {{isdaprov|Credit Support Provider}} or {{isdaprov|Specified Entity}}) experiences an {{isdaprov|Event of Default}} under a [[swap]] agreement (or other transaction falling within the definition of {{isdaprov|Specified Transaction}}, which is typically wide - but check the Agreement!) with you, this constitutes an {{isdaprov|Event of Default}} under the {{isdama}}. | ||
====Acceleration, not Default==== | ====Acceleration, not Default==== | ||
DUST is triggered by an ''acceleration following an'' event of default under the {{isdaprov|Specified Transaction}}, not upon default itself (except where that happens on maturity - see drafting point below). 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 Transaction}}s into the present one, even if the counterparty to the defaulted contract has itself waived its rights to exercise. | {{tag|DUST}} is triggered by an ''acceleration following an'' event of default under the {{isdaprov|Specified Transaction}}, not upon default itself (except where that happens on maturity - see drafting point below). 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 Transaction}}s into the present one, even if the counterparty to the defaulted contract has itself waived its rights to exercise. | ||
*''' | ====Drafting oddities==== | ||
*'''Payment acceleration versus delivery acceleration''': Upon a payment default under 5(a)(v)(1), only that particular transaction must be accelerated (it doesn't require full close out of the relevant Master Agreement. But on a delivery default under 5(a)(v)(3), that is only triggered if the whole Master Agreement is closed out. | |||
*'''Final payments''': The reason for the second limb of the definition is to catch final payments, which can't be accelerated, since they're already due. | |||
====What if I “jump the gun”?==== | ====What if I “jump the gun”?==== | ||