|
|
Line 1: |
Line 1: |
| {{isdaanat|Credit Support Document }} | | {{manual|MI|2002|Credit Support Document|Section|Credit Support Document|medium}} |
| Being the document by which {{isdaprov|Credit Support}} is provided by a {{isdaprov|Credit Support Provider}}. | | Being the document by which {{isdaprov|Credit Support}} is provided by a {{isdaprov|Credit Support Provider}}. |
| ===The {{csa}} is ''not'' a Credit Support Document...===
| | {{credit support annex as a credit support document}} |
| Note that a {{tag|CSA}}<ref>and its VM update, the {{vmcsa}}.</ref> is '''not''' a {{isdaprov|Credit Support Document}}, and you should not list it as one in {{isdaprov|Part 4}} of the {{isdaprov|Schedule}}, however satisfying it might be to do so. I mean it sounds like one, right? But no: the counterparty cannot be its own {{isdaprov|Credit Support Provider}}. The {{csa}} is, rather, a {{isdaprov|Transaction}} under the {{isdama}}. This is rather important to the whole issue of [[close-out netting]]. Deep [[ISDA lore]].
| |
| | |
| ===... But the {{nycsa}} ''is'' a {{isdaprov|Credit Support Document}}===
| |
| Because it is a {{sfca}} arrangement and not a {{ttca}}, transfer of credit support under a {{nycsa}}<ref>and its VM update, the {{nyvmcsa}}.</ref> does not change the net liabilities between the parties, the {{nycsa}} (and its regulatory VM successor, the {{nyvmcsa}} is a {{isdaprov|Credit Support Document}} and not a transaction under the {{isdama}}. Fun, huh?
| |
|
| |
|
| ===[[Guarantees]] under the {{isdama}}: why {{isdaprov|Transaction}}-specific {{isdaprov|guarantee}}s don't work=== | | ===[[Guarantees]] under the {{isdama}}: why {{isdaprov|Transaction}}-specific {{isdaprov|guarantee}}s don't work=== |
| {{isdaguaranteewarning}} | | {{isdaguaranteewarning}} |
| {{ref}} | | {{ref}} |