Netting - 1992 ISDA Provision

From The Jolly Contrarian
Jump to navigation Jump to search

1992 ISDA Master Agreement
A Jolly Contrarian owner’s manual

Section 2(c) in a Nutshell
Use at your own risk, campers!

2(c) Netting. If on any date amounts would otherwise be payable by each party to the other

(i) in the same currency; and
(ii) under the same Transaction,

then those obligations will be satisfied and replaced by an obligation on the party owing the larger amount to pay the difference. The parties may net payments across multiple specified Transactions by saying clause 2(c)(ii) will therefore not apply. This election may apply to different groups of Transactions, will apply separately to each pairing of specified Offices and will take effect as agreed between the parties.
view template

Section 2(c) in full

2(c) Netting. If on any date amounts would otherwise be payable:—

(i) in the same currency; and
(ii) in respect of the same Transaction,

by each party to the other, then, on such date, each party’s obligation to make payment of any such amount will be automatically satisfied and discharged and, if the aggregate amount that would otherwise have been payable by one party exceeds the aggregate amount that would otherwise have been payable by the other party, replaced by an obligation upon the party by whom the larger aggregate amount would have been payable to pay to the other party the excess of the larger aggregate amount over the smaller aggregate amount. The parties may elect in respect of two or more Transactions that a net amount will be determined in respect of all amounts payable on the same date in the same currency in respect of such Transactions, regardless of whether such amounts are payable in respect of the same Transaction. The election may be made in the Schedule or a Confirmation by specifying that subparagraph (ii) above will not apply to the Transactions identified as being subject to the election, together with the starting date (in which case subparagraph 2(c)(ii) above will not, or will cease to, apply to such Transactions from such date). This election may be made separately for different groups of Transactions and will apply separately to each pairing of Offices through which the parties make and receive payments or deliveries.
view template

Related agreements and comparisons

Related Agreements
Click here for the text of Section 2(c) in the 2002 ISDA
Comparisons
Click to compare this section in the 1992 ISDA and 2002 ISDA.

Resources and navigation

Resources Wikitext | Nutshell wikitext | 2002 ISDA wikitext | 2002 vs 1992 Showdown | 2006 ISDA Definitions | 2008 ISDA
Navigation Preamble | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14
Events of Default: 5(a)(i) Failure to Pay or Deliver5(a)(ii) Breach of Agreement5(a)(iii) Credit Support Default5(a)(iv) Misrepresentation5(a)(v) Default Under Specified Transaction5(a)(vi) Cross Default5(a)(vii) Bankruptcy5(a)(viii) Merger Without Assumption
Termination Events: 5(b)(i) Illegality5(b)(ii) Tax Event5(b)(iii) Tax Event Upon Merger5(b)(iv) Credit Event Upon Merger5(b)(v) Additional Termination Event

Index — Click ᐅ to expand:

Get in touch
Comments? Questions? Suggestions? Requests? Sign up for our newsletter? Questions? We’d love to hear from you.
BREAKING: Get the new weekly newsletter here Old editions here

Content and comparisons

Settlement netting, not close-out netting

Section 2(c) is about “settlement” or “payment” netting — that is, the operational settlement of offsetting payments due on any day under the normal operation of the Agreement — and not the more drastic close-out netting, which is the Early Termination of all Transactions under Section 6.

If you want close-out netting, see here:

Template

Summary

I mean, what is the point?

Our chief contrarian wonders what on earth the point of this section is, since settlement netting is a factual operational process for performing existing legal obligations, rather than any kind of variation of the parties’ rights and obligations. If you owe me ten pounds and I owe you ten pounds, and we agree to both keep our tenners, what cause of action arises? What loss is there? We have settled our existing obligations in different way.

To be sure, if I pay you your tenner and you don’t pay me mine, that’s a different story — but then there is no settlement netting at all. The only time one would wish to enforce settlement netting it must, ipso facto, have actually happened, so what do you think you’re going to court to enforce?

So, friends, this rather convoluted passage in that mighty industry standard is, as G. K. Chesterton once said - merely piss and wind.
Template

General discussion

Multiple Transaction Payment Netting

Multiple Transaction Payment Netting” is a defined term introduced in the 2002 ISDA in place of the more clunky 1992 ISDA language set out in Section 2(c).

In the 1992 ISDA, to specify that netting across transactions would apply, you must disapply Section 2(c)(ii). Counterintuitive, but true (because otherwise netting only applies in respect of the same Transaction).

That is partly why, in the 2002 ISDA they introduced the more intuitive Multiple Transaction Payment Netting concept. So now you can say “Multiple Transaction Payment Netting does (or does not) apply”.

Of course, the one person who is going to have no clue — or, for that matter, care — about how transaction netting works at an operational level is negotiator expected to thrash this out in the document.

