EBF response to the ESMA Consultation Paper on the review ... · on reporting under Article 9 of...

European Banking Federation aisbl - 56 Avenue des Arts, B-1000 Brussels

Phone: +32 (0)2 508 37 11 – Website: www.ebf-fbe.eu

Ref.:EBF_012589G

Brussels, 12 February 2015

Launched in 1960, the European Banking Federation is the voice of the European banking sector from the

European Union and European Free Trade Association countries. The EBF represents the interests of some 4,500

banks, large and small, wholesale and retail, local and cross-border financial institutions. Together, these

banks account for over 80% of the total assets and deposits and some 80% of all bank loans in the EU alone.

EBF response to the ESMA Consultation Paper on the review of the technical standards

on reporting under Article 9 of EMIR

Key Points

Generally any attempt to enhance and improve the EMIR reporting is positive and we welcome the

review of the technical standards on reporting under Article 9 of EMIR. However, the review is not

thorough enough to enhance and improve the reporting. In order to improve the reporting there needs

to be a more in depth analysis of the technical problems, in which the industry should be involved, and

solutions/amendments should be based on this analysis.

Any changes made in the reporting obligation have an impact on the industry. Every time a change is

made the industry needs time and money to make the changes to their systems and implement these

changes. Therefore it would be preferable to have an analysis and amend the technical standards

accordingly as this would minimise the number of times the industry would have to make these

changes. A balance should be struck between stabilising the reporting and improving or developing it.

At the moment for EBF members the balance still is in favour of stabilising the report.

As a way of both improving the quality of data, in addition to removing the onerous burden of reporting

from lesser sophisticated parties, we would recommend that ESMA give consideration to relieving the

reporting obligation from both parties and instead have a Single Reporting Party, consistent with other

G20 countries. As a whole, the proposals in the consultation paper contain good clarifications where

existing points are amended. The introduction of completely new fields will cause extra burden on

companies that have been working hard to cope with the current obligation and to improve the quality.

Therefore we question the need to add on new fields to an already complex structure.

In any case with the changes proposed in this consultation ESMA should allow sufficient time, in order

to ensure that all Reporting Parties, Trade Repositories and Market Infrastructure have sufficient time

to both implement and fully test any new code or process changes that may be required. Furthermore,

we would like to highlight the importance to avoid any double reporting requirements. The ECB has

recently published a Regulation on Money Market Statistical Reporting (MMSR), which includes daily

transaction reporting on FX swaps and overnight index swaps. This data could be derived from EMIR

data. We encourage ESMA to align its reporting requirements with those of the ECB. Currently the

attributes are very similar, but slightly different definitions are being used. This is very difficult for the

banking industry since the data will be derived from the same sources. Attributes should be made

http://www.ebf-fbe.eu/



identical. Furthermore, we hope that the ECB and ESMA will work together, and also with the banking

industry, to find a workable solution to re-use EMIR data for ECB purposes.

Comments to the amendments to no 148/2013 (Article 1, 1)

EBF members agree that contracts cleared on the day of execution should be reported in cleared form.

However, this should not only be possible for contracts concluded on a trading venue, but for all

contract. Otherwise, it would be very difficult to adhere to the reporting obligation of T+1.




Q1: Do you envisage any difficulties with removing the ‘other’ category from derivative class and

type descriptions in Articles 4(3)(a) and 4(3)(b) of ITS 1247/2012? If so, what additional derivative

class(es) and type(s) would need to be included? Please elaborate.

The majority of derivative contracts are associated with only one category, in both class and type. Even

contracts that can be associated with two different categories there is usually one dominant category,

that can be used to report the transaction.

However removing the “other” category will not change the fact that there still exist contracts which

cannot be assigned to a single category. It is a general challenge that counterparties have different

ways to categorise derivatives. The “other” category is appropriate for tailor-made products, the EBF

therefore believes that the deletion of this category will not increase the quality of the categorisation

process.

The “other” category does have sense at the level of the derivatives type – there are a number of

derivatives (e.g. Bermudian swaps – autocallable swaps) that are hard to classify in the existing list.

Whilst we are awaiting global consensus on the UPI (from BCBS/IOSCO) we would welcome the

maintenance of the “other” category as a stand-by.

If the "other" category is removed, counterparties will face the difficulty that it will be compulsory to

agree on a single category, even when all of the possible categories are well arguable – thus either

