Template:Csa Conditions Precedent summ: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=== | ====Paragraph 4(a) ==== | ||
===='' | 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 | |||
Well, they are — if your | 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}}===== | ====={{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 {{ | 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. | The latter argument, we fancy, will prevail. | ||
Latest revision as of 10:20, 9 May 2024
Paragraph 4(a)
With all this talk of conditions precedent, is this another flawed asset clause? Aren’t the conditions precedent dealt with in Section 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 1995 CSA and the 2016 VM CSA), but the security interest CSAs (the New York law 1994 NY CSA and 2016 NY VM CSA and the English law 2018 IM CSD) 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 conditions precedent. Given that such an Early Termination Date would affect — that is, terminate — all Transactions (keying off an Event of Default but not a 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 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 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 ISDA Master Agreement itself, this remains a theoretical possibility, however absurd, and this is, we thing, the contingency for which ISDA’s crack drafting squad™ is providing.
Interestingly the 2018 English law IM CSD words this provision slightly differently, pulling in any Early Termination Date that has resulted in the termination of all Covered Transactions (IM). This, at least, could attach to some but not all outstanding Transactions.
2018 IM CSD
In the 2018 IM CSD there is a curious reference to “provisions requiring the return of zero-Valued Posted Credit Support (IM)”. It is not entirely clear why ineligible Credit Support (that hence has a Value of zero), since it doesn’t count numerically into the Value of the 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.