Template:M intro isda ISDA purpose: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
In this backgrounder the JC will look deeply at what the basic point is of an ISDA Master Agreement. Why can’t you just crack on and trade swaps without all this dusty paperwork? What is wrong with long-form confirmations?  
In this backgrounder the JC will look deeply at what the basic point is of an ISDA Master Agreement. Why can’t you just crack on and trade swaps without all this dusty paperwork? What is wrong with [[long-form confirmations|long-form confirmations?]]


This might seem like pocket-calculator stuff to seasoned veterans, but it never hurts to stop and ponder what seems to be the bleeding obvious. The JC encountered his first {{aies}} fully thirty years ago now, and he still found himself discovering things he didn’t know, or hadn’t occurred to him, as he prepared this essay.
This might seem like pocket-calculator stuff to seasoned veterans, but it never hurts to stop and ponder what seems to be the bleeding obvious. The JC encountered his first {{aies}} fully thirty years ago now, and he still found himself discovering things he didn’t know, or hadn’t occurred to him, as he prepared this essay.


The {{isdama}} is, as we know, a [[Relationship contract|framework agreement]] under which parties can transact [[swap]] contracts. The ISDA has three main goals: it is a [[relationship contract]]; it is a [[Credit risk mitigation|credit risk management tool]], and it is a [[capital optimisation]] tool.
The {{isdama}} is, as we know, a [[Relationship contract|framework agreement]] under which parties can transact [[swap]] contracts. The ISDA has three main goals: it is a [[relationship contract]]; it is a [[Credit risk mitigation|credit risk management tool]], and it is a [[capital optimisation]] tool.
===== Relationship contract =====
==== Relationship contract ====
[[File:Wedding.jpg|250px|thumb|right|A relationship contract, yesterday.]]
[[File:Wedding.jpg|250px|thumb|right|A relationship contract, yesterday.]]
It is a legal agreement governing the general relationship between two parties, dispensing with housekeeping matters like contact details, simplifying and streamlining the transaction process and generally setting parameters within which the parties agree to transact [[from time to time]]. The ISDA does not of itself create any obligations or liabilities, or otherwise commit anyone to any Transaction in particular. It simply provides an architecture: walls within which they may safely play; a roof over their heads under which they may comfortably dance.  
Firstly, the Master Agreement is a [[relationship contract]]: a legal agreement establishing the basic relationship between the parties, reciting their aspirations, dealing with housekeeping, setting out contact details and process agents, setting up the transaction process to make trade time as simple and streamlined as possible, and generally setting up the economic parameters within which the parties agree to transact [[from time to time]].  
 
The Master Agreement does not of itself create any obligations or liabilities, or otherwise commit anyone to any Transaction in particular. For this reason, and curiously, the ISDA Master does not provide ''at all'' for termination without fault on notice. This is because, absent Transactions, the ISDA doesn’t ''do'' anything: it simply provides architecture: walls within which parties may safely play; a roof over their heads under which they may comfortably dance ''if they both want to''. If they don’t fancy dancing, no one says they have to.


In that ISDAs are painful to put in place — if it only takes a couple of months you are doing well — the ISDA is also a [[commitment signal]]: it shows you care enough to engage your [[legal eagles]] in the painstaking process of working up “[[strong docs]]”.
In that ISDAs are painful to put in place — if it only takes a couple of months you are doing well — the ISDA is also a [[commitment signal]]: it shows you care enough to engage your [[legal eagles]] in the painstaking process of working up “[[strong docs]]”.


===== Credit risk management=====
If the parties do decide to dance they execute a {{isdaprov|Confirmation}}, under the auspices of the Master Agreement that inherits its terms and sets out the economic terms of the {{isdaprov|Transaction}}.
It is a [[Credit risk management|credit management]] tool: it gives each party the tools it needs to manage and reduce its [[credit exposure]] to ''the other party'' as a result of all this derivatives trading.  
 
==== Credit risk management====
Secondly, once the parties ''have'' decided to dance, the ISDA is a [[Credit risk management|credit management]] tool. It gives each party the rights it needs to manage and reduce its [[credit exposure]] to ''the other party'' as a result of all this derivatives trading. These include {{isdaprov|Credit Support}} and [[Close-out Amount - ISDA Provision|Close-out]] rights.
 
{{isdaprov|Credit Support}} may take the form of margin “posted” by the counterparty itself against its own exposure and [[guarantee]]s, keep-wells and [[letters of credit]] provided by third parties on the counterparty’s behalf.
 