differences in reporting should be accepted (because a truthful report will have been prepared and

submitted) or there should be commonly agreed guidelines on a common process which gives

guidance on how to report derivatives.

ESMA should consider the real benefit of removing the category against the unintended consequences

of increasing the potential for incorrect classification by the two parties. In certain circumstances, such

as structured/exotic or “hybrid” transactions “other” is actually the correct classification. On the same

issue, we assume that the portion of “other” is presumably a small percentage, so the

regulators/industry should not invest too much time and effort into ironing out each detail. In our view,

the original target was to achieve transparency regarding levels of exposure per product class/group

rather than to build up a (confirmation) matching platform.

Also, if the “other” category is removed we believe that additional derivative classes should be

introduced either specified in this reporting line or with a globally endorsed and accepted standards.

At the very least, we consider that at least “Hybrid”, "Bond" and "Index" must be globally accepted

universal categories.

Additionally, it is relevant to consider that members use the means facilitated by the registered TRs

when providing the information required by the RTS and ITS.

Those means should be aligned to the requirements laid down in those rules to allow market

participants to meet all their regulatory obligations. ESMA addressed the issue in the EMIR Q&A TR

Question 21 paragraph 4, however firms encounter issues to map the product classification required

by the rules with the taxonomies used in the TR means. Consequently, we propose that the means

provided by the TRs are regulated.




Q2: Do you think the clarifications introduced in this section adequately reflect the derivatives

market and will help improve the data quality of reports? Will the proposed changes cause

significant new difficulties? Please elaborate.

With respect to paragraph 17, we welcome the suggested terms (“reporting counterparty” and “other

counterparty) and believe these changes will improve the clarity of the data reports.

Paragraph 22 will have the consequence that participants are required to import and use CCP

settlement prices in pricing cleared trades, this would have a significant impact on participants’ internal

procedures. The greatest problem with this will be the availability of the necessary data to

counterparties. This will be especially true for counterparties who are not direct clearing members.

Therefore the standard should explicitly contain an obligation for all CCPs to supply this data free of

charge and unconditionally. The EBF also believes that the data should be provided for the

Counterparty to fulfil its value reporting obligation.

There are also products (like FX swaps or forward – or float/float swaps) where neither the concept of

payer/receiver or buyer/seller is relevant, leaving this field blank may be the best option for those

trades.

The wording of Article 3a in respect of Table 1 Field 13 does not consider all possible scenarios e.g.

interest rate swaps (float/float) where a buyer/seller model is not appropriate.

There should be reasonable consistency between the valuations of the buyer/payer and the

seller/receiver. We propose that the definition of the valuation to be provided should be the “fair value

for OTC derivatives in accordance with international accounting principles.” We are also concerned

that these proposals have been made with the intention to use market value for matching purposes.

Paragraph 24 of the consultation indicates that this field should remain static, presumably for the

purpose of harmonisation and matching purposes, but this field will vary as the contracts are valued

mark to market or mark to model for the purpose of calculating variation margin. We do not believe

market value should be used for reconciliation purposes.

Q3: What difficulties do you anticipate with the approaches for the population of the mark to market

valuation described in paragraphs 21 or 19 respectively? Please elaborate and specify for each type

of contract what would be the most practical and industry consistent way to populate this field in

line with either of the approaches set out in paragraphs 21 and 23.

Reporting of mark-to-market valuation on cleared swaps would cause problems for especially smaller

counterparties. For an indirect member of a CCP it can be a challenge to receive and report these

valuations. It would be a great challenge for smaller counterparties and buy side users to get brokers

and CCPs to deliver these values to their clients. Additionally the benefits of such detailed and

demanding reporting process is not very clear to us at present.

EBF members have some concerns regarding the approach proposed under the second bullet point of

paragraph 21 and the relevance of the information presented.

Actual Replacement cost is hard to estimate because different counterparties charge different XVA

(value adjustment for counterparty credit risk and funding of collateral). Furthermore, XVA for a set of

trades (i.e. netting set) aren't necessary equal to the sum of XVAs for each trade on a standalone base.

A clarification of which XVAs to include and what assumption to make would be appreciated.




It will be challenging to report “CCP calculated” values on derivatives within T + 1. The technical

standards should allow for reporting the counterparty’s own calculated market values on a daily basis.

Q4: Do you think the adaptations illustrated in this section adequately reflect the derivatives market

