Response to consultation on Regulatory Technical Standards on detailed records of financial contracts

Go back

2. If the answer is no. What alternative trigger could be used?

N/A

3. Do you agree with the list of information set out in the Annex to the draft RTS which it is proposed shall be required to be maintained in the detailed records?

Specific comment on Recital 6. referring to a “central relational database”:

In Recital 6 of the RTS, the EBA states that “information should be kept in a central location on a relational database e.g. capable of being interrogated by the authorities and from which information can be provided easily to the authorities”. However, the Bank Recovery and Resolution Directive (BRRD) and the EBA’s RTS itself do not refer to a specific technology.

Indeed, for the resolution authority, the important element is to obtain the necessary information in financial contracts in the right format and in a reasonable amount of time in the event of a bank’s resolution. It should be left to institutions to decide which technological solution best meets this requirement as long as they can demonstrate that the system chosen will enable for all the relevant data to be provided in the required timeframe.

A central database would create challenges from both a practical/technical and legal perspective:

• Generally, firms have different systems to store ‘static’ information related to financial contracts (e.g. parties to the relevant master agreement under which single contracts are concluded, other master agreement details) and ‘dynamic’ or position-based information related to valuation and collateral. In order to ensure the timeliness and accuracy of data, there is an advantage of retaining it in systems whose functionality is closely aligned with the markets, processes and positions under review. We do not consider that a central database would be desirable. Indeed, by replicating the ‘dynamic’ data that is in the trading systems in a central database, there is a risk that data quality might be lost. In addition, ‘unified’ databases are not the best tools for preserving and searching variegated data (e.g. combining documents and spreadsheets in a single tool). We recommend that the various data be kept in its original databases – as long as firms can extract and interrogate the information on the authority’s request.

• It is also the case that an attempt to transfer data into a central database within a banking group would meet legal obstacles in third countries. Any data in connection with private individuals is usually protected by data protection laws. The group wide centralisation of documentation management would inevitably request the storage, processing and access to data containing confidential information by a different legal entity (the parent company) to the document owner (e.g. the subsidiary); this could breach local data protection legislation. For example, under data protection law in Singapore, institutions would need prior consent from clients before transferring data to a central database. Moreover, some countries have national banking secrecy rules with which global banking groups are required to comply. Finally, any contract management and storage activity by a group member would be considered as outsourcing service which is also subject to limitations or even prohibitions in some jurisdictions. The resolution authority could achieve the same results without imposing a central database, which would avoid these legal obstacles.

The EBA considers that the draft RTS “do not introduce an additional reporting burden and just require the information to be maintained”. If a central database was to be required, then it would in practical terms create an additional reporting burden, but with limited benefits given that the resolution authority could reach the same objectives without imposing a specific type of technology. We therefore recommend that the EBA replaces recital 6 with the following sentence: “It should be left to institutions to decide which technological solution they choose, as long as they can demonstrate to the satisfaction of the resolution authority that the system chosen enables the bank to provide the relevant analyses in the required timeframe”.

Comments on the list of information set out in the annex:

Overall we agree with the list of information required in the Annex of the draft RTS, however we do have some comments on specific fields which are set out below. The information required in the context of Article 71 (7) of the BRRD serves a different purpose than the data reported under EMIR or the Securities Financing Transactions Regulation (SFTR). Therefore, some fields need to be slightly amended to ensure that the information kept in detailed records is useful to authorities in the context of resolution.
• Field 10 (contractual recognition - Write down and conversion) - The RTS should refer either to master agreements or to transaction or counterparty level information. In most cases, transactions are covered by a master agreement; firms may even have entered into more than one master agreement with counterparty. The master agreement level information will then be the most relevant for the resolution authority. Where there is no master agreement, then the bail-in clause information on the single transaction level will be relevant – but we would expect this to be a minority of cases.
• Field 11 (contractual information – Resolution) – We consider that this will also be information more relevant at a master agreement level.
• Field 12 (core business lines) – It is difficult to allocate master agreements to a specific business line given that firms provide several types of services to clients, across various business lines. The EBA should specify that this field can be left empty if a clear allocation is not possible. Alternatively, several entries should be possible.
More importantly, the fields in the annex should cover how the contract relates to critical economic functions.
• Field 18 (trade exposure) – Field 18 seems to refer to mark-to-market, therefore, it is not clear what the difference is with field 13 (value mark-to-market).
• Field 20 - 22 (on collateral) – With this requirement, the EBA risks pre-empting changes in the European Market Infrastructure Regulation (EMIR) reporting matrix currently being finalised by the European Securities and Markets Authority (ESMA). As highlighted by the EBA during the “public hearing on financial contracts” which took place on the 8th of May 2015, it is important to ensure that the final draft RTS on record keeping are aligned with the final ESMA guidelines, both in terms of data requirements, but also timing of implementation.
• Field 20 (composition of collateral) – This is reported under EMIR, but at portfolio level only, therefore if the portfolio contains multiple asset types these would not be reported separately. It would be difficult to tie collateral to a specific transaction. What is important is the total value of collateral securing the portfolio.
• Field 23-24 (initial margin) – We believe that for resolution purposes, the resolution authority will need information at portfolio/master agreement level, rather than information on the value of each instrument posted or collected as initial margin. It is not clear to us that this level of granularity will be useful to the authority.
• Section 2b (details on the transaction) – In this section, we believe that some fields should refer to the master agreement as opposed to the transaction.
• Field 34 (termination conditions) – We would welcome some clarification on what termination conditions specifically means.
• Field 35 (termination rights) – The EBA should clarify that this refers to the counterparty’s rights.
• Field 38 (name of the netting arrangement governing the contract) – This field would need to be clarified as the current drafting fails to reflect the nuances that exist in practice. Indeed, there are different types of situations: 1) some trades are not covered by a master agreement; 2) some are covered by a master agreement (e.g. International Swaps and Derivatives Association – ISDA - Master Agreement) in which case it could useful to provide the authority with an identifier rather than the name of the agreement which would not state which trade falls under the arrangement; 3) some master agreements are combined into a ‘super-netting’ set (e.g. Cross Product Master Agreement). With the current wording, it is unclear which level the EBA is referring to.
• Field 41 (type of liability, claim – whether it is an eligible liability or a secured liability) – The EBA should clarify that the term “eligible liabilities” refers to liabilities eligible for bail-in and “ secured liabilities” refers to liabilities excluded from bail-in.
The fact that field 41 is under the heading ‘cleared trade’ is slightly confusing. Indeed, it is difficult to see how cleared trades could be considered as eligible liabilities for bail-in in practice. The specificities of cleared trade are recognized by the EBA in its draft RTS on valuation of derivatives.
• Field 42 (value of liability, claim) – We would welcome further clarification on this field.