{{isdaprov|Events of Default}} and {{isdaprov|Termination Events}} permit an innocent party to [[close out]] {{isdaprov|Transactions}} early, should the counterparty breach the agreement, or its creditworthiness deteriorate in more or less oblique ways contrived by the credit department. Some of the Termination Events are concerned with other externalities — change in law, force majeure, tax matters — that don’t directly affect either party’s credit position.)
=====Expected events and tail events=====
We can, in any case, distinguish between welcome “expected events” and unwelcome “tail events”.
 
“Expected events” are the risks you assume by entering the swap in the first place: the economically significant things you believe may, or may not, happen. If these things do not go how you hoped, there is no complaint: that is the bargain you struck. The forward value of goods and rates you agree to exchange.
 
“Tail events” are externalities: things that might get in the way of you enjoying the financial risk and reward of the expected events. Your counterparty blowing up or being subject to sanctions; the contract being declared illegal; relevant tax laws suddenly changing, the Great King of Terror descending in a flaming chariot, etc.<ref>The arrival of the Great King of Terror is a ''bad'' tail event: there is nothing you can really do to mitigate it. Best not write a swap on it.</ref>
 
In any case we can see a clear division of labour between the Master Agreement, under which you ''minimise and mitigate'' potential tail risks under all {{isdaprov|Transactions}}, and the {{isdaprov|Confirmation}}, under which you precisely ''describe'' (but do not ''reduce'', as such) ''market'' risk for individual {{isdaprov|Transaction}}s.<ref>This not, ah, a [[Bright-line test|bright-line distinction]], but it is a good rule of thumb. You might put some asset-specific “tail risk” Termination Events in the Confirmation, but for the most part you try to get them all into the Master Agreement.</ref>
 
So the {{Isdama}} provides a sort of “end of days” protection for the tail risks that could upset your Transactions. If a Confirmation is the GPS, the Master Agreement is the seatbelts, airbags or those inflatable slides on a plane that turn into life rafts: something we certainly want, but sincerely hope we will never need.  


Here, there is a clear difference between the Master Agreement, which is all about reducing credit risk, and the {{isdaprov|Confirmation}}, which is designed to to precisely describe (but not ''reduce'', as such) ''market'' exposure under a given {{isdaprov|Transaction}}. The point of derivatives trading is to take on market exposure, of course. Counterparty credit risk is an unwanted side effect: a tail event so the terms in the {{Isdama}} provide sort of “end of days” protection, like airbags or the inflatable slides on a plane: something we definitely want on board, but sincerely hope will never be needed.  
We are loss-averse: we tend to be prepared to spend far more time and resources than is rational preparing for apocalyptic risks. Thus, the [[negotiation]] [[military-industrial complex]] spends comparatively little time documenting the economics of swap {{isdaprov|Confirmations}} — these days a lot of that is done by computerised [[document assembly]] — but an awful lot negotiating point-to-point [[NAV trigger|net asset value trigger]]s that are almost certain never to be invoked.  


We should distinguish between “expected events“ and “tail events”. “Expected events” are things you ''hope'' will happen as a result of signing the contract: the delivery of goods; performance of services, the payment of money and so on. “Tail events” are externalities: things you sincerely hope, will not happen, particularly ones that might upset the normal run of ''expected'' events. Your counterparty blowing up; war, pandemic, the great kind of terror coming down from the sky etc.<ref>The descension from the sky of the great king of terror is a bad tail event, because there is nothing you can really do about it by way of mitigation.</ref>
The dividend of all this conceptual haggling, if done well, is a mythical contractual utopia, beloved of senior [[credit officer|credit officers]] but poorly understood by anyone else, of “[[strong docs]]”. Anyway, I digress.


It is in the nature of apocalyptic risks that we are prepared to spend far more time and resources than is rational preparing for them. Thus, the negotiation military-industrial complex, which spends comparatively little time documenting the economics of swap confirms — these days a lot of that is done by computer — but an awful lot negotiating point-to-point [[NAV trigger|net asset value trigger]]<nowiki/>s. The dividend of all this conceptual haggling, if done well, is a mythical contractual utopia, beloved of senior credit officers but not really understood by anyone else, of “[[strong docs]]”. Anyway, I digress.
==== Capital optimisation====
Thirdly, the ISDA Master is carefully designed to yield a specific regulatory capital treatment for those financial institutions who are sensitive to their [[leverage ratio]].  


===== Capital optimisation=====
Ninja point: it may look like it, but ''capital optimisation is not the same as credit risk management''. As a matter of fact, it is the ''converse'': capital management addresses the period until a counterparty credit loss actually happens, defining the minimum capital a dealer must hold to ride out the credit loss following a counterparty default.
To give regulated institutions who are sensitive to their [[leverage ratio]] the tools they need to mitigate the effect derivatives trading has on their capital calculations.  