and will help improve the data quality of reports? Will the proposed changes cause significant new

difficulties? Please elaborate.

The EBF understands the reasons behind many of the adaptions proposed here, yet we do not believe

that the data quality will be significantly improved from the amendments introduced, as many parts

of this regulation need more strong and clear improvements as opposed to the incremental changes

here. We do not necessarily believe that these changes will dramatically improve the reporting

management and quality, but they may contribute to it by helping market participants to align

practices.

The most pressing factors to strongly improve reporting quality are common definitions of UTI and UPI

as well as clear rules governing their use.

Concerning quality then it is vital that the definition of a derivative is clearly stated and commonly

accepted in the EU as a prerequisite.

EBF members welcomes the ability to include an action type 'Z' that will allow the reporting of new

and compressed positions for ETDs in a single submission.

However, we wish to raise our concern under paragraph 29 in respect of the updated rule requiring

the mandatory use of ISO 17442 Legal Entity Identifier and the removal of the option of using other

identifiers such as BICs. The premature removal of the BIC reporting option will adversely impact the

reporting identifiers for non-EEA counterparties. ESMA should provide clarification on what identifier

should be used where national identifiers and LEIs are not available, this includes Table 1- Field 9 –

Broker ID, Table 1 Field 11 Clearing Member ID and Table 2 – Field 38 CCP. Where counterparties do

not have a reporting obligation under EMIR there is no mandate to require the counterparty to obtain

this, e.g. for Asian corporates. For non-EEA counterparties we would request the continued use of an

alternative identifier including BIC. Moreover, we recommend that a provision is added on how to

address legacy trades for the purposes of obtaining an LEI, i.e. the implications of trading with

counterparties who haven’t provided the firm with an LEI by the time these rules are final.

Additionally, it is not clear how to populate fields 3 and 4 of Table 2 – Common Data, when neither a

CFI code nor an endorsed UPI code are used. We recommend the possibility of leaving those fields

blank.

The Report Tracking Number adds complexity to the reports. Consequently we recommend that

number (or the TRN) not be in included in the reports.

Counterparties could have different agreements on how to report with different counterparties, and

would need their IT–systems to support this. However this is not likely to happen, and because of this

problem we foresee that there will continue to be a low reconciliation rate for a long time to come.




Regarding paragraph 28, a time interval (timestamp), perceived as acceptable, may be defined in such

fields, to reduce reconciliation issues, since some of the differences arise in the reporting done by both

parties, due to deviations of minutes, or even seconds, in the data reported.

Concerning paragraph 29, further elaboration from ESMA would be useful. It is not clear what to do

with trades executed with clients who do not have a LEI yet. Will trading with entities without an LEI

suddenly become prohibited? Not all counterparties have adopted a LEI code for reporting. For a bank

and if under a client relationship it is impossible to force a client to buy a LEI code when the trade is

booked before the reporting start date. Deleting interim identifiers and other client codes will only

make it impossible to report the counterparty to certain trades, as this is the only way to identify them.

A significant number of small enterprises are still not aware of the mandatory nature of EMIR

reporting, and even less aware of the need of obtaining and updating the LEI (Legal Entity Identifier),

which implies a financial cost (to enterprises that, in general, do not transact more than ten financial

derivatives contracts per year). To address this issue, and if LEI is the only identifier allowed, we believe

that an exemption of the costs associated with the abovementioned identifier should be considered

regarding NFC-. This is in line with the Article 3 of the Amendments to Commission Implementing

Regulation (EU) No 1247/2012, which introduces an exception to entities not eligible to obtain a Legal

Entity Identifier (for instance, broking entities), allowing them to use a unique national identification

code. Thus, we believe that NFC- should be under the same criteria. It is also worth mentioning that

many Member States do not have LOUs (Local Operating Units), which represents an additional

difficulty for small companies with reduced derivatives contracts volume to obtain a LEI. We would

also like to point out, that the identification via client code should still be allowed as long as the client

can ultimately be uniquely identified. Firms who have a private client based would be impacted by the

proposal to enforce the use of “national IDs” for individuals. MiFIR/ MiFID II is proposing a similar point.

There has been much debate on what a valid national ID is and if the ID type should also be reported

(i.e. Passport ID/National Insurance ID) or how to deal with ID number changes during the lifetime of

the transaction. There is also nothing within the paper to clarify how to report domicile for individuals

