MiFID II: Six significant changes for Client Lifecycle Management

By Laura Glynn | 13 September 2017

The Markets in Financial Instruments Directive II (“MiFID II”) aims to improve current European legislation by introducing further transparency into financial markets and extending increased protection to investors. The incoming directive will add increased complexity to the Client Lifecycle Management process for banks within the EU, as well as banks around the world that serve European clients, by introducing new classifications for both clients and products alike. This will potentially bring more clients into scope for MiFID II obligations.

A fundamental part of complying with MiFID II will involve client outreach to collect the data and documentation required to support the new regulatory obligation and drive the ultimate compliance decision. This extensive outreach effort will have a substantial impact on operational efficiency and may hinder compliance ahead of the deadline of January 3rd, 2018.

All things considered, MiFID II has the potential to seriously erode client experience.

We’ve outlined the six significant areas of the Client Lifecycle Management process that will be directly affected by the incoming directive below:

Client Categorization

The Markets in Financial Instruments Directive II will not impact the current MiFID classification regime (i.e. the three main categories of Eligible Counterparty (EC), Professional Client (PC) and Retail Client (RC) will remain).

However, under MiFID II, local authorities and municipalities can no longer be classified as Professional Clients or Eligible Counterparties.

These entities can instead opt up to Elective Professional Client status, provided they satisfy the required knowledge and experience to meet the opt-up criteria.

How does this affect Client Lifecycle Management?

From a Client Lifecycle Management perspective, local authority and municipality clients must be reclassified. This will involve a series of tasks and activities designed to recategorize clients compliantly, including:

a) A client data look-back process to identify all local authority and municipality clients that may need to be remediated and reclassified accordingly.

b) An outreach program to each affected client to inform them of the reclassification and request consent if they elect to change from Retail Client or opt to be treated as Elective Professional Clients.

c) Establishing a process whereby all consent documents can be signed, returned and processed efficiently.  

Identification requirements: The rise of the legal entity identifier

Although the collection of LEIs is already advocated under several key regulations such as EMIR (European Market Infrastructure Regulation) and MAR (Market Abuse Regulation), the Legal Entity Identifier will finally become compulsory for the first time under MiFID II for firms’ subject to Transaction Reporting (TR) obligations.

This means that firms that fall under this remit will not be able to execute a trade on behalf of a client who is eligible for a Legal Entity Identifier (LEI) and does not have one. In fact, submitting transaction reports without LEI data will result in the rejection of the reports by competent authorities.

The LEI challenge for MiFID II

Many financial institutions are currently reviewing client data to identify clients without a valid LEI, performing an outreach program to these clients to encourage them to apply for the LEI from their Local Authority Units (LOUs).

Given the relatively low uptake of LEIs thus far (i.e. 64,000 LEIs were issued in 2016, however, 76,000 had lapsed during the same period), it is envisaged that there will be significant demand on LOUs in an effort to attain an LEI before January 3rd, 2018.

In anticipation of this, GLEIF (the Global Legal Entity Identifier Foundation) recently introduced the concept of “Registration Agents” to enable legal entities to access a greater number of organizations authorized to issue LEIs.

From a technology perspective, banks will need to consider upgrading their existing client onboarding software solutions to include real-time data fields e.g. LEI, status of LEI, legal address, legal name and associated entity etc.

Product classifications

MiFID II extends transparency requirements to a much wider range of financial instruments, which must be classified appropriately. This is particularly relevant for MiFID II Transaction Reporting obligations.

There is a new inclusion in the “financial instrument” definition under MiFID II called Commodities, which covers a wider range of products including cash-settled commodity derivatives, physically settled commodity derivatives, exotic derivatives and emission allowances.

The “CFI” (Classification of Financial Instruments) code is a mandatory field for transaction reporting and must follow the ISO 10962 standard. This is a 6-letter code with a clearly defined logic e.g. equity shares = ESXXXX, equity shares with voting rights = ESVXXX.

To ensure compliance with new product classifications, financial institutions will need to map their existing product list to the ISO 10962 code. Clients who trade in these newly covered products will be brought into scope under MiFID II and may be required to provide additional data and documentation to support the regulatory obligation. All this information (client data and new product classifications) should, in turn, be included in the Transaction Report.

Suitability & appropriateness

As previously mentioned, every client must be categorized appropriately as an Eligible Counterparty, Professional Client or Retail Client, depending on their knowledge and experience, including their ability to bear losses and a client’s risk tolerance.

As a result of these categorizations, the financial institution must ensure it fulfils suitability obligations. A core requirement is to determine and document if investment advice is being given to the client, as this will define the subsequent suitability and/or appropriateness obligations. 

To this end, client onboarding or client lifecycle management software solutions must be able to validate suitability requirements for knowledge and experience, the financial situation and investment objectives. To eliminate regulatory interpretation, the ideal solution will include a panel of embedded logic, which will determine the suitability and appropriateness requirement for the entity based on regulatory rules.    

Direct Electronic Access

For the first time, MiFID II brings Direct Electronic Access (DEA) clients into scope for regulatory compliance. This means that written agreements must now be put in place between the firm and each DEA client.

MiFID II dictates that all DEA clients must undergo at least an annual due diligence review - much like a KYC refresh process (the difference being it must occur at least every 12 months regardless of the client’s risk rating, unlike the KYC process which is linked to risk level).

In a client lifecycle / onboarding situation, financial institutions should identify and classify all DEA clients accordingly. As a first step in the client onboarding process, a user should be allowed to confirm if the entity provides DEA services.

Several new regulatory requirements for DEA entities should be included in the client lifecycle solution, including:

a) Due diligence assessment

b) Assessment of suitability of DEA

c) Any pre-set trading and/or credit thresholds

d) Mandatory binding written DEA agreement

Transaction Reporting

Under MiFID II, transaction reporting will be applicable to a wider range of financial instruments and require the disclosure of additional mandatory data. The requirements for transaction reporting are being extended to include additional new venues, more financial instruments and greater scope of the actual report (such as identifying the client and the individual trader of the transaction). These transactions must be reported to Approved Reporting Mechanisms (ARMs). Transactions reported in accordance with EMIR to a trade repository, which is approved as an ARM, will typically satisfy the MiFIR reporting requirement.

To fulfil MiFID II transaction reporting obligations, banks must leverage solutions that can accommodate the capture of client static data (i.e. data that does not change based on the entity’s trading activity) and processing of these additional data and products.

Conclusion

MiFID II represents a key opportunity to radically transform compliance operations into a truly client-centric, efficient and value-added function. The next six months will test the mettle of compliance, data and operations teams tasked with ensuring compliance with MiFID II however. Managed correctly and automated appropriately, financial institutions can create a common, centralized Client Lifecyle Management platform that delivers a unified view of client data and documentation. This will encourage re-use of these attributes across multiple business units, jurisdictions, where data privacy rules permit, and regulations. For further information, please refer to the Fenergo MiFID II – The 6 Month Countdown whitepaper