Template:Uk csa Exposure gen

From The Jolly Contrarian
Jump to navigation Jump to search

Calculating your 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:

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:

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)].

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:

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.

  1. 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.
  2. 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.