residing in multiple locations.

Per paragraph 33, it should be noted that if the LEI code is used to identify the counterparty, it should

not be necessary to identify the country, since this information is already included in the LEI. However,

if the LEI is not used, the country of the counterparty should be reported.

Concerning paragraph 34, we see challenges when client transactions are novated from one

counterparty to another seen from a bank perspective. Obtaining the original notional would be

difficult, specifically in Equity based products, and further difficulty when lifecycle events are factored

in as the original value is not stored. The transaction will be booked with the actual notional when

novated and the original notional will not always be known to transferee. The EBF therefore propose

a field named “Current Active Notional”, and would support further discussion with the regulatory

community to determine appropriate definitions in due course.

Concerning paragraph 36, the “report tracking number” has big operational consequences. There are

big operational challenges with the exchange of the UTI and many big banks are not able to generate

the UTI even though it is part of the contract that they should provide the UTI. Therefore adding the

exchange of a RTN code will only delay the time when the EMIR reporting is working as intended. At

the same time this connection between client and counterparties transactions in the systems causes a

major impact on firms which also would have to be maintained for existing trades if introduced. EBF

members feel that usage has not been clearly articulated. Placing this in table two makes it extremely




difficult, and it would be beneficial to move this to table one. A vertical ID should be added to tie in

multiple legs

Concerning paragraph 38, we agree that this kind of information should be subject to a common

format, applicable to all parties. The ESMA consultation should reference fields 36, 37 and 38.

Concerning paragraph 39, the clarifications regarding “action type” are unclear. It is difficult to

interpret the correct definition and use of the various options. The document gives an example of a

termination, and this explanation shows the exact amount of difficulty and consideration the codes

behind the reports. There is uncertainty how to use different codes and therefore ESMA should be

very specific when defining all the action types.

We believe that further clarification is needed regarding paragraph 39 and 40, considering that the

option “cancel” suggests that the transaction was either incorrectly reported or did not take place.

Therefore, an option different from “cancel” should exist for transactions that have already reached

maturity.

With respect to options, the following items should be clarified:

(i) The maturity date does not represent a life cycle event, and thus should not be reported,

considering that this information is included in the initial report.

(ii) Considering that this possibility is stated in the initial report, should the exercise of

American/Bermudan option before the maturity date, be considered a life cycle event subject to

report? Further clarity is required on what is reportable.

Regarding paragraph 41 and the introduction of a system for correcting false data inputs we have to

state that the existing cancellation and resubmitting system is inherently implemented in many IT-

systems. It is thus a very natural way of correction and we argue for the option to let this system coexist

with the new approach.

Q5: Do you think the introduction of new values and fields adequately reflect the derivatives market

and will help improve the data quality of reports? Will the proposed changes cause significant new

difficulties? Please elaborate.

Yes. In particular, we consider that the introduction of the field “Underlying ID Type” in paragraph 49

will improve the quality of the information concerning credit derivatives.

In respect of paragraphs 52 to 54 on the value of collateral, further breakdown of this data would pose

a significant problem for ETDs without further clarifications/definitions from ESMA on clarifying exactly

what is meant by posted/received, and breaking out initial margin from variation margin could

potentially mean changing the whole book keeping process.

Concerning paragraph 55, this reflects the use already widely adopted by participants. Some

transactions require additional granularity and for this purpose the “determination of the UTI

Generating party” in the ISDA white paper on UTI generation, communication and matching has

become the market standard for OTC derivatives. However, it should be recognised that it is not

practicably possible for all participants to facilitate this UTI generation and implement rules on how

and when to create these unique codes.




Collateral reporting will be reasonable when the rules regarding margin requirements for uncleared

OTC derivatives is in place. Until then the reporting of collateral should be maintained as per the

current standards. There should be separation between the definition of Initial/Variation margin and

the Collateral to cover these requirements. There is also the question of how to report trades where

the collateral agreement in place requires netting of the IA and VM collateral requirements between

parties before posting/receiving is not adequately addressed in the technical standards.

The ESMA consultation notes Fully / One Way / Partially / Uncollateralised definitions. However the

ESMA Q&A documents provide examples yet no definitions. The Q&A tables refer to actual postings

that have been made, whereas the consultation refer to the agreements (the Q&A does not align to

the consultation in this respects). Members have requested clarification and a table of examples

