Template:Csa Credit Support Obligations summ: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
← Older edit
VisualWikitext
No edit summary
No edit summary
Tag: Manual revert
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
===Timing of transfers under a CSA===
The overall vibe of a Credit Support Annex is ''self-help''.  
This is how the timing works for CSA transfers. Remember the {{{{{1}}}|Valuation Agent}} is simply the person making the demand. Terminology check: to make this easy we refer to both {{{{{1}}}|Delivery Amount}}s ''and'' {{{{{1}}}|Return Amount}}s as “'''{{{{{1}}}|Transfer Amount}}s'''”. The date on which someone actually demands a Transfer Amount we call a “'''{{{{{1}}}|Demand Date}}'''”.


'''Valuation of {{{{{1}}}|Exposure}} and {{{{{1}}}|Credit Support Balance}}''': Firstly, you must value what you are going to call, which will be the Transfer Amount under para {{{{{1}}}|2(a)}} or {{{{{1}}}|2(b)}}. This is roughly {{{{{1}}}|Credit Support Balance}} - {{{{{1}}}|Exposure}} (or ''vice versa'').  
It is presumed on any day there will be a portfolio of Transactions outstanding under the ISDA (not counting the CSA itself, which under the English law construct, is also a “Transaction”, though it is not under a NY law construct), and these Transactions will each create a market exposure, and when those market exposures are summed, will create an overall “{{{{{1}}}|Exposure}}” owed by one party or the other.


Per para {{{{{1}}}|2(a)}} the {{{{{1}}}|Transferor}} will transfer {{{{{1}}}|Eligible Credit Support}} having a {{{{{1}}}|Value}} equal to the {{{{{1}}}|Transfer Amount}} ''as of the date of transfer''.  Under the {{{{{1}}}|Calculations}} provision all calculations happen at the relevant {{{{{1}}}|Valuation Time}}. Fluctuations in value after that time won’t invalidate the {{{{{1}}}|Transfer Amount}}, but they may mean a party can immediately call for more {{{{{1}}}|Credit Support}} (that is, have ''another'' {{{{{1}}}|Demand Date}}). The {{{{{1}}}|Valuation Time}} in turn keys off the {{{{{1}}}|Valuation Date}}.<ref>Under the {{csa}} you may specify either [[close of business]] on the {{csaprov|Valuation Date}} or the {{csaprov|Local Business Day}} immediately ''before'' it. Under the {{vmcsa}} you have flexibility to determine the {{vmcsaprov|Valuation Time}} as at the point you your book each day.</ref>
The party to whom the netted amount would be paid were the {{isdama}} closed out on that day can — subject to a few conditions — call for {{{{{1}}}|Eligible Credit Support}} from the party who would be due to pay it.


'''{{{{{1}}}|Demand Date}}''':  On any date that is (or promptly follows) a {{{{{1}}}|Valuation Date}}<ref>It need not be a Local Business Day.</ref> in which the {{{{{1}}}|Exposure}} has moved in its favour, one party may demand a {{{{{1}}}|Delivery Amount}}<ref>Under para 2(a).</ref> or a {{{{{1}}}|Return Amount}}.<ref>Under para 2(b).</ref>
====Title transfer versus pledge====
English law CSAs are {{ttcsa}}s. {{{{{1}}}|Credit Support}} is delivered outright against a contingent obligation on the Transferee to return “equivalent” — meaning [[fungible]] — {{{{{1}}}|Credit Support}}. As such, the {{{{{1}}}|Transferor}} has no legal or beneficial interest in {{{{{1}}}|Credit Support}} it has posted: it has only a debt claim against the {{{{{1}}}|Transferee}} for its return (which would be netted off against the {{{{{1}}}|Transferee}}’s debt claim against it under the {{isdama}}). This is why an English law CSA is treated as a {{{{{1}}}|Transaction}}: it is, in every sense, identical to a physically settled asset swap.