Ninja point: it may look like it, but ''capital management is is not the same as credit risk management''. Indeed, it is the converse: capital management covers the period until a counterparty credit loss actually happens, describing the minimum capital the bank must hold to ride out the shock of that default. Once the default has happened, of course, the capital calculation in itself has no bearing on the size of the credit loss; only the institution’s ability to weather it without blowing up itself.  In this way, capital management it is more like ''own'' credit risk management it ensures that ''when'' a counterparty blows up, it doesn’t take you with it.  
Whereas credit mitigation comes into play when a counterparty has defaulted, capital optimisation works during the period beforehand. Once a counterparty has defaulted, your capital calculation is of no further use: you just hope it was enough. It makes no difference to the size of your loss; only your ability to weart the loss without failing.  In this way, capital optimisation is more like ''own'' credit risk management and counterparty risk management: it ensures that ''when'' your counterparty blows up, it doesn’t take your arms and legs with it.  


Capital management is, nonetheless, a tool for managing “expected events” and not “tails events” as such because it has a daily direct impact on the bank’s risk weighting calculations, and therefore how much capital the bank is allowed to put at risk. It is a cost management tool, not a risk management tool, that is to say.
Capital management is, therefore, also an expected event  a tool for managing “expected events” and not “tails events” as such because it has a daily direct impact on the bank’s risk weighting calculations, and therefore how much capital the bank is allowed to put at risk. It is a cost management tool, not a risk management tool, that is to say.


The principal tool for managing the capital cost of a swap master agreement is [[close out netting|close-out netting]].  
The principal tool for managing the capital cost of a swap master agreement is [[close out netting|close-out netting]].  

Revision as of 19:07, 3 January 2024

In this backgrounder the JC will look deeply at what the basic point is of an ISDA Master Agreement. Why can’t you just crack on and trade swaps without all this dusty paperwork? What is wrong with long-form confirmations?

This might seem like pocket-calculator stuff to seasoned veterans, but it never hurts to stop and ponder what seems to be the bleeding obvious. The JC encountered his first Aïessdiyé fully thirty years ago now, and he still found himself discovering things he didn’t know, or hadn’t occurred to him, as he prepared this essay.

The ISDA Master Agreement is, as we know, a framework agreement under which parties can transact swap contracts. The ISDA has three main goals: it is a relationship contract; it is a credit risk management tool, and it is a capital optimisation tool.

Relationship contract

A relationship contract, yesterday.

Firstly, the Master Agreement is a relationship contract: a legal agreement establishing the basic relationship between the parties, reciting their aspirations, dealing with housekeeping, setting out contact details and process agents, setting up the transaction process to make trade time as simple and streamlined as possible, and generally setting up the economic parameters within which the parties agree to transact from time to time.

The Master Agreement does not of itself create any obligations or liabilities, or otherwise commit anyone to any Transaction in particular. For this reason, and curiously, the ISDA Master does not provide at all for termination without fault on notice. This is because, absent Transactions, the ISDA doesn’t do anything: it simply provides architecture: walls within which parties may safely play; a roof over their heads under which they may comfortably dance if they both want to. If they don’t fancy dancing, no one says they have to.

In that ISDAs are painful to put in place — if it only takes a couple of months you are doing well — the ISDA is also a commitment signal: it shows you care enough to engage your legal eagles in the painstaking process of working up “strong docs”.

If the parties do decide to dance they execute a Confirmation, under the auspices of the Master Agreement that inherits its terms and sets out the economic terms of the Transaction.

Credit risk management

Secondly, once the parties have decided to dance, the ISDA is a credit management tool. It gives each party the rights it needs to manage and reduce its credit exposure to the other party as a result of all this derivatives trading. These include Credit Support and Close-out rights.

Credit Support may take the form of margin “posted” by the counterparty itself against its own exposure and guarantees, keep-wells and letters of credit provided by third parties on the counterparty’s behalf.

Events of Default and Termination Events permit an innocent party to close out Transactions early, should the counterparty breach the agreement, or its creditworthiness deteriorate in more or less oblique ways contrived by the credit department. Some of the Termination Events are concerned with other externalities — change in law, force majeure, tax matters — that don’t directly affect either party’s credit position.)

Expected events and tail events

We can, in any case, distinguish between welcome “expected events” and unwelcome “tail events”.

“Expected events” are the risks you assume by entering the swap in the first place: the economically significant things you believe may, or may not, happen. If these things do not go how you hoped, there is no complaint: that is the bargain you struck. The forward value of goods and rates you agree to exchange.

“Tail events” are externalities: things that might get in the way of you enjoying the financial risk and reward of the expected events. Your counterparty blowing up or being subject to sanctions; the contract being declared illegal; relevant tax laws suddenly changing, the Great King of Terror descending in a flaming chariot, etc.[1]

