Template:Isda 1 summ
Section 1 is a gentle introduction indeed to the dappled world of the ISDA Master Agreement: much coming from the “goes without saying, but let’s say it anyway” dept of legal wordwrightery — a large department indeed, in the annals of modern legal practice.
Section 1(a)
The large slew of definitions are set out in Section 14. the JC considers each in its own write elsewhere.
Section 1(b)
It wouldn’t be ISDA if there weren’t a hierarchy clause; all this really establishes is the obvious: the pre-printed ISDA Master Agreement itself sits at the bottom and is modified between the counterparties by its Schedule; once negotiated and stuck into the netting database, the Schedule basically sits there unregarded and is modified as needs be for each Transaction under the Confirmation. In point of fact the Confirmations don’t tend to modify anything in the Master and Schedule so much as build on them, but if there is a consistency — and with a document as pedantic and overwrought as the ISDA you just never know — then the most specific, recently edited document will be the one that prevails.
Section 1(c)
Section 1(c) starts getting a bit tastier in that it comprises the Single Agreement. This is deep ISDA lore, from which all the close-out netting that gives the ISDA Master Agreement its capital efficiency wings flows.
Okay, do not adjust the Single Agreement provision unless you are writing an ISDA Master Agreement for a repackaging vehicle issuing segregated, secured, limited recourse obligations. In that case you — and here I am supposing that “you” are the inhouse legal eagle at the arranging bank, or someone advising her — will have multiple ISDA Transactions nominally between the same two entities — your employer and the SPV — but economically being totally distinct, relating as they do to discrete ring-fenced “Series” issued by the SPV and you absolutely do not want these to form a single agreement with each other, or net, or do anything ostensibly desirable like that.
Each Transaction (or set of Transactions, if more than one Transaction}} attaches to a single Series) stands quite alone, should not be accelerated, cross-defaulted, DUSTed, closed out or heaven forbid netted, just because some other Transaction, relating to another series, has gone arriba.
Treat them as if each Series had its own distinct ISDA Master Agreement, completely isolated, air-gapped and insulated against misadventure occurring in other ISDA Master Agreements the SPV has entered with you relating to other Series.[1]
In point of fact, your best bet is a bit of “deemery”: the Transactions entered into for each new Series should be under a deemed separate ISDA Master Agreement, constituted specifically for the Series in question, on the standard terms set out in your repack programme. If you do this, then no amendment to the Single Agreement clause is necessary, since the way you have structured your ISDA, it is just a Single Agreement for the Series. Do not be surprised or alarmed if counterparts to the deal don’t buy this, or trust such deemery, and may wish to amend the Section 1(c) language as well. Try to resist this, but don’t die in a ditch about it.
Basically
In a nutshell — unless you are doing repackagings, and even then don’t get carried away — make sure you understand what Section 1 is there fore, but don’t mess with it.