MiFID II: 6 Key Changes for Client Lifecycle Management

In less than six months’ time (January 3rd, 2018), banks will need to be fully compliant with MiFID II regulatory obligations. In her second blog on the topic, Laura Glynn, Fenergo Director of Regulatory Compliance, explores the six key areas where MiFID II will impact the Client Lifecycle Management process.

A wide-ranging and complicated regulation, MiFID II presents increased complexity into the Client Lifecycle Management process by introducing new classifications for both clients and products alike. This will potentially bring more clients into scope for MiFID II obligations.

In my  previous blog, we examined how MiFID II will deliver significant changes for banks across their operations, technologies and client lifecycle management processes.

A core part of complying with MiFID II will involve client outreach to collect the data and documentation required to support the regulatory obligation and drive the ultimate compliance decision. All of this will have a heavy impact on operational efficiency, which may, in turn, hinder compliance ahead of the deadline of January 3rd, 2018. This has the potential to seriously erode client experience.

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

1. Client Categorization

The Markets in Financial Instruments Directive II will bring no significant changes to 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, one fundamental update means that it will no longer be possible to treat local authorities and municipalities as Professional Clients or Eligible Counterparties.

Instead, they may choose instead to opt up to Elective Professional Client status, once the firm has assessed them as having the requisite knowledge and experience to meet the opt-up criteria.

From a Client Lifecycle Management perspective, local authority and municipality clients must be re-categorized. This will involve a series of tasks and activities designed to reclassify 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 client that falls under this category to inform them of the reclassification and solicit consent if they elect to change from Retail Client or opt to be treated as Elective Professional Clients.

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

2. Identification Requirements – The Rise of the Legal Entity Identifier

While the collection of LEIs is already recommended under several key regulations such as EMIR (European Market Infrastructure Regulation) and MAR (Market Abuse Regulation), it will finally become mandatory 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.

Many financial institutions are currently examining 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 paltry 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 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 assist legal entities to access a greater number of organizations authorized to issue LEIs.

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

3. Product Classifications

MiFID II brings into scope a much wider range of financial instruments, which must be classified appropriately. This is especially 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 is required to 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 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, populate the Transaction Report.

4. Suitability & Appropriateness

As mentioned above, 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 fulfil suitability obligations.  A fundamental requirement is to determine and document if investment advice is being provided to the client. This will drive the subsequent suitability and/or appropriateness obligations.   

To this end, client onboarding or client lifecycle management software solutions must be capable of recording 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.  

5. Direct Electronic Access

For the first time, MiFID II brings Direct Electronic Access (DEA) clients into scope for regulatory compliance and written agreements must be put in place between the firm and the 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 must 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 software solution, including

• Due diligence assessment;
• Assessment of suitability of DEA;
• Any pre-set trading and/or credit thresholds;
• Mandatory binding written DEA agreement.

6. Transaction Reporting

Under MiFID II, transaction reporting will apply to a much 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 should 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, software solutions should 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:

The next few months are set to test the mettle of compliance, data and operations teams tasked with ensuring compliance with MiFID II. 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. Furthermore, this will encourage the re-use of these attributes across multiple business units, jurisdictions (data privacy rules permitting) and regulations, which will increase operational efficiency and improve the overall client experience.