included in the RTS/ITS to make this clear in order for industry to handle reporting consistent manner.

ESMA should be careful that this does not trigger some questions around the back-loading of

transactions which may not be closed when these new rules will apply. This would lead to

inconsistencies at firm level between two sets of data reported under different standards, but not at

the same time.

ESMA should also provide clarification on what “main residence” means. The current interpretation is

based on legal entity incorporation; domicile and address will be challenging to capture. The scope of

EMIR has been driven by legal entity incorporation; adding domicile/address will create further

complexity around determining the extra-territorial impact.

In respect of the addition of Article 6 we wish to raise a concern on a global UTI being generated on a

European classification basis. This may cause different UTIs being generated for different jurisdictions

and undermining the creation of a global identifier. Additionally, it should be considered how this will

be manifested in the absence of an agreement – presumably this will mean two UTIs being generated

on certain occasions. If it is meant to be used as the default setting so that parties need not agree –

i.e. just rely on the fall-back – this would seem to be appropriate.

Q6: In your view, which of the reportable fields should permit for negative values as per paragraph

40? Please explain.

In general no numeric value field should be restricted from being negative.

In particular EBF members believe that the following fields should allow for negative values:

i. Value of Contract (T1F17)

ii. Price / Rate (T2F16)

iii. Up-Front Payment (T2F23)

iv. Fixed rate of leg 1 (T2F40)

v. Fixed rate of leg 2 (T2F41)

vi. Forward exchange rate (T2F50)

vii. Strike price (cap/floor rate) (T2F67)

viii. Index factor (T2F72)




Q7: Do you anticipate any difficulties with populating the corporate sector of the reporting

counterparty field for non-financials as described in paragraph 42? Please elaborate.

It may be difficult to have all sectors available for each counterparty as all their business/activities may

not be known. Furthermore, it would be possible for a non-financial counterparty to have activities in

more than one sector. We believe that in this case the reporting counterparty should report only the

main sector or the sector the client has supplied information about. We strongly recommend that the

reporting counterparty / report submitting counterpart should be able to rely on the information the

other counterparty is supplying.

We find it inefficient and a strain on all reporting parties to denote the corporate Sector and maintain

such a database. It would have made more sense to include this in the LEI-registration only once

instead of each and every EMIR report.

The proposed mandatory fulfilment of this field with the NACE (Nomenclature of Economic Activities)

could have a significant impact in countries where alternative nomenclatures are more commonly used

(for example, the CAE [Code of Economic Activity] in Portugal), by imposing the necessity of

equivalence between both classifications. It will impact firms that report on behalf of NFCs as they will

need to undertake additional reach-out to capture information on this field, and the mapping into

NACE might not be evident.

Q8: Do you envisage any difficulties with the approach described in paragraph 45 for the

identification of indices and baskets? Please elaborate and specify what would be the most practical

and industry consistent way to identify indices and baskets.

We believe that the highest level of detail represents an improvement. However, we urge that ESMA

should unambiguously define the rules concerning the reporting of the components.

We envisage difficulties for baskets and indices that don’t have an ISIN. This will result in a lot of data

where especially individually created baskets will be very difficult if not impossible to report. We don’t

see the purpose for ESMA to collect all of this information.

It can be hard to derive the information on existing derivatives from current systems. The data is not

available in the correct format in the systems used for reporting. This will lead to a lot of adaptions and

work on reporting systems.

There are not enough field types to describe the content of a basket. If the underlying identifier type

B is used it is not possible to inform which identification type is applicable for each component in the

basket.

If the rules on the order of the report of the fields and on the codification and ordering of the

components where there is no ISIN are properly defined, it should not be necessary for the name of

the basket to be a matching field.

Q9: Do you think the introduction of the dedicated section on Credit Derivatives will allow to

adequately reflect details of the relevant contracts? Please elaborate.

Yes. Since currently there is no section that demands specific information with respect to credit

derivatives, the introduction of a section dedicated to this class represents can be an improvement.




The EBF would support ESMA in clarifying the definition of field 70 “Date of lifecycle event”, and

additionally the types of lifecycle events that are expected to be reported.

Nevertheless, we believe that the report of the interest rate, the frequency of payment and the

calculation basis, as opposed to reporting the coupon, will more adequately reflect the details of the

contract, considering that in some CDS the coupon amount is not fixed.

However ESMA should also take into account that this would again add complexity to the current data

