DRS’ Michael Beaton explores
Introduction
On 6 March 2015, the European Banking Authority (EBA) published a consultation paper containing a “Draft Regulatory Standard on a minimum set of the information on financial contracts that should be contained in the detailed records” required by the Bank Recovery and Resolution Directive[1] (BRRD).
The consultation period closes on 6 June 2015 so as to enable the EBA to meet its commitment to submit the RTS to the EU Commission by 3 July 2015. Broadly, the draft Regulatory Technical Standard (RTS) applies to EU credit institutions, EU investment firms and their EU group companies (to the extent that the latter are financial firms)[2] (“Relevant Firms”). It is required as a consequence of Article 71 of the BRRD, which gives resolution authorities the power to temporarily suspend termination rights of any party to a contract with an institution under resolution. In order to facilitate the effective exercise of this power, Article 71(7) states that resolution authorities may require a Relevant Firm to maintain “detailed records” of “financial contracts” and Article 71(8) requires the EBA to define the minimum set of the information that should be contained in the “detailed records” as well as the circumstances in which the requirement to maintain detailed financial records should be imposed on firms.
“Financial Contracts”
The definition of “financial contracts” includes[3]:
a) securities contracts (including stock lending and repurchase transactions);
b) commodities contracts;
c) futures and forwards contracts;
d) swap agreements (including swaps and options relating to interest rates; foreign exchange; currencies; indices; commodities; weather; emissions; inflation and credit) together with any similar transactions and which are the subject of recurrent dealing in the swaps or derivatives markets;
e) inter-bank borrowing agreements where the term of the borrowing is three months or less; and
f) master agreements for any of the contracts referred to above.
Maintenance of “detailed records”
The RTS proposes that a Relevant Firm shall be required to maintain detailed records of financial contracts if its resolution plan envisages that resolution actions would be taken in relation to the firm in the event that the conditions for resolution were met[4]. In other words, less systemically important Relevant Firms – which are more likely to simply be allowed to enter traditional insolvency rather than be subject to resolution – are not automatically subject to the requirement to maintain detailed records of financial contracts. This, the EBA states, is in line with the principle of proportionality which pervades the BRRD, although it is quick to point out that nothing in the RTS precludes resolution authorities from requiring less systemically important Relevant Firms to maintain detailed records. In either case, there is no requirement on Relevant Firms to report the detailed records relating to financial contracts. Rather, the requirement is simply to maintain the necessary data and make the same available to resolution authorities on request.
Nature of “detailed records”
The Schedule to this article lists the information which should be kept at a minimum as part of “detailed records”[5]. However, the consultation paper makes clear that this is not necessarily an exhaustive list and authorities are at liberty to require additional information from Relevant Firms. This approach is intended to strike a balance between the need to achieve an appropriate level of convergence in record keeping whilst allowing resolution authorities to impose additional requirements where considered appropriate for the purposes of ensuring that the resolution powers can be applied effectively to different types of business.
Outstanding Questions
Do your current capabilities make the grade?
The RTS does not prescribe a specific template for the maintenance or provision of information contained in financial contracts. However, it is clear that all data must be collected in advance and kept in a central location on a relational database from which it can be “accessed”, “interrogated”, “extracted readily” and “provided easily” to authorities. As such, even though it is prepared to be flexible in the way in which data is stored, the EBA expects firms to implement a technological solution with minimum baseline functionality in order to achieve compliance in this area. This is consistent with the emphasis on data and transparency which has been such a hallmark of financial regulation since the collapse of Lehman. The conclusion is that those firms which currently store and analyse data on spread sheets (or similar) will be required to adopt a new approach to understanding the terms of their financial contracts. Even those firms with the ability to execute searches across portfolios of documentation will find themselves falling short of the required mark. Rather, what is required is the ability to transform unstructured data from contracts into structured metadata and to intelligently analyse and flexibly report on the results. Whilst there are clearly cost implications in implementing and maintaining this type of technology, the fact that Relevant Firms are required to notify resolution authorities of the identity of the member of the management body (i.e. the board member) responsible for maintaining the detailed records, should mean that senior management are incentivised to find the budget necessary to address this issue properly.
The RTS does not require firms to maintain a digitised image file of the financial contract with the metadata relating to that contract. In other words, the EBA is implementing a requirement to store metadata, but not actual data, relating to financial contracts. This seems somewhat anomalous given (a) the absence of a specific template which would help ensure completeness and consistency in terms of metadata relating to financial contracts, and (b) the ultimate aim of the RTS which is to promote the effective and efficient application of the resolution tools and resolution powers. In a resolution situation, one would imagine that having the ability to readily access actual contracts would be of great value to a resolution authority. As such, it would not be surprising if many resolution authorities made this an additional data requirement and Relevant Firms should consider this when implementing solutions in this area. At the very least, it would seem wise to maintain image files with their associated metadata if only for audit purposes and so as to be able to more easily verify the accuracy of data.
How up-to-date should data be?
Questions remain about the meaning of “maintenance”, specifically the frequency with which information must be refreshed and kept up-to-date. The consultation paper states that information must be maintained on “an ongoing basis” and “made available to the competent authorities and resolution authorities on request”. In a wider context, the FSB’s Key Attributes of Effective Resolution Regimes for Financial Institutions requires firms to have the ability to produce data within 24 hours[6] and the BRRD enables resolution authorities to suspend termination rights for only 1 Business Day. Given that the ultimate purpose of the RTS is to promote the effective and efficient application of resolution powers, it would seem logical to conclude that, in practice, firms will be required to ensure that data from financial contracts is processed and made available within 1-2 business days of creation. The consequential resourcing requirement is likely to be significant.
How big a challenge will this be?
The RTS attempts to maintain consistency with EMIR in terms of language and structure and there is certainly significant overlap between EMIR reporting and the RTS. Like EMIR reporting, the “detailed records” requirement encompasses economic and legal terms traditionally documented in confirmations (such as “Effective Date” and “Maturity Date” of a transaction), provisions found in framework Master Agreements (such as “Master Agreement Type”) and structured data feeds taken from trading and collateral systems (such as “Value of the contract” and “Collateral portfolio codes”). Not only must individual trades be mapped to their master agreements, but financial contracts must also be mapped to core business lines and external taxonomies, such as corporate sectors and CFI codes[7]. A number of the required data points are dynamic in nature and will have to be periodically refreshed (e.g. date/time of last valuation). Complicating matters yet further is the fact that some information will have to be sourced from counterparties (e.g. EMIR counterparty status), making the job of data verification yet more challenging. The net result is a real challenge in terms of sourcing and assimilating both unstructured and structured data.
However, as an exercise in data management, the RTS threatens to go far beyond the challenge posed by EMIR reporting. By way of example, the “Contractual Recognition – Resolution” requirements presuppose that firms have already conducted extensive remediation exercises to bring portfolios of documentation into line with the new requirements through the inclusion of contractual resolution recognition clause. They demand that, if only some of the resolution powers available under the BRRD (of which there are almost 30)[8] are recognised within a contractual recognition provision, Relevant Firms must specify precisely which of the resolution powers have been recognised. Other requirements, such as “Type of liability/claim”, assume that firms will conduct a significant amount of analysis – both in relation to their financial contracts and their liabilities more generally – to assess whether liabilities are subject to the bail-in tool.
An additional challenge arises by virtue of what has been left unsaid by the RTS. As an example, ostensibly at least, compliance with the “Termination Right” data point – which asks firms to indicate whether a contractual termination right is based solely on the insolvency or financial condition of the institution under resolution – would seem straightforward. However, it will require firms to perform a significant amount of highly focused data mining. In practice, if only for audit and data verification purposes, each contractual termination right, and all of its attendant legal vagaries, will have to be analysed in turn, irrespective of whether it is linked to insolvency or the financial condition of the institution under resolution.
Conclusion
The cost-benefit analysis accompanying the RTS notes that “Most Member States are currently preparing information collection and reporting procedures for the purposes of their bank recovery and resolution frameworks”. In other words, this is not a problem that is going to go away. Quite the opposite – the requirement to mine data from documentation looks set to be extended, with the minimum list of information provided in the draft RTS serving as a basis for authorities when exercising their discretion to impose similar requirements in the context of recovery planning[9] and resolution planning[10].
This consultation paper should be the trigger for any EU G-SIB[11], D-SIB[12] or investment firm of substantial size to reassess whether its current systems and processes for the acquisition, analysis and reporting of metadata from financial contracts is fit for purpose. On the bright side, firms can legitimately view the RTS as an opportunity. If XVA has shown the market anything, it is that data is fast becoming the new competitive frontier. The ability to access, validate and assimilate legal and commercial data, to combine it with other data sources, analyse results and rapidly form and apply conclusions in order to drive smarter business decisions is a factor which is already beginning to distinguish a select group of financial institutions from their peers. At a time when transparency and reporting are keystones of the regulatory environment, not only are firms which have embraced a culture of data better able to achieve and demonstrate regulatory compliance, adapt to regulatory change and assess risk, but they are increasingly able to monetise this inherent advantage, turning data into dollars at the expense of competitors. If the RTS is the spark which motivates a firm to join this select band, it should be welcomed with open arms.
Schedule
The minimum set of the information on financial contracts that should be contained in the detailed records
|
Field |
Description of information to be maintained in detailed records of financial contracts |
|
Section 1 – Parties to the financial contract |
|
1 |
Counterparty ID |
Unique code (Legal Entity Identifier (LEI), where available) identifying the reporting counterparty. In the case of an individual, a client code shall be used. |
2 |
ID of the other counterparty |
Unique code (Legal Entity Identifier (LEI), where available) identifying the other counterparty of the contract. This field shall be filled from the perspective of the reporting counterparty. In the case of an individual, a client code shall be used. |
3 |
Name of the counterparty |
Corporate name of the reporting counterparty. This field can be left blank where the counterparty ID already contains this information |
4 |
Domicile of the counterparty |
Information on the registered office, consisting of full address, city and country of the reporting counterparty. This field can be left blank where the counterparty ID already contains this information |
5 |
Corporate sector of the counterparty |
Nature of the reporting counterparty’s company activities (bank, insurance company, etc.). This field can be left blank in case the counterparty ID already contains this information. |
6 |
Financial or non-financial nature of the counterparty |
Indicate whether the reporting counterparty is a financial or nonfinancial counterparty in accordance with points 8 and 9 of Article 2 of Regulation (EU) No 648/2012. |
7 |
Group undertaking |
Indicate parent, subsidiary or other. |
8 |
Contract with non-EEA counterparty |
Indicate whether the other counterparty is domiciled outside the EEA. |
9 |
Governing law |
Identify governing law of the financial contract. |
10 |
Contractual recognition – Write-down and conversion (third country governed contracts only) |
The contract includes term by which the creditor or party to the agreement creating the liability recognises that liability may be subject to the write-down and conversion powers by any reduction of the principal or outstanding amount due, conversion or cancellation that is effected by the exercise of those powers by a resolution authority in compliance with the requirement set out in Article 55(1) of the BRRD. |
11 |
Contractual recognition – Resolution (third country governed contracts only) |
The contract includes a term by which the creditor or party to the agreement creating the liability recognises that the contract may be affected by an application of the resolution powers by a Member State resolution authority and agrees to be bound by the effects of the application of such powers. Where not all but only some resolution powers are recognised, specify which are recognised. |
12 |
Financial contract relates to core business lines |
Identify which core business line it relates to. |
13 |
Value of contract |
Mark to market valuation of the contract, or mark to model valuation where applicable under Article 11(2) of Regulation (EU) No 648/2012. The CCP‘s valuation to be used for a cleared trade. |
14 |
Currency of the value |
The currency used for the valuation of the contract |
15 |
Valuation date |
Date of the last mark to market or mark to model valuation. |
16 |
Valuation time |
Time of the last mark to market or mark to model valuation. |
17 |
Valuation type |
Indicate whether valuation was performed mark to market or mark to model or provided by the CCP. |
18 |
Trade exposure |
As defined in Article 4(1)(91) of the Capital Requirements Regulation[1]. |
19 |
Collateralisation |
Whether collateralisation was performed. |
20 |
Composition of the collateral |
List of instruments posted as collateral by the reporting counterparty to the other counterparty, and collected by the reporting counterparty from the other counterparty. |
21 |
Collateral portfolio |
Whether the collateralisation was performed on a portfolio basis. Portfolio means the collateral calculated on the basis of net positions resulting from a set of contracts, rather than per trade. |
22 |
Collateral portfolio code |
If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty. |
23 |
Initial margin posted |
Value of each of the instruments posted as initial margin by the reporting counterparty to the other counterparty |
24 |
Initial margin received |
Value of each of the instruments collected as initial margin by the reporting counterparty to the other counterparty. |
25 |
Variation margin posted |
Value of the each of the instruments posted as variation margin posted, including cash settled, by the reporting counterparty to the other counterparty. |
26 |
Variation margin collected |
Value of each of the instruments collected as variation margin posted, including cash settled, by the reporting counterparty from the other counterparty |
27 |
Currency of the collateral value |
Specify the value of the collateral for fields 23 to 27. |
|
Section 2a – Financial contract type |
|
28 |
Type of the financial contract |
a) Securities contract; b) Commodities contract; c) Future and forward contracts; d) Swap agreements; e) Inter-bank borrowing agreement (where the term of the borrowing is three months or less). |
29 |
Product ID 1 |
The contract shall be identified by using a product identifier: Product Identifier (UPI, endorsed in Europe), ISIN or derivative class (Commodity, Credit, Currency, Equity, Interest Rate, Other). |
30 |
Product ID 2 |
The contract shall be identified by using a product identifier: CFI or derivative type (Contracts for difference, Forward rate agreements, Futures, Forwards, Option, Swap, Other) |
|
Section 2b – Details on the transaction |
|
31 |
Effective date |
Date when obligations under the contract come into effect. |
32 |
Maturity date |
Original date of expiry of the reported contract. An early termination shall not be reported in this field. |
33 |
Termination date |
Termination date of the reported contract. If not different from maturity date, this field shall be left blank. |
34 |
Termination conditions |
Termination conditions of the reported contract, if different from maturity date. |
35 |
Termination right |
Whether the termination right under the reported contract is based solely on the insolvency or financial condition of the institution under resolution. |
36 |
Master Agreement type |
Reference to the name of the relevant master agreement, if used for the reported contract (e.g. ISDA Master Agreement; Master Power Purchase and Sale Agreement; International ForEx Master Agreement; European Master Agreement or any local Master Agreements). |
37 |
Master Agreement version |
Reference to the year of the master agreement version used for the reported trade, if applicable (e.g. 1992, 2002, etc.). |
38 |
Netting arrangement |
Name of the netting arrangement governing the contract |
|
Section 2d – Clearing |
|
39 |
Cleared |
Indicates whether clearing has taken place. |
40 |
Intragroup |
Indicates whether the contract was entered into as an intragroup transaction, defined in Article 3 of Regulation (EU) No 648/2012. |
41 |
Type of liability/claim |
Indicates if an eligible liability or a secured liability. |
42 |
Value of liability/claim |
Including on a net basis per master agreement or other applicable netting agreement. |
[2] See the definition of “institution” and Article 1(1)(b), (c) and (d)
[3] Article 2(1)(100) of the BRRD
[4] Article 2
[5] As required by Article 3 of the RTS
[6] See paragraph 12.2(iii)
[7] Classification of Financial Instruments” as defined in ISO 10962
[8] See Articles 63 to 72 of the BRRD
[9] See Article 5(8) of the BRRD
[10] See Article 10(8) of the BRRD
[11] Global Systemically Important Bank
[12] Domestic Systemically Important Bank
[13] Regulation (EU) No 575/2013