Response to consultation on Regulatory Technical Standards on detailed records of financial contracts
Go back
To this end, the following aspects would need to be reviewed and considered:
Postponement of the data record keeping requirement for securities financing transactions until the establishment of SFT-reporting requirements.
In view of the fact that securities financing transactions (SFT) are about to become subject to a reporting requirement modelled after the TR-reporting requirement under EMIR, the EBA should wait 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 and resolution measures- data field 10 and 11 – The information most relevant to the resolution authority will be at portfolio level, rather than at transaction level. Only where there is no master agreement should the resolution authority asks for information at transaction level.
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 apparently intends to address a different and wider, more general contractual recognition clause covering other 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 11 should therefore be deleted.
If such data field is, however, retained, at least the type of clause it intends to cover would need to be specified more clearly: Presumably, the data field under item 11 intends to address contractual recognition clauses concerning the recognition of a suspension of termination rights as a consequence of resolution measures. If this is indeed the case, this should be clarified accordingly. In addition, we refer to our comments on data field 10 regarding the need to record this information on master agreement level.
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, 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.
Also the EBF noted that the template on financial contracts is written with derivatives and SFTs in mind. The direct consequence is that the other types of contracts such as outright sales, purchases of securities and commodities, lending and deposits between financial institutions, are not fitting with that specific format.
The need for a very detailed amount of information on these contracts is not as relevant as for the two other types in a resolution situation. For example: outright sales and purchases of securities typically have a short lifetime, typically only the few days between the initiation and the settlement. In a similar way, a lot of interbank lending has other characteristics than the type of transactions that is the main focus of the regulation. These transactions are often simple payments to tor from an account, where the important information is related to the net balance between the parties, rather than transaction by transaction information.
Therefore, it would make sense to have a simplified format for these specific types of contracts.
This could both lead to provide a more useful set of information in a resolution situation for resolution authorities, but also to reduce significantly the burden for banks.
Information on collateralisation – data fields 21 to 26
In the case of transactions entered into under a master agreement, collateralisation will occur on a master agreement/portfolio level and not on transaction level. This needs to be reflected in all of the data fields concerning collateralisation (see also our response to Q6)
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.
It should therefore 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).
Minor corrections/clarifications – data fields 21 to 27
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 can 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 recorded 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.
In addition, 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 a differentiation between counterparty data and transactions data elements as applicable for the purposes of the TR-reporting obligation.
2. If the answer is no. What alternative trigger could be used?
No comment.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?
We largely agree with the list, however we believe that certain amendments are necessary to avoid 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 and considered:
Postponement of the data record keeping requirement for securities financing transactions until the establishment of SFT-reporting requirements.
In view of the fact that securities financing transactions (SFT) are about to become subject to a reporting requirement modelled after the TR-reporting requirement under EMIR, the EBA should wait 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 and resolution measures- data field 10 and 11 – The information most relevant to the resolution authority will be at portfolio level, rather than at transaction level. Only where there is no master agreement should the resolution authority asks for information at transaction level.
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 apparently intends to address a different and wider, more general contractual recognition clause covering other 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 11 should therefore be deleted.
If such data field is, however, retained, at least the type of clause it intends to cover would need to be specified more clearly: Presumably, the data field under item 11 intends to address contractual recognition clauses concerning the recognition of a suspension of termination rights as a consequence of resolution measures. If this is indeed the case, this should be clarified accordingly. In addition, we refer to our comments on data field 10 regarding the need to record this information on master agreement level.
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, 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.
Also the EBF noted that the template on financial contracts is written with derivatives and SFTs in mind. The direct consequence is that the other types of contracts such as outright sales, purchases of securities and commodities, lending and deposits between financial institutions, are not fitting with that specific format.
The need for a very detailed amount of information on these contracts is not as relevant as for the two other types in a resolution situation. For example: outright sales and purchases of securities typically have a short lifetime, typically only the few days between the initiation and the settlement. In a similar way, a lot of interbank lending has other characteristics than the type of transactions that is the main focus of the regulation. These transactions are often simple payments to tor from an account, where the important information is related to the net balance between the parties, rather than transaction by transaction information.
Therefore, it would make sense to have a simplified format for these specific types of contracts.
This could both lead to provide a more useful set of information in a resolution situation for resolution authorities, but also to reduce significantly the burden for banks.
Information on collateralisation – data fields 21 to 26
In the case of transactions entered into under a master agreement, collateralisation will occur on a master agreement/portfolio level and not on transaction level. This needs to be reflected in all of the data fields concerning collateralisation (see also our response to Q6)
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.
It should therefore 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).
Minor corrections/clarifications – data fields 21 to 27
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 can 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 recorded 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.
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?
See comments on question 3 above.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?
In principle, yes. However, we refer to our above comments on question 3 regarding unnecessary deviations from the requirements regarding the TR-reporting obligation.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?
As already mentioned in some of the previous responses, it will not only be necessary to distinguish between counterparty and trade/transaction level but also between master agreement/portfolio and transaction level. This needs to be addressed in all data fields concerning transactions which are entered into under a master agreement.In addition, 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 a differentiation between counterparty data and transactions data elements as applicable for the purposes of the TR-reporting obligation.