Default Under Specified Transaction - ISDA Provision

From The Jolly Contrarian
(Redirected from 5(a)(v) - ISDA Provision)
Jump to navigation Jump to search

2002 ISDA Master Agreement
A Jolly Contrarian owner’s manual™

Resources and navigation

Section 5(a)(v) in a Nutshell

Use at your own risk, campers!
5(a)(v) Default Under Specified Transaction. The party or one of its Credit Support Providers or Specified Entities:―
(1) defaults on any payment due under a Specified Transaction (or any related credit support arrangement) and as a result that Specified Transaction is validly accelerated;
(2) defaults on any final payment due under a Specified Transaction after one Local Business Day;
(3) defaults on any delivery due under a Specified Transaction (or any related credit support arrangement) and, all Transactions under the relevant Master Agreement are validly accelerated; or
(4) repudiates any Specified Transaction (or any related credit support arrangement);

Full text of Section 5(a)(v)

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);

Related agreements and comparisons

Click here for the text of Section 5(a)(v) in the 1992 ISDA
Click to compare this section in the 1992 ISDA and 2002 ISDA.

Comments? Questions? Suggestions? Requests? Insults? We’d love to 📧 hear from you.
Sign up for our newsletter.

Content and comparisons

DUST has been expanded in five significant ways by the 2002 ISDA:

  • The phrase “or challenges the validity of” was added after “disaffirms, disclaims, repudiates or rejects” to reduce ambiguity as to whether a party’s action constitutes a repudiation; and
  • to stiffen the criteria for something to count as a repudiation so as to require written evidence from the repudiating party of its extended middle finger. This is really an articulation of common sense, for it would be a brave risk officer indeed who closed out an ISDA Master Agreement based on an oral communication, or the proverbial extended middle finger, for which she could not subsequently produce in 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.

The mini closeout point, as we discuss in the commentary below, is technically correct but should have led to a simplification of the DUST provision, rather than a convolution of it. I know what you’re thinking, and you’re right: like that was ever going to happen.



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.

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.

General discussion

Acceleration, not Default

DUST is triggered by an acceleration following an event of default under the Specified Transaction, not upon the default itself[5]. 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[6], 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[7] 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”.)

For details freaks

Payment acceleration versus delivery acceleration — mini close-out

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 a delivery default under 5(a)(v)(3), is only triggered if the whole Master Agreement is closed out.

Why would that be? Oh! Yes, Stock loan ninja at the back, with your hand up!

Stock loan ninja (for it is he): Sir! Sir! Please sir, is this to stop the mini-closeout of a single Loan under a 2010 GMSLA?
The JC (beaming inscrutably): Yeeeees — Go on — ?
SLN: Sir, please sir, settlement failures under a stock loan are often a function of market illiquidity (the asset to be delivered isn’t available) and aren’t necessarily indicative of credit deterioration, sir, so should not necessarily trigger a DUST under the ISDA. But this situation would never apply to a simple cash payment. On the other hand, if the whole 2010 GMSLA is closed out as a result of a delivery fail, you clearly are in a credit-stress situation.
JC: Excellent!

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[8] (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.

See also



  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!
  5. Except where that happens on maturity: see drafting point below.
  6. 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.)
  7. And, to be candid, rightful.
  8. Concord Trust v The Law Debenture Trust Corporation plc