management of firms that do not necessarily have the information required in the right format.

Q10: The current approach to reporting means that strategies such as straddles cannot usually be

reported on a single report but instead have to be decomposed and reported as multiple derivative

contracts. This is believed to cause difficulties reconciling the reports with firms’ internal systems and

also difficulties in reporting valuations where the market price may reflect the strategy rather than

the individual components. Would it be valuable to allow for strategies to be reported directly as

single reports? If so, how should this be achieved? For example, would additional values in the Option

Type field (Current Table 2 Field 55) achieve this or would other changes also be needed? What sorts

of strategies could and should be identified in this sort of way?

The problem described by ESMA is an issue firms are experiencing when reporting strategies and

packages including more than one option. The Option Type field should permit firms to include Exotic

Options as part of the Option classification. Additionally, the firms booking methodologies are often

depicted in way that more than one option component are linked to the same transactions, so it would

be convenient to allow the reporting of more than one Option within the same report (separate strike

prices, etc.)

This is a vital question, which relates to the technical infrastructure used by each market participant.

Current reporting practice differs amongst market participants, primarily due to different trading and

risk systems. A trading strategy which can be booked as a single trade by one participant may require

registration of multiple trades by another participant.

EBF members have proposed two different options:

1. Report package deals as one record, as confirmed with the counterparty Pros: Easier to reconcile if both parties report one record only Cons: Technically difficult for counterparties to construct one record out of several booked trades, especially if the number of attributes to be reported for package deals are the same as for non-package deals

2. Report structures as booked by each counterparty in internal system with one common UTI for all components within the same package Pros: Package deals will be reported as booked in the systems, which minimizes operational risk Cons: Reconciliation is challenging if parties of the same package deal report different number of records that do not match on component level, only on package level as confirmed




Both alternatives may require changes on which attributes to report for package deals, and also the possibility to report a common UTI or link ID if reporting on component level as booked by the individual party. Also, the EBF would also like to stress the importance of giving enough time for the market to adapt to the reporting of structures/strategies.

Q11: Do you think that clarifying notional in the following way would add clarity and would be

sufficient to report the main types of derivatives:

60. In the case of swaps, futures and forwards traded in monetary units, original notional shall be

defined as the reference amount from which contractual payments are determined in derivatives

markets;

61. In the case of options, contracts for difference and commodity derivatives designated in units

such as barrels or tons, original notional shall be defined as the resulting amount of the derivative‘s

underlying assets at the applicable price at the date of conclusion of the contract;

62. In the case of contracts where the notional is calculated using the price of the underlying asset

and the price will only be available at the time of settlement, the original notional shall be defined

by using the end of day settlement price of the underlying asset at the date of conclusion of the

contract;

63. In the case of contracts where the notional, due to the characteristics of the contract, varies over

time, the original notional shall be the one valid on the date of conclusion of the contract.

Yes, we feel these changes will add clarity and be sufficient for reporting.

We suggest that the term ‘initial’ is used instead of ‘original’, and please refer to our comments in Q4

which we reiterate here.

The notional value must be specified for each asset class and derivative type in combination in order

for the counterparties to clearly understand and for differences to be minimized. In addition, for ETD

positions required to be reported it is not clear which notional value is the original/initial since the

notional value changes from day to day and the initial value is not directly pertinent for reconciliation

purposes.

Additional comments:

In addition to the answers previously given, it is worth mentioning that in the Annex, in particular in

“Table 2 – Common Data”, in what concerns fields 46 and 47, it is suggested that the name of the

floating rate index should change so that the relevant period and the index name should be separated

by “ / “. (Ex: 3M/EURIBOR). We believe that this proposal is insufficient, since:

(i) In some operations, the index is the average of another index within a given period (Ex: The

average EURIBOR 3M in the month prior to the fixing date). In these cases we are including

“AVERAGE” in the index name. Is this the best practice or, for example, 3M/EURIBOR should

be reported whether it is a simple or an average rate?




(ii) For CHF, USD and GBP, the index is LIBOR. This could raise further issues. However, the EBF

and its members would support jointly working together with ESMA to find a solution that

would be acceptable to all parties.


EBF response to the ESMA Consultation Paper on the review ... · on reporting under Article 9 of...

Documents

Transcript of EBF response to the ESMA Consultation Paper on the review ... · on reporting under Article 9 of...