4. If the answer is no. What alternative approach could be used to define the circumstances in which the requirement should be imposed in order to ensure proportionality relative to the aim pursued?

In the event of resolution, the authority would need to know whether a contract relates to a critical economic function previously identified by the institution. This would be at least as relevant to the resolution authority as the relation to a core business line (field 12).

5. Do you agree that in the Annex to the draft RTS the same structure as in Commission’s delegated regulation (EU) no 148/2013 should be kept?

We welcome the EBA’s effort to ensure alignment with existing EMIR requirements in order to avoid placing overlapping requirements on institutions. We also support the EBA’s intention to align the final draft RTS with the future changes to the EMIR reporting rules currently being considered by ESMA.

While most of the data stipulated in the draft RTS should already be available concerning derivatives due to the EMIR requirements, the EBA’s proposed requirements include additional information for the purpose of resolution. This new scope would require significant changes to Information Technology (IT) infrastructure and therefore a sufficient implementation period – at least 12 months - is needed before it can be fully operational.

Furthermore, the scope of the draft RTS goes beyond than just derivatives contracts and includes other types of contracts - such as securities financing transactions (SFTs) - which are not in scope of EMIR reporting.

The proposal for a regulation 2014/0017 on reporting and transparency of securities financing transactions (SFTR) contains reporting requirements for SFTs under Article 4, which closely mirror EMIR reporting requirements. When finalised ESMA will be mandated to prepare draft RTS and would have 12 months after the final adoption of SFTR to complete its work under the Council’s General Approach and the European Parliament Economic and Monetary Affairs (ECON) committee’s report. Given that SFTR is currently under negotiation, the ESMA RTS is not expected to be finalised before the second half of 2016 or early 2017. The reporting will then start later (six months for financials and 12 months for non-financials under the ECON report; 12 months for financials and 24 months for non financials under the Council General Approach). The proposal is being drafted in this fashion to provide sufficient time to market participants to prepare for the start of the SFTR reporting requirements. We are concerned that the EBA RTS on record keeping of financial contract would pre-empt the development of the SFTR reporting requirements and also provide insufficient time for market participants to put the necessary systems in place.

There is also some overlap between the proposed RTS and the European Central Bank (ECB) regulation (EU No 1333/2014) published in November 2014 on Money Market Statistical Reporting in terms of product scope and reporting requirements. The first official reporting will start in July 2016. Again, there is a risk that the EBA RTS on record keeping is inconsistent with the ECB requirements and could also create challenges for banks who have been working to the ECB’s timetable.

Consistency between the different requirements and their implementation timetable is required. Specifically, a phase-in approach could be used with regards to financial contracts that will be covered by legislation not expected to be in force by the time the EBA RTS is finalised.

6. Considering the question above do you think it would be possible and helpful to define expressly in the RTS which data points should be collected at a “per trade” level, and which should be collected at a “per counterparty” level?

Rather than looking at “per trade” and “per counterparty” levels, we recommend distinguishing between portfolio/master agreement level and transaction level. Indeed, resolution measures will need to respect the netting set and therefore some information is more relevant at master agreement level (e.g. fields 10 and 11). Furthermore, to the extent bail-in may become an option for an unsecured part of a given portfolio, the netting and collateral safeguards under the BRRD should be properly reflected, otherwise, there is a risk of reporting bail-in amounts on a gross basis where the actual amounts are net.

Upload files

Name of organisation

Deutsche Bank