Default Under Specified Transaction - ISDA Provision: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
← Older edit
VisualWikitext
No edit summary
 
(25 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{fullanat2|isda|5(a)(v)|1992|5(a)(v)|2002}}
{{nman|isda|2002|5(a)(v)}}
===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}}'''.
 
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.
 
====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}}====
*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.
 
{{seealso}}
*[http://www.stroock.com/SiteFiles/Pub175.pdf The Importance Of Being Specified: Designating Affiliates - Strook]
 
{{t2|Events of Default|Breach of contract}}

Latest revision as of 16:55, 14 August 2024

2002 ISDA Master Agreement

A Jolly Contrarian owner’s manual™

5(a)(v) in a Nutshell™

The JC’s Nutshell™ summary of this term has moved uptown to the subscription-only ninja tier. For the cost of ½ a weekly 🍺 you can get it here. Sign up at Substack. You can even ask questions! Ask about it here.

Original text

5(a)(v) Default Under Specified Transaction. The party, any Credit Support Provider of such party or any applicable Specified Entity of such party:―
(1) defaults (other than by failing to make a delivery) under a Specified Transaction or any credit support arrangement relating to a Specified Transaction and, after giving effect to any applicable notice requirement or grace period, such default results in a liquidation of, an acceleration of obligations under, or an early termination of, that Specified Transaction;
(2) defaults, after giving effect to any applicable notice requirement or grace period, in making any payment due on the last payment or exchange date of, or any payment on early termination of, a Specified Transaction (or, if there is no applicable notice requirement or grace period, such default continues for at least one Local Business Day);
(3) defaults in making any delivery due under (including any delivery due on the last delivery or exchange date of) a Specified Transaction or any credit support arrangement relating to a Specified Transaction and, after giving effect to any applicable notice requirement or grace period, such default results in a liquidation of, an acceleration of obligations under, or an early termination of, all transactions outstanding under the documentation applicable to that Specified Transaction; or
(4) disaffirms, disclaims, repudiates or rejects, in whole or in part, or challenges the validity of, a Specified Transaction or any credit support arrangement relating to a Specified Transaction that is, in either case, confirmed or evidenced by a document or other confirming evidence executed and delivered by that party, Credit Support Provider or Specified Entity (or such action is taken by any person or entity appointed or empowered to operate it or act on its behalf);
See ISDA Comparison for a comparison between the 1992 ISDA and the 2002 ISDA.
The Varieties of ISDA Experience
Subject 2002 (wikitext) 1992 (wikitext) 1987 (wikitext)
Preamble Pre Pre Pre
Interpretation 1 1 1
Obligns/Payment 2 2 2
Representations 3 3 3
Agreements 4 4 4
EODs & Term Events 5 Events of Default: FTPD • Breach • CSD • Misrep • DUST • Cross Default • Bankruptcy • MWA Termination Events: Illegality • FM • Tax Event • TEUM • CEUM • ATE 5 Events of Default: FTPD • Breach • CSD • Misrep • DUST • Cross Default • Bankruptcy • MWA Termination Events: Illegality • Tax Event • TEUM • CEUM • ATE 5 Events of Default: FTPD • Breach • CSD • Misrep • DUSS • Cross Default • Bankruptcy • MWA Termination Events: Illegality • Tax Event • TEUM • CEUM
Early Termination 6 Early Termination: ET right on EOD • ET right on TE • Effect of Designation • Calculations; Payment Date • Payments on ET • Set-off 6 Early Termination: ET right on EOD • ET right on TE • Effect of Designation • Calculations • Payments on ET • Set-off 6 Early Termination: ET right on EOD • ET right on TE • Effect of Designation • Calculations • Payments on ET
Transfer 7 7 7
Contractual Currency 8 8 8
Miscellaneous 9 9 9
Offices; Multibranch Parties 10 10 10
Expenses 11 11 11
Notices 12 12 12
Governing Law 13 13 13
Definitions 14 14 14
Schedule Schedule Schedule Schedule
Termination Provisions Part 1 Part 1 Part 1
Tax Representations Part 2 Part 2 Part 2
Documents for Delivery Part 3 Part 3 Part 3
Miscellaneous Part 4 Part 4 Part 4
Other Provisions Part 5 Part 5 Part 5

Resources and Navigation

Index: Click ᐅ to expand:
ISDA

Comparisons

DUST has been expanded in five significant ways by the 2002 ISDA. See the summary and general sections for details.

Basics

The connoisseur’s negotiation oubliette.

Default Under Specified Transaction — colloquially, “DUST” — is often confused with Cross Default. In fact, they’re meant to be mutually exclusive. That won’t stop folks conflating them, though. Look, we all do it.

DUST is like Cross Default, but where Cross Default references indebtedness owed to third parties, DUST is all about non-“borrowing” style transactions — e.g., swap agreements, stock loans[1] and repos, but only transactions between the two counterparties.[2]

If a Counterparty[3] experiences an Event of Default under a swap agreement (or other “Specified Transaction”[4] with you, this will be an Event of Default under the ISDA Master Agreement.

Changes from the 1992 Master Agreement

DUST overwent quite a makeover in the 2002 ISDA. For example:

Mini-closeout carveout: Defaults require the acceleration of just the Specified Transaction in question (for general defaults) but off all outstanding transactions under the relevant master agreement (for delivery defaults). This change was made with mini-close-out under repos and stock loans in mind — a concept which the stock loan market invented after the 1992 ISDA was published, so you can’t blame ISDA’s crack drafting squad™ for overlooking it at first — where delivery failures under are common and do not of themselves indicate weakness in the Defaulting Party’s creditworthiness.

Credit support failures covered: DUST under the 2002 ISDA can be triggered by default under a credit support arrangement relating to a Specified Transaction. These weren’t included for the 1992 ISDA DUST.

Shortened cure period: In tune with the general tightening up of cure periods — you know, we’re in a new millennium, computers work properly nowadays, and all that — the cure period for a failure to make a final or early termination payment on a Specified Transaction has been reduced from three days to one. This caused many a credit officer to sadly shake her head and refuse to move to the new agreement.

Repudiation evidence: Repudiation was modified to add the phrase “...or challenges the validity of ... after “... disaffirms, disclaims, repudiates or rejects ...” to reduce ambiguity as to whether a party’s action constitutes a repudiation. Also, we imagine, by way of stiffening the criteria for what counts as a repudiation, the 2002 requires written evidence that the repudiating party has an extended middle finger. This rules out being able to close out cornered hedge-fund managers, having been “brought to the negotiating table” by their fund’svproximity to a NAV trigger and who are not enjoying having their “feet held to the fire”, shouting “Well, bugger you, I shan’t pay, and let’s see how you like that” in the heat of the moment, when they really didn’t mean it, only to discover they had inadvertently repudiated a contract they were otherwise in perfect compliance with. Of course, no risk officer would dream of closing out an ISDA Master Agreement based on an intemperate oral communication, or the proverbial extended middle finger, for which she could not subsequently prove with fairly compelling evidence. But still.

Widened definition of Specified Transaction: The “Specified Transaction” concept has been broadened to include additional transaction types such as repos, and to include a catchall clause designed to include any future derivative products that have not been thought of yet.

Voltaire and DUST

In which ISDA’s crack drafting squad™ got bogged down in the weeds once in 1987, doubled down in their in-weed bogged-downness in 2002, and we’ve been dealing with resulting confusion ever since. A case of perfection being the enemy of good enough, as Voltaire would say, in the JC’s humble opinion, especially in these modern times where, thanks to compulsory daily zero-threshold variation margining, DUST is even more of a dead letter than it even was in the good old days. To our knowledge, no ISDA Master Agreement in history has been closed out using, exclusively, Section 5(a)(v).

That said, the 1992 ISDA version is a bit skew-wiff as regards mini-closeout, and you may find assiduous counterparties hungrily licking their lips at the prospect of a hearty negotiation about this bald man’s comb.

We are talking about other derivative-like transactions, between you and the same counterparty, where the counterparty presents a clear and present danger of blowing up, but where that behaviour has not yet manifested under the present ISDA Master Agreement, meaning you have no grounds to blow them up directly. So, you know, fairly implausible scenario, but still. You want to use the event arising under this other Specified Transaction to detonate the present ISDA. The squad breaks your ability to do so down in to four scenarios:

  • Counterparty fails to pay amounts falling due before maturity on a Specified Transaction, and you accelerate that transaction, but not necessarily others under the same master agreement. Here the principle is that any obligation to pay a sum of money on time is fundamental, of the essence and speaks indelibly to a merchant’s credit, whether or not one accelerates other related Specified Transactions (though, actually, walk me through the scenarios in which you wouldn’t, or even weren’t obliged to?)
  • Counterparty fails to pay amounts falling due at maturity on a Specified Transaction, so you can’t “accelerate” as such on that Specified Transaction, as it has matured, but you are still out of pocket and of a mind to press a big red button — though, again, curiously, only on this Specified Transaction and not the other outstanding transactions under the same master agreement, even though you could;
  • Counterparty fails to deliver assets due under a Specified Transaction, and as a result you accelerate the Specified Transaction (1992 ISDA) or all Specified Transactions under the affected master agreement (2002 ISDA — the 2002 version being designed to carve out things like mini close-out under a 2010 GMSLA as these are not credit-related;
  • Counterparty presents you an extended middle finger generally with regard to any obligation under any Specified Transaction, whether you accelerate it or not. Here if your counterparty is playing craziest dude in the room, it has committed a repudiatory breach thereby losing what moral high-ground it might otherwise stand on to expect you to follow form and protocol before closing it out.
Premium content

See also

References

  1. ↑ I know these sound like borrowing transactions, but they’re fully collateralised, and in fact aren’t.
  2. ↑ And — sigh — their Credit Support Providers and Specified Entities.
  3. ↑ Or — sigh — its Credit Support Provider or Specified Entity
  4. ↑ This is typically wide, though it excludes borrowed money — but check the Agreement!
Retrieved from "https://jollycontrarian.com/index.php?title=Default_Under_Specified_Transaction_-_ISDA_Provision&oldid=88835"