82,891
edits
Default Under Specified Transaction - ISDA Provision: Difference between revisions
Default Under Specified Transaction - ISDA Provision (view source)
Revision as of 12:21, 9 March 2018
, 9 March 2018→Drafting oddities
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) |
||
| Line 8: | Line 8: | ||
{{tag|DUST}} is triggered by an ''acceleration following an'' event of default under the {{isdaprov|Specified Transaction}}, not upon default itself (except where that happens on maturity - see drafting point below). Since the {{isdaprov|Specified Transaction}} is between you and the other party to the {{isdama}}, 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 {{isdaprov|Cross Default}} provision, which imports all the {{isdaprov|Events of Default}} from all {{isdaprov|Specified Transaction}}s into the present one, even if the counterparty to the defaulted contract has itself waived its rights to exercise. | {{tag|DUST}} is triggered by an ''acceleration following an'' event of default under the {{isdaprov|Specified Transaction}}, not upon default itself (except where that happens on maturity - see drafting point below). Since the {{isdaprov|Specified Transaction}} is between you and the other party to the {{isdama}}, 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 {{isdaprov|Cross Default}} provision, which imports all the {{isdaprov|Events of Default}} from all {{isdaprov|Specified Transaction}}s into the present one, even if the counterparty to the defaulted contract has itself waived its rights to exercise. | ||
====Drafting oddities==== | ====Drafting oddities==== | ||
*'''Payment acceleration versus delivery acceleration''': 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 | *'''Payment acceleration versus delivery acceleration''': | ||
*Upon a payment default under {{isdaprov|5(a)(v)}}(1), only that particular transaction must be accelerated (it doesn't require full close out of the relevant [[Master agreement|Master Agreement]]. But a delivery default under {{isdaprov|5(a)(v)}}(3), is only triggered if ''the whole Master Agreement is closed out''. | |||
*Why would that be? This is to stop the [[mini-closeout]] of a single transaction under a {{gmsla}} — which is often a function of market illiquidity (the asset to be delivered isn't available) and isn’t necessarily indicative of credit deterioration — giving rise to a DUST under the ISDA. Clearly this situation would never apply to a simple cash payment. If the ''whole'' {{gmsla}} is closed out as a result of a delivery fail, you clearly are in a credit-stress situation. | |||
*'''Final payments''': The reason for the second limb of the definition is to catch final payments, which can't be accelerated, since they're already due. | *'''Final payments''': The reason for the second limb of the definition is to catch final payments, which can't be accelerated, since they're already due. | ||