'''{{{{{1}}}|Transfer Date}}''': Under para {{{{{1}}}|3(a)}} ({{{{{1}}}|Transfers}}) if the {{{{{1}}}|Demand Date}} is a {{{{{1}}}|Local Business Day}} and demand is received ''before'' the {{{{{1}}}|Notification Time}}, the transfer must be made not later than [[close of business]] on the related [[Regular Settlement Day - VM CSA Provision|''Regular'' Settlement Day]].<ref>The “{{csaprov|Settlement Day}}” under the {{csa}} is slightly different.</ref> If received ''after'' the {{{{{1}}}|Notification Time}} (or at any time on a non-{{{{{1}}}|Local Business Day}}), the transfer must be made by close of business on the {{vmcsaprov|Regular Settlement Day}} relating to the day<ref>Note: ''ordinary'' day, ''not'' Local Business Day</ref> ''after'' the Demand Date. <br>
New York law CSAs are {{sicsa}}s: {{{{{1}}}|Credit Support}} is posted by way of security, and the {{{{{1}}}|Transferee}} takes only legal title, holding beneficial interest in the {{{{{1}}}|Credit Support}} for the Transferor. This markedly changes the netting analysis. ''But'' — unless the option has been disapplied in the elections paragraph, the holder of pledged Credit Support is entitled to “rehypothecate” it — transfer it outright to a third party, against an obligation to return a fungible asset — and while U.S. attorneys may beg to differ this, to a jaundiced English lawyer, makes a NY law CSA materially identical to an English law one. Both are effectively, title transfer arrangements.


'''{{csaprov|Settlement Day}}''': Here is where things differ materially between the {{csa}} and the {{vmcsa}}.<br>
English law Credit Support Deeds, such as the {{imcsd}}, are {{sicsa}}s. They do not generally allow [[reuse]]: for the Ancient version, it wouldn’t make any sense to take under a pledge/custody model, mark yourself in scope for CASS and all that carry on, and then deliver away the collateral: if you wanted to do that it would be better tpo just use a normal {{ttcsa}}. As a result the 1995 ISDA Credit Support Deed is seldom spoken of, an even more seldom seen. The {{imcsd}}, being a regulatory IM document, specifically forbids reuse of collateral. The whole point of reg IM is that someone sensible is meant to sit on it at all times.  
'''{{csa}}''': The {{csaprov|Settlement Day}} for ''any'' day (whether or not it is a {{{{{1}}}|Local Business Day}}) is:
*'''Cash''': for cash, the next {{{{{1}}}|Local Business Day}} and,  
*'''Securities''': for securities, the {{{{{1}}}|Local Business Day}} after the date on which a trade in the relevant security, if effected on the day in question, would have been settled in accordance with customary practice.


'''{{vmcsa}}''': In the new world we have the new concept of the [[Regular Settlement Day - VM CSA Provision|''Regular'' Settlement Day]], and this is the same {{vmcsaprov|Local Business Day}} as the Demand Date. The run-off text at the end of Paragraph {{vmcsaprov|3(a)}} gives you a little more flex: if the demand came after the {{vmcsaprov|Notification Time}}, then you must make the transfer by close on the {{vmcsaprov|Regular Settlement Day}} for the next day.<ref>Just how the business days interact under the ISDA and CSA is about as complicated as string theory, by the way. For a cheat’s guide, see [[How business days work under the CSA]]. You’re welcome!</ref>
====Credit Support Balance v Posted Credit Support====
Quick terminology check: “{{{{{1}}}|Eligible Credit Support}}”, once delivered to the person demanding it under a {{ttcsa}} is called the “Credit Support Balance” and under a {{sicsa}} is called “Posted Credit Support”. This seems annoying, and is, but {{icds}} has its reasons, as ever. The difference reflects their differing ontological statuses. True.  


Collateral posted under a {{ttcsa}} goes outright, leaving the deliveror only a simple debt claim for an equivalent asset. There is no sense of custody; no bailment; no lingering interest in what has been sent away. It is not like it has been posted into a cubby-hole to be kept safe and sound and later returned. Hence, it is just a “Credit Support Balance”.