Now, seeing as (per above) payment netting is an operational fact not a legal right as such, and it doesn’t need to be in the contract, and your negotiator will care not one row of buttons whether or not Multiple Transaction Payment Netting, or its 1992 predecessor, applies or not, you might think it wise to put something diffident like “The parties will agree to any Multiple Transaction Payment Netting arrangements separately as an operational matter.”

I know, I know: I’m a total Mr. Buzzkill. But look, it’s for the good of your own long-term mental health.

Relevance of Section 6 to the peacetime operation of the Credit Support Annex

The calculation of {{{{{1}}}|Exposure}} under the CSA is modelled on the Section 6(e)(ii) termination methodology following a Termination Event where there is one Affected Party, which in turn tracks the Section 6(e)(i) methodology following an Event of Default, only taking mid-market valuations and not those on the Non-Defaulting Party’s side.

This means you calculate the {{{{{1}}}|Exposure}} as:

(a) the Close-out Amounts for each Terminated Transaction plus
(b) Unpaid Amounts due to the Non-defaulting Party; minus
(c) Unpaid Amounts due to the Defaulting Party.

There aren’t really likely, in peacetime, to be Unpaid Amounts loafing about — an amount that you are due to pay today or tomorrow wouldn’t, yet, qualify as “unpaid”, but would be factored into the Close-out Amount calculation.

There is a little bit of a dissonance here, since “{{{{{1}}}|Exposure}}” is a snapshot calculation that treats all future cashflows, whether due in a day, a month or a year from today, the same way: it discounts them back to today, adds them up and sets them off. Your {{{{{1}}}|Delivery Amount}} or {{{{{1}}}|Return Amount}}, as the case may be, is just the difference between that Exposure and whatever the existing {{{{{1}}}|Credit Support Balance}} is. The future is the future: unknowable, unpredictable, but discountable, whether it happens in a day or a thousand years.

All the same, this can seem kind of weird when your CSA you have to pay him an amount today when he owes you an even bigger amount tomorrow. It’s like, “hang on: why am I paying you margin when, tomorrow, you are going to be in the hole to me? Like, by double, if I pay you this margin and you fail to me tomorrow.”

The thing which, I think, causes all the confusion is the dates and amounts of payments under normal Transactions are deterministic, anticipatable, and specified in the Confirmation, whereas whether one is required under a CSA on any day, and how much it will be, depend on things you only usually find out about at the last minute. CSA payments are due “a regular settlement cycle after they are called” — loosey goosey, right? — (or even same day if you are under a VMV CSA and you are on the ball with your calls) whereas normal swap payments are due (say) “on the 15th of March”

So, a scenario to illustrate:

  • Day 1: Party A has an {{{{{1}}}|Exposure}} — is out of the money — to the tune of 100. Its prevailing {{{{{1}}}|Credit Support Balance}} is 90, so (let’s say, for fun, after the {{{{{1}}}|Notification Time}} on the {{{{{1}}}|Demand Date}}) Party B has called it for a {{{{{1}}}|Delivery Amount}} of a further 10, which it must pay, but not until tomorrow.
  • Day 2: Meanwhile, Party A has a Transaction payment of 10 that falls due to Party B, also tomorrow. The arrival of this payment will change Party A’s Exposure to Party B so it is 90. Assuming Party A also pays the Delivery Amount, by knock-off time tomorrow it will have posted a {{{{{1}}}|Credit Support Balance}} of 100, and its Exposure to Party B will only be 90. This means it will be entitled to call Party B for a {{{{{1}}}|Return Amount}} of 10.

This seems rather a waste of operational effort, and will also take years off your credit officer’s life and may even cause his hair to catch fire. Can Party A just not pay the further Delivery Acount in anticipation of what will happen tomorrow?

Fun times in the world of collateral operations.

Transaction flows and collateral flows

In a fully margined ISDA Master Agreement, all other things being equal, the termination of a Transaction will lead to two equal and opposite effects:

The strict sequence of these payments ought to be that the Transaction termination payment goes first, and the collateral return follows, since it can only really be calculated and called once the termination payment has been made.

I know what you’re thinking. Hang on! that means the termination payer pays knowing this will increase its Exposure for the couple of days it will take for that collateral return to find its way back. That’s stupid!

What with the regulators’ obsession minimise systemic counterparty credit risk, wouldn’t it be better to apply some kind of settlement netting in anticipation, to keep the credit exposure down?

Now, dear reader, have you learned nothing? It might be better, but “better” is not how ISDA documentation rolls. The theory of the ISDA and CSA settlement flows puts the Transaction payment egg before the variation margin chicken so, at the moment, Transaction flows and collateral flows tend to be handled by different operations teams, and their systems don’t talk. Currently, the payer of a terminating transaction has its heart in its mouth for a day or so.

Industry efforts to date have been targeting at shortening the period between the Exposure calculation and the final payment of the collateral transfer.

Template

See also

Template

References