Credit Support Amount - CSA Provision
Credit Support Amount is the total amount one counterparty must have delivered to the other at any time: The combination of its net Exposure under the ISDA Master Agreement and the net Independent Amounts it must post.
No equivalent in the 2016 VM CSA
Careful observers will have noticed there isn't such a concept in the 2016 VM CSA. This is because the Credit Support Amount is no more than a given party’s Exposure — as already defined in the CSA — together with any pertinent Independent Amounts and similar amounts. Of course, under the 2016 VM CSA (being concerned only with Variation Margin) there are no Independent Amounts. So it vanishes, in a puff of logic and existential redundancy.
Calculating your {{{{{1}}}|Credit Support Amount}}
Superficially things are quite different between the 1995 CSA and the 2016 VM CSA, but this all boils down to the fact that the 2016 VM CSA is meant to be a zero-threshold, variation margin-only affair, so the concepts of Independent Amount and Threshold, both of which confuse the 1995 CSA, aren’t there to get in the way. Unless you go and put them in anyway, as we shall see...
1995 CSA
How the IA contributes to the Credit Support Amount — being the amount of credit support in total that one party must have given the other at any time[1] under the 1995 CSA can be mind-boggling.
It pans out for a Transferee like so:
- The Transferee’s Exposure: the net mark-to-market value the Transferor would owe the Transferee under all outstanding Transactions if they were closed out (not counting, of course, the 1995 CSA itself). Call this ETee.
- The Transferor’s Independent Amount: The total Independent Amount Transferor must give the Transferee we will call IATor. You can add this to the Transferee’s Exposure, but then you must remember to deduct ...
- The Transferee’s Independent Amount: Any Independent Amount the Transferee has to pay the Transferor. Call this IATee. [2]. Lastly don’t forget to take into account ...
- The Transferor’s Threshold: Any Threshold that applies to the Transferor being the Exposure it is allowed to represent before it has to post variation margin in the first place.
This leaves you with a formula for a Transferee’s Credit Support Amount as follows: Max[0, (ETee + IATor - IATee + Threshold)].
Let’s plug in some numbers. Say:
- The Transferee’s Exposure is 10,000,000
- The Transferor’s Independent Amount IATor is 2,000,000
- The Transferee’s Independent Amount IATee is 0
- The Transferor’s Threshold is 5,000,000
Your Credit Support Amount is therefore the greater of zero and 10,000,000 + 2,000,000 - 0 + 5,000,000) = 7,000,000.
Now, whether you have to pay anything or receive anything as a result — whether there is a Delivery Amount or a Return Amount, in other words — depends whether your Credit Support Amount is greater or smaller than your prevailing Credit Support Balance, by at least the Minimum Transfer Amount.
2016 VM CSA with no IA amendment
Since the 2016 VM CSA assumes there is no Independent Amounts and no Thresholds, it is quite a lot easier. It is just the Exposure. So much so, that there isn’t even a concept of the “Credit Support Amount” under the 2016 VM CSA, unless you have retrofitted one, and who in their right mind would do that?
Oh.
You have, haven’t you. You’ve gone and co-opted the Credit Support Amount (VM/IA) concept in your Paragraph 11 elections. Yes you did. No, don’t blame your credit department; don’t say you were just following orders. You did it.
2016 VM CSA with a customised IA amendment
Never mind. Well, just for you, the formula is a sort of half-way house: Under this unholy bastardisation of a 2016 VM CSA, a Transferee’s Credit Support Amount will be: Max[0, (ETee + IATor - IATee)].
Exposure under csa
Transaction flows and collateral flows
In a fully margined ISDA Master Agreement, all other things being equal, the termination of a Transaction will lead to two equal and opposite effects:
- A final payment or exchange under the Transaction having a value more or less equal to the present value of that Transaction;
- A offsetting change in the Exposure under the CSA in exactly the same value.
The strict sequence of these payments ought to be that the Transaction termination payment goes first, and the collateral return follows, since it can only really be calculated and called once the termination payment has been made.
I know what you’re thinking. Hang on! that means the termination payer pays knowing this will increase its Exposure for the couple of days it will take for that collateral return to find its way back. That’s stupid!
What with the regulators’ obsession minimise systemic counterparty credit risk, wouldn’t it be better to apply some kind of settlement netting in anticipation, to keep the credit exposure down?
Now, dear reader, have you learned nothing? It might be better, but “better” is not how ISDA documentation rolls. The theory of the ISDA and CSA settlement flows puts the Transaction payment egg before the variation margin chicken so, at the moment, Transaction flows and collateral flows tend to be handled by different operations teams, and their systems don’t talk. Currently, the payer of a terminating transaction has its heart in its mouth for a day or so.
Industry efforts to date have been targeting at shortening the period between the Exposure calculation and the final payment of the collateral transfer.
References
- ↑ As opposed to the amount required to be transferred on that day, considering the “Credit Support Balance” the Transferee already holds — that’s the Delivery Amount or Return Amount, as the case may be.
- ↑ There’s something faintly absurd both parties exchanging Independent Amounts by title transfer — they net off against each other — but that’s as may be. Stupider things have happened. SFTR disclosure, for example.