===Questions===
Collateral posted under a {{sicsa}} ''is'' “posted” on that basis; there ''is'' a (conditioned) expectation of getting back the same thing you sent. This expectation is annihilated by the act of [[rehypothecation]], but still, in theory, it is for an instant there. Hence what you have is “Posted Credit Support”.  
'''{{{{{1}}}|Demand Date}} not a {{{{{1}}}|Local Business Day}}''': What if the Demand Date is not a {{{{{1}}}|Local Business Day}}? E.g., what if it is received after the {{{{{1}}}|Notification Time}} on a Friday, meaning the {{csaprov|Settlement Day}} takes place on the date on which a trade, effected on a Saturday, would have been settled in accordance with customary practice?
*'''Securities''': For securities this is ok: a trade effected on a non-business day would be deemed to be effected on the next following Local Business Day anyway, so it would pick this up.
*'''Cash''': For cash, not so clear.
'''What happens if the transferred credit support changes in value on the {{{{{1}}}|Settlement Day}}'''?<br>


'''What happens to {{{{{1}}}|Exposure}}s if the {{{{{1}}}|Settlement Day}} is a long time after the Demand Date?'''<ref>As it may well be, under a {{csa}}, if the collateral is corporate [[bond]]s held in a [[clearing system]]</ref> Is the demand, if answered with irrevocable instructions to deliver, treated as having been met, or does the {{{{{1}}}|Exposure}} stay outstanding until the collateral comes in? The answer (counterintuitive, given that the {{{{{1}}}|Transferee}} remains subject to the [[credit exposure]] during this time) is YES, thanks to the definitions of {{{{{1}}}|Delivery Amount}} and {{{{{1}}}|Return Amount}}, both of which include the words:
However compelling the intellectual grounds for the distinction, in practice it is annoying, especially if you happen to be speaking generally about ISDA Credit Support Annexes of either kind, as the JC is.  For ease of deference to his usual slapdash way of thinking about things JC will refer to ''either'' as simply “{{{{{1}}}|Credit Support}}”. that can probably apply loosely to Eligible Credit Support, which is te universe of collateral which, by rights, ''could'' be posted under the CSA even if it has not necessarily been yet.
{{quote|“...the {{{{{1}}}|Value}} as of that {{{{{1}}}|Valuation Date}} of the {{{{{1}}}|Transferor}}’s {{{{{1}}}|Credit Support Balance}} (adjusted to include any prior {{{{{1}}}|Delivery Amount}} and to exclude any prior {{{{{1}}}|Return Amount}}, the transfer of which, in either case, has not yet been completed and for which the relevant {{{{{1}}}|Settlement Day}} falls on or after such {{{{{1}}}|Valuation Date}}).”}}
====The Basic Idea====
The basic idea is that {{{{{1}}}|Credit Support}} creates an offsetting value under the CSA which, when set off against the net market exposure under the {{isdama}} proper, would equal zero, or at any rate an acceptably low number: pre-agreed {{{{{1}}}|Threshold}}s, {{{{{1}}}|Independent Amount}}s, {{{{{1}}}|Minimum Transfer Amount}}s may intervene to make that number something other than zero, and {{{{{1}}}|Exposure}} and the value of extant {{{{{1}}}|Credit Support}} may subsequently change, but it will be in any case ''near'' zero.


'''What if I have to pay out a {{isdaprov|Transaction}} termination amount which the counterparty is already holding all or some of by way of [[variation margin]]?''' Since it will owe me that back, we can just offset those and call it quits, right? ''Wrong''. See our [[Transaction terminations and VM|separate article]] on that issue.
Each party can run this calculation on, essentially, any Local Business Day. The person holding {{{{{1}}}|Credit Support}} must factor its value into its demand.
 
