82,891
edits
Negotiation oubliette: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 3: | Line 3: | ||
{{oubliette capsule}} | {{oubliette capsule}} | ||
Into the oubliette you will go, taking the whole negotiation with you, the moment anyone proposes to accommodate any of the infinite | Into the oubliette you will go, taking the whole negotiation with you, the moment anyone proposes to accommodate any of the infinite [[tail event]]s that in logical theory ''could'' but in recorded history never ''have'' come about. Seeing an oubliette coming early is vital, as is the right response, since falling into it is very easy to do. The notion of a “clabby conversation” translates very well into the world of [[contract negotiation]]. | ||
So let’s look at the classic case. Warning: we are about to drop into an unseemly amount of detail about something that is very, ''very'' [[Tedium|dull]], but that is the very point: by seeing how dull these holes in the ground are, we can learn how to avoid falling into them. Remember: [[Tedium is particular, not generic|tedium is ''always'' specific, never general]]. | So let’s look at the classic case: [[DUST]]. Warning: we are about to drop into an unseemly amount of detail about something that is very, ''very'' [[Tedium|dull]], but that is the very point: by seeing how dull these holes in the ground are, we can learn how to avoid falling into them. Remember: [[Tedium is particular, not generic|tedium is ''always'' specific, never general]]. | ||
===The classic negotiation oubliette: {{isdaprov|Default Under Specified Transaction}}=== | ===The classic negotiation oubliette: {{isdaprov|Default Under Specified Transaction}}=== | ||
As all [[ISDA ninja]]s will well know, {{icds}} left the door open on a bit of chicanery in its conceptualisation of {{isdaprov|Default Under Specified Transaction}}. | As all [[ISDA ninja]]s will well know, {{icds}} left the door open on a bit of chicanery in its conceptualisation of {{isdaprov|Default Under Specified Transaction}}. | ||
[[DUST]] a form of limited bilateral [[Cross acceleration|cross-acceleration]] by dint of which one may close out transactions under ''this'' master agreement because your counterparty has defaulted on transactions under that one. A simple enough concept, and a prudent [[credit mitigation]] tool, even if it is rarely<ref>Um, ''ever''.</ref> used in practice. | |||
''But''. There are idiosyncrasies in some markets. In [[Securities financing transaction|securities financing arrangement]]s (e.g., [[stock loan]] and [[repo]]) settlement failures are common, and have nothing to do with credit stress: pure operational fails happen every day, get quickly sorted out by [[buy-in]], and the parties move on. But a [[buy-in]] is, technically an early termination of the transaction and — depending on your master agreement<ref>The GMSLA, a settlement fail is specifically not an Event of Default. there is no such carve-out under the {{gmra}} or the American equivalents the {{mra}} and {{msla}}.</ref> — may technically be an [[event of default]]. In many cases it is a matter of market convention, not documentation, that these are not treated as events of default. | ''But''. There are idiosyncrasies in some markets. In [[Securities financing transaction|securities financing arrangement]]s (e.g., [[stock loan]] and [[repo]]) settlement failures are common, and have nothing to do with credit stress: pure operational fails happen every day, get quickly sorted out by [[buy-in]], and the parties move on. But a [[buy-in]] is, technically an early termination of the transaction and — depending on your master agreement<ref>The GMSLA, a settlement fail is specifically not an Event of Default. there is no such carve-out under the {{gmra}} or the American equivalents the {{mra}} and {{msla}}.</ref> — may technically be an [[event of default]]. In many cases it is a matter of market convention, not documentation, that these are not treated as events of default. | ||
| Line 16: | Line 16: | ||
*Any default ''during'' a {{isdaprov|Specified Transaction}} — ''except'' a simple delivery failure — that leads to the acceleration of that {{isdaprov|Specified Transaction}} only | *Any default ''during'' a {{isdaprov|Specified Transaction}} — ''except'' a simple delivery failure — that leads to the acceleration of that {{isdaprov|Specified Transaction}} only | ||
*Any default at scheduled maturity of a {{isdaprov|Specified Transaction}} — ''except'' a simple delivery failure — this is to cover off the pedantic point that you can’t accelerate an obligation that is already due, so {{icds}} perceive some kind of category distinction between a performance breach ''before'' maturity and one ''at'' maturity | *Any default at scheduled maturity of a {{isdaprov|Specified Transaction}} — ''except'' a simple delivery failure — this is to cover off the pedantic point that you can’t accelerate an obligation that is already due, so {{icds}} perceive some kind of category distinction between a performance breach ''before'' maturity and one ''at'' maturity | ||
*Any default at any time that ''is'' a simple delivery failure that results in the acceleration of all outstanding transactions under the same master agreement — this, therefore, carves out simple delivery fails that the parties sort out by themselves without accelerating anything else. | *Any default at any time that ''is'' a simple delivery failure that results in the acceleration of all outstanding transactions under the same master agreement — this, therefore, carves out simple delivery fails that the parties sort out by themselves without accelerating anything else. | ||
This is so [[tedious]] as to be hard to even write about. | This is so [[tedious]] as to be hard to even write about. | ||