Default Under Specified Transaction - ISDA Provision: Difference between revisions
Jump to navigation
Jump to search
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
{{fullanat2|isda|5(a)(v)|1992|5(a)(v)|2002}} | {{fullanat2|isda|5(a)(v)|1992|5(a)(v)|2002}} | ||
==Commentary== | ===Commentary=== | ||
This is like {{isdaprov|Cross Default}}, but for non "borrowing" style transactions - for example [[swap|swap agreements]] agreements and [[repo]]s, '''but only transactions between the two counterparties and their referenced {{isdaprov|Credit Support Provider}}s and {{isdaprov|Specified Entities}}'''. | This is like {{isdaprov|Cross Default}}, but for non "borrowing" style transactions - for example [[swap|swap agreements]] agreements and [[repo]]s, '''but only transactions between the two counterparties and their referenced {{isdaprov|Credit Support Provider}}s and {{isdaprov|Specified Entities}}'''. | ||
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==== | |||
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 point''': The reason for the second limb of the definition is to catch final payments, which can't be accelerated, since they're already due. | **'''Drafting point''': 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”?==== | |||
Could a wrongfully submitted notice of default be treated as a [[repudiatory|repudiation]]/[[anticipatory breach]] by the "[[non-defaulting party]]" giving the other party at least the right to withhold payments on the basis that this would constitute a {{isdaprov|Potential Event of Default}} by the party submitting the notice? There's not much law on point, but the starting point is "no" - it would simply be an ineffective notice. '''However''', a non-payment on the basis of an ineffective notice would be impermissible and may itself amount to a Failure to Pay. But as to the mere dispatch of the notice itself, there is relatively recent case law (albeit in the bond world) stating that an acceleration notice that is submitted wrongfully, i.e. when no actual event of default, is merely ineffective and does not give rise to a claim for breach of contract or damages from "defaulting party". Clearly this has not been considered in context of ISDA per se (and may be nuances here that would lead to different result) but at it is a start. | |||
===Comparison with {{isdaprov|Cross Default}}=== | ====Comparison with {{isdaprov|Cross Default}}==== | ||
*No requirement for a {{isdaprov|Threshold Amount}} to be hit before trigger: any default will trigger it. | *No requirement for a {{isdaprov|Threshold Amount}} to be hit before trigger: any default will trigger it. | ||
*Only relates to transactions between the two counterparties (or any {{isdaprov|Specified Entity}}) - a default by a counterparty under a derivatives transaction *with a third party* would not trigger this clause. | *Only relates to transactions between the two counterparties (or any {{isdaprov|Specified Entity}}) - a default by a counterparty under a derivatives transaction *with a third party* would not trigger this clause. | ||
{{ | {{seealso}} | ||
*[http://www.stroock.com/SiteFiles/Pub175.pdf The Importance Of Being Specified: Designating Affiliates - Strook] | *[http://www.stroock.com/SiteFiles/Pub175.pdf The Importance Of Being Specified: Designating Affiliates - Strook] | ||
{{t2|Events of Default|Breach of contract}} | {{t2|Events of Default|Breach of contract}} | ||
Revision as of 11:19, 12 January 2017
|
Commentary
This is like Cross Default, but for non "borrowing" style transactions - for example swap agreements agreements and repos, but only transactions between the two counterparties and their referenced Credit Support Providers and Specified Entities.
If a Counterparty (or its Credit Support Provider or Specified Entity) experiences an Event of Default under a swap agreement (or other transaction falling within the definition of Specified Transaction, which is typically wide - but check the Agreement!) with you, this constitutes an Event of Default under the ISDA Master Agreement.
Acceleration, not Default
DUST is triggered by an acceleration following an event of default under the Specified Transaction, not upon default itself (except where that happens on maturity - see drafting point below). 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 Transactions into the present one, even if the counterparty to the defaulted contract has itself waived its rights to exercise.
- Drafting point: 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”?
Could a wrongfully submitted notice of default be treated as a repudiation/anticipatory breach by the "non-defaulting party" giving the other party at least the right to withhold payments on the basis that this would constitute a Potential Event of Default by the party submitting the notice? There's not much law on point, but the starting point is "no" - it would simply be an ineffective notice. However, a non-payment on the basis of an ineffective notice would be impermissible and may itself amount to a Failure to Pay. But as to the mere dispatch of the notice itself, there is relatively recent case law (albeit in the bond world) stating that an acceleration notice that is submitted wrongfully, i.e. when no actual event of default, is merely ineffective and does not give rise to a claim for breach of contract or damages from "defaulting party". Clearly this has not been considered in context of ISDA per se (and may be nuances here that would lead to different result) but at it is a start.
Comparison with Cross Default
- No requirement for a Threshold Amount to be hit before trigger: any default will trigger it.
- Only relates to transactions between the two counterparties (or any Specified Entity) - a default by a counterparty under a derivatives transaction *with a third party* would not trigger this clause.