Where a party is seeking ''new'' {{{{{1}}}|Credit Support}} to cover its own outright Exposure, that is a “{{{{{1}}}|Delivery Amount}}”. Where it is seeking to “call back” {{{{{1}}}|Credit Support}} it has already delivered, that is called a “{{{{{1}}}|Return Amount}}”.
====The difference between Delivering and Returning====
There is not much of a difference, but there is some: with a {{{{{1}}}|Return Amount}}, the {{{{{1}}}|Transferee}} gets to choose which bit of {{{{{1}}}|Credit Support}} the {{{{{1}}}|Transferor}} sends back, out of what the {{{{{1}}}|Transferee}} originally delivered. When the {{{{{1}}}|Transferee}} is calling for a {{{{{1}}}|Delivery Amount}} the {{{{{1}}}|Transferor}} gets to choose from the agreed {{{{{1}}}|Eligible Credit Support}} table in the elections paragraph.
 
The self-help element is this: you don’t ''have'' to call for {{{{{1}}}|Credit Support}}. You may be ''entitled'' to, but it is up to you to run the calculations and make the demand. If you don’t, the other party is not obliged to send you anything.
 
Each party therefore also “marks its own homework”. Should the parties not agree on their respective valuations, there is a dispute resolution process set out in Paragraph {{{{{1}}}|4}}.
 
====Paragraph 3(c) of the 2018 IM Credit Support Deed on margin mechanics ====
There is quite a lot in Paragraph {{imcsdprov|3}} of the {{imcsd}}, and rather than setting it all here, we have created a whole page for Paragraph {{imcsdprov|3(c)}}, seeing as it has no equivalent in the variation margin CSAs.

Latest revision as of 16:52, 8 July 2024

The overall vibe of a Credit Support Annex is self-help.

It is presumed on any day there will be a portfolio of Transactions outstanding under the ISDA (not counting the CSA itself, which under the English law construct, is also a “Transaction”, though it is not under a NY law construct), and these Transactions will each create a market exposure, and when those market exposures are summed, will create an overall “{{{{{1}}}|Exposure}}” owed by one party or the other.

The party to whom the netted amount would be paid were the ISDA Master Agreement closed out on that day can — subject to a few conditions — call for {{{{{1}}}|Eligible Credit Support}} from the party who would be due to pay it.

Title transfer versus pledge

English law CSAs are title transfer CSAs. {{{{{1}}}|Credit Support}} is delivered outright against a contingent obligation on the Transferee to return “equivalent” — meaning fungible — {{{{{1}}}|Credit Support}}. As such, the {{{{{1}}}|Transferor}} has no legal or beneficial interest in {{{{{1}}}|Credit Support}} it has posted: it has only a debt claim against the {{{{{1}}}|Transferee}} for its return (which would be netted off against the {{{{{1}}}|Transferee}}’s debt claim against it under the ISDA Master Agreement). This is why an English law CSA is treated as a {{{{{1}}}|Transaction}}: it is, in every sense, identical to a physically settled asset swap.

New York law CSAs are security interest CSAs: {{{{{1}}}|Credit Support}} is posted by way of security, and the {{{{{1}}}|Transferee}} takes only legal title, holding beneficial interest in the {{{{{1}}}|Credit Support}} for the Transferor. This markedly changes the netting analysis. But — unless the option has been disapplied in the elections paragraph, the holder of pledged Credit Support is entitled to “rehypothecate” it — transfer it outright to a third party, against an obligation to return a fungible asset — and while U.S. attorneys may beg to differ this, to a jaundiced English lawyer, makes a NY law CSA materially identical to an English law one. Both are effectively, title transfer arrangements.

English law Credit Support Deeds, such as the 2018 English law IM CSD, are security interest CSAs. They do not generally allow reuse: for the Ancient version, it wouldn’t make any sense to take under a pledge/custody model, mark yourself in scope for CASS and all that carry on, and then deliver away the collateral: if you wanted to do that it would be better tpo just use a normal title transfer CSA. As a result the 1995 ISDA Credit Support Deed is seldom spoken of, an even more seldom seen. The 2018 English law IM CSD, being a regulatory IM document, specifically forbids reuse of collateral. The whole point of reg IM is that someone sensible is meant to sit on it at all times.

