Michael Beaton of DRS explores the recently published regulatory technical standards for the BBRD.
Introduction
On 17 December 2015, the EBA published its “Draft Regulatory Technical Standards on a minimum set of the information on financial contracts that should be contained in the detailed records and the circumstances in which the requirement should be imposed” (the RTS) as required by Article 71(7) of the Bank Recovery and Resolution Direction (BRRD).
The requirement to maintain detailed records of financial contracts[1]
A “financial contract” includes (a) securities contracts, (b) commodities contracts, (c) futures and forwards contracts, (d) swap agreements, (e) inter-bank borrowing agreements where the term of the borrowing is three months or less, and (f) master agreements for any of the aforementioned.[2] The requirement to maintain detailed records from financial contracts is designed to support the effective and efficient application of resolution powers and resolution tools, particularly the power to temporarily suspend termination rights.[3] Broadly, an institution which is subject to the BRRD is required to maintain detailed records of financial contracts where its resolution plan contemplates that it would be subject to resolution rather than standard insolvency proceedings[4]. Institutions that are likely to be placed into insolvency or that are subject to a waiver under Article 4(8) of the BRRD are not automatically subject to the requirement, but this does not prevent authorities from imposing the same or similar requirements on them.
The information to be kept (at a minimum) in “detailed records”[5]
The RTS specifies only a minimum – and not an exhaustive – list of information which should be maintained by firms. This is intended to strike a balance between the need to achieve an appropriate level of convergence in record keeping whilst enabling authorities to impose additional requirements where considered appropriate. Neither does the RTS prescribe the format in which data should be provided although, again, it remains open to authorities to do so. The Annex to this article provides a full list of the final data points to be maintained, highlighting requirements that have been deleted from the original consultation paper (in red), added in the final RTS (in green) and those that have remained unaltered between the two (in black), together with a suggestion of where each data point may be sourced in practice.
EBA Lacks Resolve to Tackle Resolvability?
The EBA received a total of 8 responses to its consultation paper and has softened its original requirements in a number of respects as a result of the feedback received. Unsurprisingly, the main objection from respondents related to the requirement that information be kept in a “central location on a relational database capable of being accessed by the competent and resolution authorities from which information can be extracted readily and transmitted to the relevant authority”. Whilst some respondents accepted that a database was required, most argued (probably correctly) that the BRRD does not grant a mandate to the EBA to define technical aspects of the way in which information is to be held. Others pointed out that the establishment of a single database would be challenging in light of cross-border privacy, banking secrecy and data protection laws. One respondent advocated that information from financial contracts be kept in external databases with existing trade repositories in order to avoid duplication and administrative burden. The general feeling was that the EBA should focus on an outcomes based approach rather than prescribe technical elements. The EBA has accepted this feedback. The final RTS no longer requires that data be held in a central relational database, instead merely stating that information must be collected in advance, on an ongoing basis[6], and made available to authorities on request within the timescale specified within the request[7].
Elsewhere, in response to comments questioning their relevance to matters of resolvability, a number of data points proposed in the original consultation have been removed. These include “Corporate sector of the counterparty”, “Financial or non-financial nature of the counterparty”, “Group undertaking” and “Contract with non-EEA counterparty”. Clarification has also been provided in a number of other areas, such as the need to maintain data regarding contractual recognition of the power to suspend early termination rights; that collateralisation typically takes place on a portfolio level (rather than by reference to individual transactions); and the fact that there is no practical difference between ‘Termination Conditions’ and ‘Termination Rights’ – with the two previously discrete data points effectively being consolidated.
Despite this, the data challenge associated with the RTS should not be underestimated. It is still not certain how all information should be reported. The ‘Termination Right’ data point[8] is of most importance in this regard. It requires firms to indicate whether a counterparty’s termination rights in relation to a financial contract are based on the firm’s insolvency or financial condition. In practice, there may be a number of clauses that are potentially in scope under this heading – some of which are highly complex in nature – such as bankruptcy Events of Default, Cross-Default, Credit Event Upon Merger, ratings downgrade triggers and ‘MAC’ clauses. Unfortunately, to date, no guidance is provided on whether all of this data should be captured or the manner in which it should be presented.
Complicating matters yet further is the fact that data is likely to come from many sources, all of which will have to be monitored on an on-going basis. A number of data points will have to be mined from master agreements. This will include “Governing law”[9], “Currency of the collateral value”[10], “Master Agreement type”[11] and “Master Agreement version”[12]. Some will come from confirmations, such as “Effective Date”[13], “Maturity Date”[14] and “Termination Date”[15]. Other data will have to come from internal systems, such as “Country of the other Counterparty”[16], “Value of contract”[17] and collateralisation information[18]. Yet other data will have to be sourced externally. For example, in practice, contractual recognition of bail-in, suspension of termination rights and application of resolution powers provisions[19] will often have been incorporated into documentation by way of ISDA protocol. The extent to which firms routinely, consistently and continuously monitor changes in protocol data is, at best, questionable, bringing into question the accuracy of data in this area. Perhaps most challenging of all, the “Type of liability/claim”[20] data point will require firms to analyse transactions against complex and vague regulatory requirements, namely the bail-in provisions of the BRRD.
More fundamentally, questions remain as to whether the information required by the RTS is sufficient to enable authorities to achieve their objectives. The current data set will certainly help to monitor the build-up of exposure within the financial system. Authorities will also be able to understand whether certain barriers to resolution exist (such as the absence of a contractual bail-in clause in a contract governed by a non-EU governing law). However, even the “Termination Right” data point will only cast limited light on the fundamental question of what it is to be resolvable as a financial institution – in terms of understanding the types of clause that create financial stability risk for individual firms and which can cause financial contagion across the system – and, in turn, how this issue can be most effectively addressed.
The problems caused by a lack of data are compounded by the fact that there is no requirement to keep a copy of documentation from which data has been extracted together with the actual data. In this sense, the obligation is to maintain metadata (data about data) but not data. This seems incongruous in light of the fact that the EBA are not specifying either the level of granularity or the form in which information is to be maintained, making clear that “if institutions are already recording the information they can continue to do so in accordance with their existing practices”. If the CFTC’s experience in relation to transaction reporting under the Dodd Frank Act is anything to go by, specificity and consistency in the form in which data is received is of critical importance. In order to control and mitigate the risks which will inevitably follow the failure of a systemically important financial institution, accurate and timely data is paramount. However, in practice, this need arises at just the same time that the underlying information is most difficult to obtain. In the absence of a centrally-held and comprehensive database, a copy of the actual contract agreed between relevant parties would seem an obvious and valuable tool in this regard.
In its response to the feedback received, the EBA seems to have made a genuine attempt to reduce the admin burden on firms as well as the overlap with other regulatory data initiatives such as transaction reporting under EMIR, MiFID II and the SFTR. Whilst this is to be applauded, it must be recognised that data capture under the BRRD is designed to achieve a very different objective to transaction reporting. Its purpose is to help authorities understand – at a very fundamental level – what it is to be resolvable as a financial institution. Achievement of this objective needs data – lots of data – consistently held in a manner which is instantly accessible in its entirety, even in circumstances where the firm itself has ceased operating in the normal sense of the word. Whilst undoubtedly expensive and burdensome for firms to implement, the prize – the creation of a tool which can help authorities to understand how the problem of ‘too big to fail’ can be addressed in practice – is a price worth paying. Let’s hope that that it does not take another financial crisis before authorities have the resolve to establish the necessary regulatory data environment.
Annex
|
|
Field |
Description of information to be maintained in detailed records of financial contracts |
Data Source |
|
|
Section 1 – Parties to the financial contract |
||
|
1 |
Record keeping timestamp |
Date and time of record entry |
System generated |
|
2 |
Type of ID of the reporting counterparty |
Type of the code used to identify the reporting counterparty |
Other internal system |
|
13 |
Reporting 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. |
Other internal system |
|
4 |
Type of ID of the other counterparty |
Type of the code used to identify the other counterparty |
Internal KYC system |
|
25 |
ID of the other counterparty |
Unique code (Legal Entity Identifier (LEI), where available) identifying the other counterparty of the financial 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 in a consistent manner. |
Internal KYC system |
|
36 |
Name of the reporting counterparty |
Corporate name of the reporting counterparty. This field can be left blank where LEI is used to identify the reporting counterparty the counterparty ID already contains this information |
Other internal system |
|
47 |
Domicile of the reporting counterparty |
Information on the registered office, consisting of full address, city and country of the reporting counterparty. This field can be left blank where LEI is used to identify the reporting counterparty the counterparty ID already contains this information |
Other internal system |
|
8 |
Country of the other Counterparty |
The code of the country where the registered office of the other counterparty is located or country of residence in case that the other counterparty is a natural person |
Internal KYC system |
|
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 the law governing law of the financial contract. |
Legal agreements database |
|
10 |
Contractual recognition – Write-down and conversion powers (only for contracts governed by third country law subject to the requirement of the contractual term under the first subparagraph of Article 55(1) of Directive 2014/59/EU third country governed contracts only) |
The contractual term required under Article 55(1) of the Directive 2014/59/EU
When such contractual term is included in a master agreement and applies to all trades governed by that master agreement, it can be recorded at the master agreement level.
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. |
Legal agreements database / Protocol data |
|
11 |
Contractual recognition – Suspension of termination rights (only for contracts governed by third country law) |
The contractual term by which the creditor or party to the agreement creating the liability recognises the power of the resolution authority of a Member State to suspend termination rights.
When such contractual term is included in a master agreement and applies to all trades governed by that master agreement, it can be recorded at the master agreement level. |
Legal agreements database / Protocol data |
|
1112 |
Contractual recognition – Resolution powers (only for contracts governed by third country law third country governed contracts only) |
The contractual term, if any, by which the creditor or party to the agreement creating the liability recognises the power of a Member State resolution authority to apply resolution powers other than those identified in field 10 and field 11.
When such contractual term, if any, is included in a master agreement and applies to all trades governed by that master agreement, it can be recorded at the master agreement level.
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. |
Legal agreements database / Protocol data |
|
1213 |
Financial contract relates to cCore business lines |
Identify which core business line or core business lines the financial contract it relates to, if any. |
Trade capture system |
|
1314 |
Value of contract |
Mark to market valuation of the financial contract, or mark to model valuation reported in application of [Article 3(5) and 3(6) of the Delegated Regulation on Article 9 where applicable under Article 11(2) of Regulation (EU) No 648/2012]. The CCP‘s valuation to be used for a cleared trade. |
Trade capture system |
|
1415 |
Currency of the value |
The currency used for the valuation of the financial contract |
Trade capture system |
|
1516 |
Valuation timestamp date |
Date and time of the last mark to market or mark to model valuation.
For mark-to-market valuation the date and time of publishing of reference prices shall be reported. |
Trade capture system |
|
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. |
Trade capture system |
|
18 |
Trade exposure |
As defined in Article 4(1)(91) of the Capital Requirements Regulation[21]. |
|
|
1918 |
Collateralisation |
Indicate whether a collateral agreement between the counterparties exists. Where financial contract is covered by the reporting requirement under [Delegated Regulation on Article 9 of Regulation (EU) No 648/2012] information on collateralisation shall be provided as required by these requirements. Whether collateralisation was performed. |
Legal agreements database |
|
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. |
|
|
2119 |
Collateral portfolio |
Indicate Wwhether 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. |
Collateral management system |
|
2220 |
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. |
Collateral management system |
|
2321 |
Initial margin posted |
Value of each of the instruments posted as initial margin posted by the reporting counterparty to the other counterparty.
Where initial margin is posted on a portfolio basis, this field should include the overall values of initial margin posted for the portfolio. |
Collateral management system |
|
22 |
Currency of the initial margin posted |
Specify the currency of the initial margin posted |
Collateral management system |
|
24 |
Initial margin received[22] |
Value of each of the instruments collected as initial margin by the reporting counterparty to the other counterparty. |
|
|
2523 |
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.
Where variation margin is posted on a portfolio basis, this field should include the overall value of variation margin posted for the portfolio. |
Collateral management system |
|
24 |
Currency of the variation margin posted |
Specify the currency of variation margin posted |
Collateral management system |
|
25 |
Initial margin received |
Value of initial margin received by the reporting counterparty from the other counterparty.
Where initial margin is received on a portfolio basis, this field should include the overall value of initial margin received for the portfolio. |
Collateral management system |
|
26 |
Currency of the initial margin received |
Specify the currency of the initial margin received. |
Collateral management system |
|
2627 |
Variation margin received collected |
Value of each of the instruments collected as variation margin received posted, including cash settled, by the reporting counterparty from the other counterparty.
Where variation margin is received on a portfolio basis, this field should include the overall value of variation margin received for the portfolio. |
Collateral management system |
|
28 |
Currency of the variation margin received |
Specify the currency of the variation margin received |
Collateral management system |
|
27 |
Currency of the collateral value |
Specify the value of the collateral for fields 23 to 27. |
|
|
|
Section 2a – Financial contract type |
||
|
2829 |
Type of the financial contract |
Classify the financial contract according to Article 2(100) of Directive 2014/59/EU 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). |
Other internal system / manual review |
|
30 |
Financial contract ID |
Unique trade ID where the financial contract is covered by the reporting requirements under [Delegated Regulation on Article 9 of Regulation (EU) No 648/2012]. For any other financial contract, ID assigned by the reporting counterparty. |
Trade capture system |
|
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 financial contract come into effect. |
Trade capture system |
|
32 |
Maturity date |
Original date of expiry of the reported financial contract. An early termination shall not be reported in this field. |
Trade capture system |
|
33 |
Termination date |
Termination date in the case of an early termination of the reported financial contract. If not different from maturity date, this field shall be left blank. |
Trade capture system |
|
34 |
Termination conditions |
Termination conditions of the reported contract, if different from maturity date. |
|
|
3534 |
Termination right |
Indicate Wwhether the other counterparty’s termination right under the reported financial contract is based solely on the insolvency or financial condition of the institution under resolution.
When such contractual term is included in a master agreement and applies to all trades governed by that master agreement it can be recorded at the master agreement level. |
Legal agreements database / confirmations |
|
3635 |
Master Agreement type |
Reference to the name of the relevant master agreement, if used for the reported financial contract (e.g. ISDA Master Agreement; Master Power Purchase and Sale Agreement; International ForEx Master Agreement; European Master Agreement or any local Master Agreements). |
Legal agreements database |
|
3736 |
Master Agreement version |
Reference to the year of the master agreement version used for the reported trade, if applicable (e.g. 1992, 2002, etc.). |
Legal agreements database |
|
3837 |
Netting agreement arrangement |
If the financial contract is a part of a netting arrangement as defined in Article 2(1)(98) of Directive 2014/59/EU, a unique reference of the netting arrangement Name of the netting arrangement governing the contract |
Legal agreements database |
|
38 |
Type of liability/claim |
Indicate whether liabilities arising from the financial contract are:
|
Legal Analysis |
|
|
Section 2c – Clearing |
||
|
39 |
Clearing obligation |
Indicate whether the reported financial contract belongs to a class of OTC derivatives that has been declared subject to the clearing obligation and both counterparties to the contract are subject to the clearing obligation under Regulation (EU) No 648/2012, as of the time of execution of the financial contract. |
Trade capture system |
|
3940 |
Cleared |
Indicates whether clearing has taken place. |
Trade capture system |
|
41 |
Clearing timestamp |
Time and date when clearing took place. |
Trade capture system |
|
42 |
CCP |
In the case of a financial contract that has been cleared, the unique code for the CCP that has cleared the financial contract. |
Trade capture system |
|
4043 |
Intragroup |
Indicates whether the financial contract was entered into as an intragroup transaction, defined in Article 3 of Regulation (EU) No 648/2012. |
Trade capture system |
|
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. |
|
[1] RTS, Article 1
[2] BRRD, Article 2(1)(100)
[3] BRRD, Article 71(1)
[4] Article 1
[5] Article 2 and the Annex
[6] Recital 1 and Article 2
[7] Article 2(2)
[8] Data point 34
[9] Data point 9
[10] Data point 27
[11] Data point 35
[12] Data point 36
[13] Data point 31
[14] Data point 32
[15] Data point 33
[16] Data point 8
[17] Data point 14
[18] Data points 19 to 28
[19] Data points 10-12
[20] Data point 38
[21] Regulation (EU) No 575/2013
[22] Essentially, this data point has been moved to data point 25, rather than deleted.
