Time for an Industry Legal Documentation Utility?
The timescale to put the trading legal documentation in place with counterparties has always frustrated business teams. In the case of an ISDA Master Agreement and related collateral arrangement putting this in place has ranged from weeks to, in some cases, 12-18 months.
This is hard to justify in cases where the business drive to be able to trade is present, coupled with the necessary credit and ‘know-your-customer’ documentation. However, it is not just the time taken that presents a problem, but the management of the legal terms that are eventually agreed, many of which have significant pricing and operational consequences. With the plethora of regulatory changes that have buffeted the OTC market, there have also been increasing numbers of urgent repapering exercises, where financial institutions have had to amend or put new documentation into place, to take into account the regulatory changes. With the strain this has put on existing legal and documentation teams, much of the contract data management issues have fallen to the wayside.
Is this the time for the rise of a centralised Industry Legal Documentation Utility, to streamline the process of putting in place the legal documentation, and standardise terms to minimise the increasing concern around non-standard and commercially impactful terms, from both financial institutions themselves and the regulators?
The ISDA Documentation Framework
The ISDA documentation framework, which is modular in its design, has dutifully served the industry, providing the document infrastructure for derivatives trading volumes to exponentially increase in the 1990s and 2000s. The core credit, legal and relationship level terms are agreed in the ISDA Master Agreement, and the core collateral terms in a Credit Support Annex.
These can be compared to a Master Services Agreement, a contractual relationship that can often take months to agree, however, once in place, allows individual trades to be entered into with ease. The ISDA Master Agreement and the Credit Support Annex is a relational contract, intended to be capable of establishing a framework for a course of dealing over an extended period of time. The parties can then enter into individual trade confirmations each time they wish to enter into a derivatives trade, broadly speaking only having to specify the economic terms of the transaction in the trade confirmation, with the credit and legal terms having been pre-agreed and applicable through the Master Agreement and Credit Support Annex.
The Evolution of Trade Confirmations
Over the last fifteen years, as trade volumes increased, the manner in which the trade confirmations are generated and the economic trade data contained within them is managed, has developed in order to provide a suitable infrastructure to the industry (albeit with some regulatory sticks in respect of trade confirmation backlogs, a push towards the clearing of trades assisting with the standardisation of the economic terms and trade reporting requirements). Simply consider the usage of document generation tools such as Scrittura and Thunderhead in this regard, facilitating the workflow to drive the straight-through-processing of the transactions, with integration into industry utilities such as MarkitSERV. It is fair to comment that the transactions are very much data driven at the point of execution, and the trade documentation follows as a slave to its master - the commercial data.
The use of document assembly tools in the trade confirmation space relies on the following combination of items to generate the documentation:
- Client Data – there will be specific ‘know-your-client’ and operational information e.g. the name and contact details
- Commercial economic data – for example, the type of swap, the relevant interest rates and tenor
- Relevant legal template for the asset class / product – this will differ mainly based on the product, and needs to be populated accordingly with the appropriate client data and commercial economic data
This data driven approach helps to ensure that the institution can cope operationally as the systems will be set up to expect the terms of the transactions to differ as anticipated by the template, and exception-handling can be defined to scenarios that fall outside of this. It does however, rely on standardisation of the products, which has been very well facilitated by various ISDA product definitions being refined over time.
The negotiation of the ISDA Master Agreement and its collateral annexes have, in comparison, always been viewed as a bit of an art by the negotiators, with light touch processes around it and little standardisation of commonly negotiated provisions. One might say, ‘word-driven’, both in the sense of the almost universal use of Microsoft Word as a tool and the focus on the unstructured words themselves.
Growing Awareness of the Commercial Implication of Non-standard Terms
Trade confirmations confirm the terms of a trade(!), so the commercials are at the heart of this document and abundantly clear. Less so in the context of the legal relationship agreements. Rating downgrade termination events are an excellent case in point. A decade ago, pre-financial crisis, many investment banks agreed to provisions allowing their counterparties to terminate the ISDA Master Agreement relationship in the event of a decline in ratings of the bank, typically set a number of notches below the current rating of the relevant institution. The wisdom that prevailed was that if the bank really were to be downgraded to such a low credit rating – an unlikely event in itself - there would be much bigger issues at hand. As such, there was limited value in such a provision and it was fine to insert into the documentation if this would keep the counterparty happy. There were limited pricing implications of such a term.
After the crisis and the ensuing regulation, the position is different, with banks having to provide capital against the outflows that would result from the theoretical downgrade by a number of notches of the prudentially regulated firm. All of a sudden, these terms have an immediate financial impact, despite the actual rating threshold not having been hit.
The terms of the credit support annex are another example, with increased focus on the impact of these through Credit, Debit and Funding Valuation Adjustments, to just name some of the relevant xVAs. Firms have become far more sensitive to the complex embedded optionality within the collateral arrangements, in terms of the choices available of the collateral that can be posted to the counterparty – without being able to adequately price such optionality. Worse still, where they can account for the specific terms of the collateral that may be posted, the limited granularity and accuracy of firms’ collateral legal data maintained, obscured such terms, resulting in a balance sheet adjustment when the exact terms came to light.
The Specified Condition clause, found in the New York Law Credit Support Annex, is another case in point, with few financial firms monitoring this legal term in their legal agreement data, despite its commercial impact (including, losing rights of rehypothecation and entitlements to delivery and return amounts of collateral, upon the occurrence of such a specified condition).
Regulatory Supervision Concerns
The variability of language also causes issues for regulatory supervision. This is illustrated in the context of Recovery and Resolution Planning, where there is a critical need for regulators to understand the contractual impediments to an orderly resolution of a failing firm. The termination provisions, such as cross default and default under specified transaction clauses contained in these agreements, are often amended in a bespoke manner by market participants, to the extent that meaningful reporting on these provisions is not straightforward even at a financial firm level, never mind aggregated across the industry as the regulator seeks to do in order to understand systemic risk.
Lack of Standardisation of the ISDA Legal Relationship Documentation?
One might bemoan the lack of standardisation of the ISDA Master Agreement and Credit Support Annex, however it is more the lack of standardisation of the elections and variables to the pre-printed form that is an issue. The actual origins of the documents are from a drive to standardisation, as in the 1980s, local trade associations in different geographical regions sought to resolve the problem independently. For example, The British Bankers Association’s Interest Rate Swap Working Party and Forward Rate Agreement Working Party developed a standard prescriptive set of terms for interest rate swaps and forward transactions. However, in the United States, a group of swap dealers who formed the International Swap Dealers Association (now renamed to the International Swaps and Derivatives Association) devised a master agreement and menu approach. Under the ISDA approach, the master agreement provides terms that apply generally to all trades and the parties then choose additional provisions that best apply to their deal from a menu of standard terms. It is this master agreement and menu approach that has become the dominant method by which market participants document their OTC derivatives transactions today.
The issue is the subsequent vision and standardisation. This can be seen from the meagre number of ISDA Master Agreement and Credit Support Annex forms, with current substantive versions of the former in 1987, 1992 and 2002, the latter in 1994, 1995 and 2008, only addressing standardisation of the pre-print terms rather than of the elections or bespoke industry provisions in any meaningful way.
Document Assembly and Generation Tools for the Legal Documentation
The use of document assembly tools to drive the standardised generation of these documents is not a recent thought. It is easy to forget the August 2001 ISDA press release, “ISDA Selects Beachfire for Online Negotiation of ISDA Master Agreements1”, stating that Beachfire’s Collaborative Agreement Builder (a web-based collaborative negotiation solution) would enable ISDA members to streamline the process of drafting, negotiating and executing ISDA Master agreements with counterparties. Whereas a number of larger firms have invested in systems to generate these agreements and the collateral annexes, none have been able to apply this to more than very specific silos involving the most vanilla documentation.
However, without the use of a data driven approach, firms are left with a historical portfolio of agreements containing a host of critically important commercial and operational terms, resorting to manual review exercises and imperfect search tools (using character recognition) to sift through the documents. The cost of addressing the legacy documents can be prohibitive, seeking to move from unstructured data to structured data, addressing the significant noise from the failure to simply regard the documentation process as a structured data to another form of structured data transformation. Accordingly, the bleeding needs to be stopped, as these exercises are simply inefficient, expensive, and fail to drive home the important message regarding treating the legal data as a valued asset, needing the right data governance around it.
An industry utility to solve the issues?
There is no escaping the fundamentals that need to occur in order to address the issues. One needs to start with the commercially sensitive terms and standardise those into a number of industry-wide drafting options, put into strictly defined areas in the documents – with little latitude for firms to individually change the form (particularly given the substance is not in question).
Any specific legalese that then needs to be in place in an agreement with a particular counterparty again needs to be standardised where possible, but at the very least, subject to industry convention as to location within the document.
It is only strict adherence to this that will enable a true end to the legal documentation bottleneck. To date, document negotiation tools implemented by the larger banks have had only limited success because of the lack of such strict standards and conventions, working where house paper is used, but struggling with client paper negotiations. It would then facilitate the use of a cloud-based negotiation platform, empowering the business to take much more control of the legal documentation, through its focus on the commercial terms, and less on the technical legal terms.
Through the use of a data driven approach to the legal documentation, there would be a natural standardisation of the data representation of the agreement for downstream consumption by consumers such as risk and collateral, as well as easing the burden for all from a regulatory reporting perspective.
The Rationale for a Utility and bravely embracing the Change
The rapidly changing regulatory landscape, coupled with the severe cost pressure on financial firms are accelerating the industry’s willingness to embrace utilities. The larger firms simply cannot cope with the costs of individually updating their burgeoning and creaking legacy systems, whereas smaller firms still have a significant investment to make, despite their more limited volumes. This is resulting in desire to collaborate and mutualise costs.
The question will be the desire of the industry, especially legal and documentation teams to take a brave journey to positively disrupt the current mode of operation. As always, it is rarely the systems or technology that is the limiting factor, but people and process.
This article was first published in edition 7 of Rocket, our magazine. Download available Rocket editions here, and save your up to date address in your profile to to indicate your interest in receiving a printed copy of the magazine. Copies are also available to purchase and subscribe to via the shop.
To save your address into your profile:
- Visit the home page
- Click Account (in the middle of the row of black buttons)
- Click Edit Profile (in the row of buttons at the top)
- Click Reader (top right)
- There you can see your profile, with a box for your address - complete it accurately, and click Save