Template:Csa Conditions Precedent summ: Difference between revisions

← Older edit

Template:Csa Conditions Precedent summ (view source)

Revision as of 10:20, 9 May 2024

1,975 bytes added , 9 May

no edit summary

Amwelladmin

Bureaucrats, Interface administrators, Administrators

82,892

edits

@@ Line 1: / Line 1: @@
-===Conditions precedent===
+====Paragraph 4(a) ====
-====''Another'' flawed asset clause?====
+With all this talk of conditions precedent, is this ''another'' flawed asset clause? Aren’t the [[Condition precedent|conditions precedent]] dealt with in Section {{isdaprov|2(a)(iii)}} of the ISDA?
-Aren’t the Conditions precedent dealt with in Section {{isdaprov|2(a)(iii)}} of the ISDA?
-Well, they are — if your credit support annex counts as a Transaction under the ISDA, which the ''[[title transfer]]'' CSAs do (eg, the English law {{1995csa}} and the {{2016csa}}), but the ''security interest'' CSAs (the New York law {{1994csa}} and {{2016nycsa}} and the English law {{2018imcsd}}) do not.
+Well, they are — if your [[Credit Support Annex]] counts as a {{isdaprov|Transaction}} under the ISDA, which the ''[[title transfer]]'' CSAs do (eg, the English law {{1995csa}} and the {{2016csa}}), but the ''security interest'' CSAs (the New York law {{1994csa}} and {{2016nycsa}} and the English law {{2018imcsd}}) do not.
+=====Paragraph 4(a)(ii)=====
+We are not sure what “for which any unsatisfied payment obligations (whether present, actual, future or contingent) exist” is driving at in Para {{{{{1}}}|4(a)(ii)}}: the [[Condition precedent|conditions precedent]]. Given that such an {{isdaprov|Early Termination Date}} would affect  — that is, ''terminate'' — all {{isdaprov|Transactions}} (keying off an {{isdaprov|Event of Default}} but not a {{isdaprov|Termination Event}}), if all of the Transaction Amounts have been settled, Q.E.D., there are no Transactions outstanding under the ISDA, so there can hardly be a Transfer requirement under any {{{{{1}}}|Credit Support Document}}.
+Oh, hold on: there is one case where this could happen: where a party has committed an Event of Default, had all its {{isdaprov|Transactions}} closed out and, before having settled them all and cleared the slate, it has resumed trading under the same ISDA and put some new {{isdaprov|Transactions}} on.
+Readers, if you are currently doing a double take, rubbing your eyes, and thinking, “''What?''” do not be alarmed: this is a perfectly understandable reaction. There is no practical chance that any counterparty would be dopey enough to resume trading with a swap counterparty it had just closed out ''at all'', let alone before the Defaulting Party had finally settled its account in full. Seeing as a full EOD close-out does ''not'' have the effect of formally terminating the {{isdama}} itself, this remains a theoretical possibility, however absurd, and this is, we thing, the contingency for which {{icds}} is providing.
+Interestingly the {{imcsd}} words this provision slightly differently, pulling in any Early Termination Date that has resulted in the termination of all {{imcsdprov|Covered Transactions (IM)}}. This, at least, could attach to some but not all outstanding {{isdaprov|Transaction}}s.
 ====={{2018imcsd}}=====
 In the {{2018imcsd}} there is a curious reference to “provisions requiring the return of zero-Valued Posted Credit Support (IM)”. It is not entirely clear why ineligible {{csaprov|Credit Support}} (that hence has a {{csaprov|Value}} of zero), since it doesn’t count numerically into the {{csaprov|Value}} of the {{imcsdprov|Posted Credit Support (IM)}}) should be covered, as on its own theory of the game the Secured Party assigns no value to this collateral and has no justification for holding onto it — but on the other hand, the argument is “well, you are going ''[[tetas arriba]]'' so frankly anything of yours that I hold I’m damn well keeping and selling for anything I can get for it.”
 The latter argument, we fancy, will prevail.