The linkage of trades to the master trading agreements that govern them (“trade tagging”) is a fundamental task of any trading institution – it must be accurate, immediate, and business as usual. Yet poor process design and data governance across multiple business areas continues to create significant issues, affecting key aspects of every institution’s risk management – from netting to capital adequacy and collateral management. And regulators are starting to take note – it’s just amazing it took so long (maybe, it was just too primal a requirement!).
It should be straightforward to link trades to the right master trading agreement at the point of trade, yet this is frequently not done. Accordingly, most banks need to rely on post-trade business processes to link trades to their respective trading agreements. With potentially tens of millions of legacy trades – if trade matching is not highly automated, efficient, and accurate – a host of risks and issues quickly emerge. Trade matching processes are dependent on complete and accurate data that must be sourced from multiple locations (e.g., front office trade data, post trade confirmations, counterparty data and legal agreement data). The reality is that data quality across these sources is far too often sub-par. Common data issues include incomplete or stale data, as well as conflicting data definitions. This results in trading tagging issues – ranging from multiple master agreements to counterparties marked invalid and confusion over product coverage of agreements.
Automated trade tagging solutions can’t resolve this inconsistency, resulting in large volumes of exceptions that must be manually researched and corrected. Potentially even more problematic are trades that may be tagged incorrectly, creating issues in credit risk, liquidity, client assets and money, or regulatory capital reports.
A strategic change is required, encompassing every relevant division and, critically, it has to have the support of the legal function. Poor trade tagging can undermine the work of a legal team, leading to a plethora of regulatory issues – never mind the business impact. As Eric Mueller, US Lead; Ali Bandali, Senior Consultant; and Akber Datoo, CEO, D2 Legal Technology insist, legal has the skills to resolve this problem – and it is vital they take the lead now.
Operational Imperative
As the capital markets grew, the trading documentation architecture evolved to enable rapid growth. Master trading agreements were created to contain relationship level and credit terms between parties, such as the ISDA Master Agreement, the Global Master Repurchase Agreement (published by ICMA and SIFMA) and the Global Master Securities Lending Agreement (published by ISLA). The trades themselves (and the economics) were separated out, and later confirmed in trade confirmations, governed by those trading master agreements.
The linking of the trades (and confirmations) back to a master trading agreement between the parties is integral to business risk assessment and regulatory reporting. From netting to Capital Requirements Regulation, European Market Infrastructure Regulation (EMIR) and collateral management, accurate trade tagging is vitally important to every institution. Effective trade management systems and ensuring data is accurate is also key to compliance with BCBS239, a post-Financial Crisis recognition of the role poor data governance played in the building up of risk within the financial system.
And it’s not new – far from it. So why are many institutions only now beginning to recognise the lack of integrity and consistency within trade tagging models and the implication on accurate reporting of their Risk Weighted Asset (RWA)? The infrastructure has been in place to support Master Trade Agreements for decades – it has been some 35 years since D2LT’s Jeffrey Golden led the drafting of the first ISDA Master Agreement. Legal teams dedicate huge amounts of time and resource to creating and defining relationship agreement terms between counterparties – yet the vital importance of tagging every trade to a master agreement seems to have been eroded over time, or shall we say, fallen between the cracks of silos – from legal to middle office to credit and to the trading desks themselves.
At the beginning, it was perhaps a bit too easy. Two parties would typically only have the one master trading agreement between them – let’s say an ISDA Master Agreement, for their OTC derivatives trading. But over time, there may have been a need for a specific structured transaction between those same parties, for which the general relationship level and credit terms were just not appropriate. So, the two in-house legal teams crafted a new ISDA Master Agreement, to be used for this transaction – and perhaps, due to the focus on the structured transaction, it was correctly tagged to this bespoke agreement. This was however, simply something kept within the knowledge of the legal team and the relevant business desk. The two firms continued to trade interest rates swaps, and other non-structured transactions. However, the middle office, when trying to determine how to book the trade, saw two ISDA Master Agreements – and assumed this was some sort of mistake. Surely, there is only one master agreement, and therefore trades should be tagged to the one with the later date in time.
Dangerous Legal Disconnect
How has this come about?
There is a disconnect between legal teams and the rest of the business – a disconnect reflected in attitude, technology, even basic definitions. Increasingly, these disconnects manifest themselves through the medium of data in systems.
Legal and credit, for example, may take a different approach to defining a counterparty. A counterparty may be one legal entity but may also enjoy a number of different credit profiles, hence the need for a single legal identifier, but multiple credit identifiers. Not only is the information stored in different systems but, at its worse, legal and credit will actually use each others’ IDs, oblivious to the differences these may entail, creating another point of failure in an already broken system. How can any institution have faith in any reporting when the data usage and data attributes are so poorly defined?
Umbrella agreements, where an investment manager acts on behalf of multiple (principal) funds, and the documentation clones master trading agreements with each of these principals is another source of many issues, with an inevitable confusion of legal agreement identifiers and client identifiers.
And product data is also problematic, with invariable differences between product definitions in trading, credit and legal agreement systems (of course, creating an inevitable disaster when it comes to close-out netting and the regulatory capital calculation that is so important from a financial stability point of view!).
Linking transactions to master agreements and related collateral agreements is a crucial part of the close-out netting determination. Adding in the problems of product type definitions, it is very easy to see how the lack of strategic attention and the plethora of tactical data fixes is leading to incorrect close-out netting and collateral enforceability determinations, or at best, determinations that lack the requisite audit trail back to the data inputs.
Inadequate Data Governance
Some institutions have taken tactical steps to address aspects of these data inaccuracies – but this has, more often than not, simply created more data quality issues in other areas. For example, relying on a trade tagging process does not clearly recognise and differentiate between the legal and credit view of a counterparty. This is about understanding the purpose for which we need client, product and agreement identifiers, precisely defining these identifiers, and then ensuring any usage of these identifiers is consistent with such data definitions.
The problem is an end-to-end failure in data governance – and with the growing regulatory focus on BCSB239 compliance, this is a serious concern. Who is responsible for maintaining data definitions? Who is responsible for the consequences when a definition or data point is changed? What happens if a master trading agreement is changed from ‘valid’ to ‘invalid’ in a legal agreement database? Where is the impact felt and, critically (no BCBS239 pun intended!), does anyone know?
If an institution cannot answer these questions – and far too many cannot – something has to change fast. These inconsistencies in data definitions, these untracked changes to data points are creating significant risk – yet it remains hidden. Moreover, the linkage between trades and the master trading agreements that govern them is the legal department’s link to the business they support.
Strategic Commitment
This is not a problem that can be resolved with a simple algorithm to allocate trades to the correct master agreement – the underpinning data sources are too diverse, too numerous and too institution-specific. Best practice is evolving but it will require fundamental redesign of the trade tagging process and a reliance on high-quality data sources. This requires expertise, knowledge and commitment across a wide number of operational areas, including credit and legal, to progress and achieve a golden source of trade data that supports each department’s information needs and view on trade tagging. We need to stop the bleeding and trades need be mapped to the master agreement at the point of trade booking.
Given the decades’ long history of system development and different data governance models, there is no shortcut to this process – although developments such as the industry clause taxonomies and libraries provide some support, covering clauses that are crucially important to the trade tagging mechanism.
One unarguable point is that this process needs the involvement of the legal function – this can only be solved by a legal team committed to being more than an advisory role and being a core, value adding part of the business. By taking the lead and embracing a strategic approach to trade tagging specifically – and data governance in general – there is an opportunity to not only avoid the possible, currently unknown regulatory or business issues, but also to add significant value to the institution. Lawyers will need to get familiar with the data that represents the master trading agreements – in a world in which they are now surrounded by systems and the increasing embracing of the digital agenda, words on a page no longer suffice.
This is legal data – and the legal function not only needs to take ownership but, frankly, it is the only team with the requisite expertise to provide a solution. This is the recognition of the importance of the legal agreement data domain.
