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, 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)
2. If the answer is no. What alternative trigger could be used?
No comment (see above)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 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)