Yes. We believe it is appropriate to make the obligation to maintain detailed records contingent upon whether the resolution plans for the relevant institution or the group resolution plans provide for resolution actions in relation to the institution in question.
However, we note that the range of the institutions covered is likely to change over time. It therefore has to be expected that some institutions which do not, as of now, fall within the scope of application, will become subject to the obligations in the future. In this case, the relevant institution will need to have an adequate transition period giving it sufficient time to implement the necessary processes and set up the required technical infrastructure to enable it to discharge its obligations.
In this context it should be pointed out that the expectation expressed under item 3 of the Consultation Paper in the background and rationale to Art. 3 (page 6), that the requirements under the future RTS will not increase the burdens for the institutions, is unrealistic: While it is of course true that institutions indeed already maintain records on their financial contracts and are subject to parallel (however not necessarily coordinated) reporting obligations in respect of financial contracts, most notably the obligation under EMIR to report derivative transactions to trade repositories in accordance with Delegated Regulation (EU) no. 148/2013 (TR-reporting obligation), the data reported differs to some extent of what has to be recorded for the purposes of the BRRD: It is precisely for this reason that it was considered necessary to introduce a new and separate obligation to record financial contract data rather than relying on existing records and reports (if existing reporting obligations would indeed provide all information required, there would not have been any need for a new requirement). In addition, even where the data to be recorded is generally consistent with data elements which are to be reported under the existing TR-reporting obligations, the specifications in the Annex differ to some extent from those applicable to the TR-reporting obligation (see response to Question 3). Moreover, current databases and data recording structures and processes established in view of existing regulatory requirements, in particular regarding risk management, have been established with a primary focus on the counterparties. However, the new financial contract data recording obligation has its focus on the position of the institutions and/or its group members. Consequently, this new perspective demanded by the financial contract data requirement forces the institutions to implement fundamental changes to existing data recording processes as well as the database and IT-structure. These changes will be challenging and time consuming. The institutions thus will need a phase-in or implementation period. Such a phase-in or implementation period would also permit a greater alignment with the upcoming revision of the TR reporting obligations and the new reporting obligations in relation to securities financing transactions.
Furthermore, we note with concern that the consultation paper assumes that institutions establish a single, central data base covering all financial contract data for the entire group on an ongoing basis. The establishment of such a single database may, however, not be possible in many cases, since financial contract data may be subject to many different privacy, banking secrecy and/or data protection requirements requiring the recording in separate. It should therefore be left to the institutions to decide how to technically implement the financial contract data recording obligation. Any technical set-up and database structure should be acceptable as long as the system or a multitude of systems combined enable the institution to provide the relevant data in the required timeframe. To avoid potential conflicts with applicable laws and regulations and also to avoid unnecessary burdens it should be clarified that the financial contract data recording obligation does not prescribe a certain database structure, in particular, not the establishment of one single, central database. Instead it could be considered to set out certain criteria which would need to be met by an institution’s database structure and system, which could include the following:
- Adequacy of the timeframe within the relevant financial contracts can be identified and reviewed. Ability to assess the relevancy of the financial contracts, and ability to identify all material terms of the financial contracts which have been identified as being of sufficient relevance.
- Establishment of adequate processes and systems permitting the identification and assessment of the relevant financial contracts upon request at short notice.
- For example, in the case of a group, one designated entity could act as a single point of entry with regards to any requests.
No comment (see above)
We largely agree with the list, however we believe that certain amendments are necessary to accomplish the central objective, namely the avoidance of unnecessary inconsistencies with existing reporting obligations in respect of financial transactions, in particular the TR-reporting obligation - taking into account the upcoming changes as proposed in the current review of the TR-reporting obligation, thereby enabling the institutions to rely on the same data set produced for this already existing reporting obligations wherever possible.
To this end, the following aspects would need to be reviewed, furthermore several descriptions of the information to be maintained should be clarified (see commented annex):
- Clear distinction between transaction level, counterparty level information and portfolio/master agreement level Information
The various data fields do not always distinguish clearly enough between data on a transaction level, counterparty level data and data on portfolio/ master agreement level. This may cause uncertainties and inconsistencies where an institution has entered into more than one master agreement in relation to a counterparty (see also response to question 6 below). Likewise, even where parties have entered into only one master agreement, the lack of such clear distinction (or clarification which data is to be provided on counterparty, portfolio/master agreement or transaction-level) could mean that the information required in relation to a “contract” which is identical for any transaction under the same master agreement (information to be entered into data fields 10 and 11) would have to be reproduced in respect of each transaction.
- Postponement of the extension of data recording requirement to security finance transactions until establishment of SFT-reporting requirements
We of course recognise that the financial contract data requirements addressed by the draft RTS are not limited to derivatives but also concern other financial contracts. However, in view of the fact that securities finance transactions (SFT) are about to become subject to a reporting requirement modelled after the TR-reporting requirement under EMIR, it should be considered to wait with any specifications regarding the data to be recorded on SFT until the relevant reporting requirements have been defined and established. Otherwise it is almost certain that there will be inconsistencies or even conflicts between the data recording requirements addressed by this draft RTS and the future SFT reporting requirements. This again underlines the need for an adequate implementation or phase-in period (see also response to Question 1)
- Information on contractual recognition clauses regarding bail-in/write-down - data field 10
The relevant information should be recorded on master agreement level and not on transaction or counterparty level since (i) transactions are regularly covered by a master agreement and (ii) institutions may have entered into more than one master agreement in relation to a certain counterparty. Transaction level information only makes sense where the transactions are entered into without being included into a master agreement.
- Information on contractual recognition clauses regarding resolution measures – data field 11
An obligation to agree on a contractual recognition clause currently only exists under Art. 55 BRRD and only in relation to bail- and write-down powers. This obligation is addressed in item 10.
Item 11 can be read to address a different and wider, more general contractual recognition clause covering all resolution measures. There is, however, no legal basis for such a wider, general recognition clause and consequently also no legal basis for an obligation to record data on such a clause. The data field is of course intended to address contractual recognition clauses concerning the recognition of a suspension of termination rights (resolution stays) as a consequence of resolution measures. To avoid any confusion, the type of clause to be captured, namely contractual clauses regarding the suspension of termination rights, would need to be specified more clearly. In addition, the comments on data field 10 regarding the need to provide this information on master agreement level, apply correspondingly.
- Information on core business relation - data field 12
It will not always be possible to identify a core business line for each counterparty. This is because institutions may offer a wider range of services to an institution across the various business lines.
- Information on collateralisation - data field 19
This data field may be redundant as the relevant information already follows from the subsequent data fields.
In addition the term “performed” may be confusing in this context. We assume that – in particular in the case of a portfolio or master agreement - this is intended to address information whether a collateral arrangement requiring posting or exchange of collateral in relation to the secured portfolio is in place and that there is no requirement to record each individual posting/exchange of collateral (we also refer to our earlier comment regarding the need for a clearer distinction between transaction and master agreement/portfolio-level information).
- Information on collateralisation composition etc. - data field 20 et seq.
Such detailed information on each individual asset serving as collateral should not be required considering that the key information is the overall value of the collateral. The data field should therefore be deleted (see also our comments regarding the valuation of individual instruments, comments on data fields 21 to 26).
It would at least need to be aligned with the structure of the revised TR-reporting requirements regarding collateral following the EMIR review.
- Information on collateralisation – data fields 21 to 26
The requirements regarding the data to be recorded on collateralisation in data fields 21 and 23 to 26 are inconsistent with existing parallel TR-reporting obligations and collateralisation practice and thus should be reviewed:
The relevant data fields currently would require institutions not only to list each individual instruments used as collateral but apparently also to value each of the listed instruments independently.
Such instrument specific valuation is incompatible with present collateralisation practice and, more importantly, produces unnecessary detailed data sets. The key information is the total value of collateral securing the portfolio. Consequently, the systems employed by institutions, do of course take into account each individual instruments used as collateral but only produce overall valuations. To break down the data for each instrument would therefore require considerable changes to existing systems and practices without resulting in better or more relevant information. This is also recognised by the parallel TR-reporting obligation which only demand a portfolio valuation.
Consequently, it should be entirely sufficient to identify the individual instruments in data field 20 and record the overall value of all collateral in a separate data field (under the present approach, data field 20 would also be redundant as each individual instruments would already be identified in the subsequent data fields).
- Method of Classification of the type of financial contracts – data field 28
Item 28 of the Annex currently distinguishes between the following five types of financial contracts:
a) securities contracts
b) commodities contracts
c) future and forward contract
d) swap agreement
e) inter-bank borrowing agreement
At least with regard to derivative transactions, this method for the classification conflicts with method set out in the proposal for a revised TR-reporting obligation submitted by ESMA in its Consultation Paper for the current review of the technical standards on reporting under Article 9 of EMIR. According to this proposal, a derivative contracts would be classified by contract type (distinguishing here between six sub-categories of contract types) and asset classes (distinguishing here between five types of asset classes), see Table 2, No. 66, item 1 and 2/ page 50 of the ESMA proposal.
In view of the fact that the material scope of the financial contract data recording obligation for the purposes of the BRRD also extends to financial contracts other than derivative transactions (subject to our above comments regarding the need to consider a postponement), it should be considered to reflect this by relying on a two level approach for the classification of the financial contract type:
On a primary level, a distinction would have to be made between
-derivative transactions which are already captured by EMIR reporting obligations
-security finance transactions, which are to be captured by the future regulatory measures on security finance transactions (SFT) and
-transactions which do not fall within any of the above categories but fall within the ambit of the definition of financial contract under Art. 2 (100) BRRD.
On a secondary level, the three categories could then be further distinguished and sub-categorised: In the first two instances, such further sub-categorisation should occur on the basis of the classification methodology applicable under EMIR (that is using the six contract types and the five asset classes as suggested in the ESMA proposal) and the future SFT, respectively.
- Transaction information - data field 31
Where transactions are entered into under master agreements, it would be more appropriate to record master agreement level data. This would also better reflect the fact that master agreements are protected by safeguards and that resolution measures will be taken on master agreement level. Consequently, transaction level information is of no practical relevance and may actually be misleading.
- Information on termination conditions and termination right - data fields 34 and 35
The difference between termination conditions to be addressed in data filed 34 and termination rights to be addressed in data field 35 may not be sufficiently clear in all circumstances.
In addition, we refer to our pervious comments on the need to clearly distinguish between transaction level and master agreement/portfolio level (see above): For example, termination rights (or early automatic termination clauses) triggered by an event of a default (in particular insolvency) generally apply on master agreement level and not on transaction level.
- Information on Master Agreement type - data field 36
We refer to our pervious comments on the need to clearly distinguish between transaction level and master agreement/portfolio level (see above). This may entail the need to include a new section covering master agreement level information.
- Information on Master Agreement version - data field 36
Not all standard master agreement have different versions identified by a certain year as it is custom in the case of the ISDA Master Agreements. We therefore would assume that such information on the version is only needed where the relevant type of master agreement used is generally identified by such a reference to a year.
- Information on netting arrangement - data field 37
It is unclear what information is to be provided in this data filed as the master agreement (which is or contains a netting arrangement) is already identified in the previous data fields 36 and 37. The data field is thus redundant and can be deleted.
- Information on netting agreement - data field 38
The meaning of netting arrangement may be misleading in this context, in particular in contrast to the term master agreement used in the previous data field 37. In particular, it is not entirely clear what information is to be provided other than specifying whether and what a master agreement has been entered into (which is already covered by data field 37). If this data field intends to capture so called master-master netting agreements which cover different master agreements entered with a certain counterparty, this should be clarified to avoid confusion.
- Information on Type of liability/claim - data field 41
The relevant data field apparently intends to require the addressees to identify whether a certain liability is exempted from a bail in under Art. 44 (2) (b) BRRD for qualifying as “secured liability”. This may be difficult to determine in advance, in particular considering the fact that the draft RTS currently under consultation intended to clarify this issue propose a very narrow reading of “secured liability”. It should therefore be considered to delete this data field.
- Information on value of liability/claim - data field 42
Because of the use of the word “including” it is unclear whether the relevant data field is intended to address the net value (where netting agreements are in place) or the net value and the gross value. Of course, the only relevant information is the net value. We therefore suggest a clarification to this effect.
- Minor corrections/clarifications – data fields 21 to 39
-Data filed 24: “to” should be replaced by “from”
-Data filed 25: “posted” after “variation margin” should be deleted
-Data field 26: “posted” should be deleted
-Data field 27: “27” would need to be replaced by “26”. Furthermore, as the current description may cause misunderstandings, it should also be considered to clarify which specific type of information is to be entered in this field: information on the currencies in which collateral is denominated or valued in on the one hand, or the total value of all collateral and the currency used for this purpose on the other hand.
-“Section 2d – Clearing” would need to be renamed into “Section 2c - Clearing)
See comments on question 3 above.
In principle, yes. However, we refer to our above comments on question 3 regarding deviations from the requirements regarding the TR-reporting obligation which result in unreasonable burdens and may ultimately produce confusing data. In this context it will need to be taken into account that the financial contract data recording obligation has a different perspective (the institution/group itself and its resolvability) than the data reporting requirements under EMIR and the SFT which are intended to increase market transparency.
As we strongly support the approach to align the data recording obligation addressed in this draft RTS as closely as possible to the TR-reporting obligation, we would support an identical differentiation between counterparty data and transactions data elements as applicable for the purposes of the TR-reporting obligation. However, as already pointed out above, it will also be necessary to differentiate between master agreement-level information on the one hand and counterparty or transaction-level information on the other, where appropriate and relevant (again because of the different perspective taken by the financial contract data recording obligation, see above).