In any case we can see a clear division of labour between the Master Agreement, under which you minimise and mitigate potential tail risks under all Transactions, and the Confirmation, under which you precisely describe (but do not reduce, as such) market risk for individual Transactions.[2]

So the ISDA Master Agreement provides a sort of “end of days” protection for the tail risks that could upset your Transactions. If a Confirmation is the GPS, the Master Agreement is the seatbelts, airbags or those inflatable slides on a plane that turn into life rafts: something we certainly want, but sincerely hope we will never need.

We are loss-averse: we tend to be prepared to spend far more time and resources than is rational preparing for apocalyptic risks. Thus, the negotiation military-industrial complex spends comparatively little time documenting the economics of swap Confirmations — these days a lot of that is done by computerised document assembly — but an awful lot negotiating point-to-point net asset value triggers that are almost certain never to be invoked.

The dividend of all this conceptual haggling, if done well, is a mythical contractual utopia, beloved of senior credit officers but poorly understood by anyone else, of “strong docs”. Anyway, I digress.

Capital optimisation

Thirdly, the ISDA Master is carefully designed to yield a specific regulatory capital treatment for those financial institutions who are sensitive to their leverage ratio.

Ninja point: it may look like it, but capital optimisation is not the same as credit risk management. As a matter of fact, it is the converse: capital management addresses the period until a counterparty credit loss actually happens, defining the minimum capital a dealer must hold to ride out the credit loss following a counterparty default.

Whereas credit mitigation comes into play when a counterparty has defaulted, capital optimisation works during the period beforehand. Once a counterparty has defaulted, your capital calculation is of no further use: you just hope it was enough. It makes no difference to the size of your loss; only your ability to weart the loss without failing. In this way, capital optimisation is more like own credit risk management and counterparty risk management: it ensures that when your counterparty blows up, it doesn’t take your arms and legs with it.

Capital management is, therefore, also an expected event a tool for managing “expected events” and not “tails events” as such because it has a daily direct impact on the bank’s risk weighting calculations, and therefore how much capital the bank is allowed to put at risk. It is a cost management tool, not a risk management tool, that is to say.

The principal tool for managing the capital cost of a swap master agreement is close-out netting.

Derivatives are odd contracts because they are inherently levered, and therefore extremely volatile. They have large notional values, but lower mark-to-market values. An “at-market” swap[3] starts with zero exposure, either way, and thereafter can fluctuate wildly in either direction. Compare this with a traditional loan, where the transaction starts with an exposure equal to its notional amount — lender goes “in the money”, borrower “out-of-the-money” — and the value of the loan to the lender then fluctuates narrowly around that notional amount (to account for accrued interest, changing interest rates, and the borrower’s changing credit profile) until it is all repaid, in one go, at maturity. The exposure profile of a swap is very different. The raw market exposure of a portfolio of swap transactions can, thus, be huge compared with the original capital committed (i.e. zero): the total of all your out-of-the-money positions, which you can assume you must perform, versus all collateral you hold, which you should assume you will be required to return.

If you can treat that overall total exposure as the net sum of the offsetting positive and negative exposures — especially where the bank also requires variation margin[4] — the capital requirement is much more manageable — on margined trades, net mark-to-market exposure is reset to zero every day. The capital calculation on that is extremely complicated, but this offsetting effect is powerful. It would be a whole lot higher if you couldn’t take account of close out netting.

The “standard of proof” for “netting down” Transaction exposures is also huge: regulations require banks to obtain an external legal opinion that the netting contract actually will — not just should — work. This is a “beyond reasonable doubt” sort of standard. By contrast, when setting a “credit line” the credit department is not directly constrained.[5]

There was once a time where the credit team might take a more lenient view for credit risk management purposes than the treasury team could for capital purposes. As the global financial crisis wore on, this sort of cavalier “IBGYBG” attitude gave way to a new austerity and credit teams started to think the better of this. (It probably didn’t make a lot of difference, really: you can make your credit line as big as you like, but if you have to gross your exposures for capital purposes you won’t be competitive in the market).

  1. The arrival of the Great King of Terror is a bad tail event: there is nothing you can really do to mitigate it. Best not write a swap on it.
  2. This not, ah, a bright-line distinction, but it is a good rule of thumb. You might put some asset-specific “tail risk” Termination Events in the Confirmation, but for the most part you try to get them all into the Master Agreement.
  3. Almost all swaps start off as at-market. Starting your swap off the market implies a one-way initial payment under the transaction, by way of premium, to the party who starts “out-of-the-money”. Otherwise, it would be economically irrational to enter into the Transaction.
  4. Though VM has its dark nemesis: see our essay when variation margin attacks.
  5. As ever, our old friend Lucky provides a great example. During Archegos the risk team repeatedly changed the applicable risk model to something more benign so they could continue to trade.