Template:Isda 5(a)(v) summ
{{{{{1}}}|Default Under Specified Transaction}} — colloquially, “{{{{{1}}}|DUST}}” — is often confused with {{{{{1}}}|Cross Default}}. In fact, they’re meant to be mutually exclusive. That won’t stop folks conflating them, though. Look, we all do it.
{{{{{1}}}|DUST}} is like {{{{{1}}}|Cross Default}}, but where {{{{{1}}}|Cross Default}} references indebtedness owed to third parties, {{{{{1}}}|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 {{{{{1}}}|Event of Default}} under a swap agreement (or other “{{{{{1}}}|Specified Transaction}}”[4] with you, this will be an {{{{{1}}}|Event of Default}} under the ISDA Master Agreement.
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 begged-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, eslecially in these modern times where, thanks to complulsory daily zero-threshold 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 {{{{{1}}}|5(a)(v)}}.
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 {{{{{1}}}|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 {{{{{1}}}|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 {{{{{1}}}|Specified Transaction}}, so you can’t “accelerate” as such on that {{{{{1}}}|Specified Transaction}}, as it has matured, but you are still out of pocket and of a mind to press a big red button;
- Counterparty fails to deliver assets due under a {{{{{1}}}|Specified Transaction}}, and as a result you accelerate all {{{{{1}}}|Specified Transaction}}s under the affected master agreement (ie not just that transaction) — this is 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.
- ↑ I know these sound like borrowing transactions, but they’re fully collateralised, and in fact aren’t.
- ↑ And — sigh — their Credit Support Providers and Specified Entities.
- ↑ Or — sigh — its Credit Support Provider or Specified Entity
- ↑ This is typically wide, though it excludes borrowed money — but check the Agreement!