Credit Support Balance v Posted Credit Support

Quick terminology check: “{{{{{1}}}|Eligible Credit Support}}”, once delivered to the person demanding it under a title transfer CSA is called the “Credit Support Balance” and under a security interest CSA is called “Posted Credit Support”. This seems annoying, and is, but ISDA’s crack drafting squad™ has its reasons, as ever. The difference reflects their differing ontological statuses. True.

Collateral posted under a title transfer CSA goes outright, leaving the deliveror only a simple debt claim for an equivalent asset. There is no sense of custody; no bailment; no lingering interest in what has been sent away. It is not like it has been posted into a cubby-hole to be kept safe and sound and later returned. Hence, it is just a “Credit Support Balance”.

Collateral posted under a security interest CSA is “posted” on that basis; there is a (conditioned) expectation of getting back the same thing you sent. This expectation is annihilated by the act of rehypothecation, but still, in theory, it is for an instant there. Hence what you have is “Posted Credit Support”.

However compelling the intellectual grounds for the distinction, in practice it is annoying, especially if you happen to be speaking generally about ISDA Credit Support Annexes of either kind, as the JC is. For ease of deference to his usual slapdash way of thinking about things JC will refer to either as simply “{{{{{1}}}|Credit Support}}”. that can probably apply loosely to Eligible Credit Support, which is te universe of collateral which, by rights, could be posted under the CSA even if it has not necessarily been yet.

The Basic Idea

The basic idea is that {{{{{1}}}|Credit Support}} creates an offsetting value under the CSA which, when set off against the net market exposure under the ISDA Master Agreement proper, would equal zero, or at any rate an acceptably low number: pre-agreed {{{{{1}}}|Threshold}}s, {{{{{1}}}|Independent Amount}}s, {{{{{1}}}|Minimum Transfer Amount}}s may intervene to make that number something other than zero, and {{{{{1}}}|Exposure}} and the value of extant {{{{{1}}}|Credit Support}} may subsequently change, but it will be in any case near zero.

Each party can run this calculation on, essentially, any Local Business Day. The person holding {{{{{1}}}|Credit Support}} must factor its value into its demand.

Where a party is seeking new {{{{{1}}}|Credit Support}} to cover its own outright Exposure, that is a “{{{{{1}}}|Delivery Amount}}”. Where it is seeking to “call back” {{{{{1}}}|Credit Support}} it has already delivered, that is called a “{{{{{1}}}|Return Amount}}”.

The difference between Delivering and Returning

There is not much of a difference, but there is some: with a {{{{{1}}}|Return Amount}}, the {{{{{1}}}|Transferee}} gets to choose which bit of {{{{{1}}}|Credit Support}} the {{{{{1}}}|Transferor}} sends back, out of what the {{{{{1}}}|Transferee}} originally delivered. When the {{{{{1}}}|Transferee}} is calling for a {{{{{1}}}|Delivery Amount}} the {{{{{1}}}|Transferor}} gets to choose from the agreed {{{{{1}}}|Eligible Credit Support}} table in the elections paragraph.

The self-help element is this: you don’t have to call for {{{{{1}}}|Credit Support}}. You may be entitled to, but it is up to you to run the calculations and make the demand. If you don’t, the other party is not obliged to send you anything.

Each party therefore also “marks its own homework”. Should the parties not agree on their respective valuations, there is a dispute resolution process set out in Paragraph {{{{{1}}}|4}}.

Paragraph 3(c) of the 2018 IM Credit Support Deed on margin mechanics

There is quite a lot in Paragraph 3 of the 2018 English law IM CSD, and rather than setting it all here, we have created a whole page for Paragraph 3(c), seeing as it has no equivalent in the variation margin CSAs.

Retrieved from "https://jollycontrarian.com/index.php?title=Template:Csa_Credit_Support_Obligations_summ&oldid=87358"