MiFID II, Welcome to the Jungle; Client Classification Challenges and Data Model Magnificence
In efforts to implement the MiFID II regulations in time for the compliance date of 3rd January 2018, almost all market participants are still struggling with the lack of clarity and guidance on the rules. The detail of regulation is a veritable jungle in which, almost paradoxically, the main goal or aim is clarity! In speaking with our clients and consulting industry partners we have, however, identified four crucial areas that will require detail and rigour when implementing KYC processes under MIFID II.
1. Client suitability and appropriateness
Firms will have to apply tests to determine the suitability of clients; obtaining relevant information from a client or potential client before providing investment or portfolio management services. They will need to determine the knowledge and experience of the investment field in which the investment advice or portfolio management is to be offered; their financial situation including their ability to bear losses; and the investment objectives, including the risk tolerance of the client. In practice, suitability checks must be adaptable and client-specific.
2. Client classification
Also in the context of the suitability regime, firms are required to classify clients either as retail, professional or eligible counterparties.
3. Target market identification
Further, again in the vein of suitability and classification, a financial services product manufacturer must identify at a sufficiently granular level the potential target market for each financial instrument and specify the type(s) of client for whose needs, characteristics and objectives the financial instrument is compatible. The new requirements to manufacture and distribute financial products to a pre-defined ‘target market’ will require knowledge about clients, in order to ensure target market product requirements are met.
4. Marketing controls
Firms will need to make or conduct the new client classifications and suitability assessments, noted above, before marketing complex financial products to their clients. In other words, even in the sales process, firms will need to take into account the perceived needs of the intended target market, when marketing and distributing their products.
Financial Services firms have understood that, because of the challenge of moving through the almost impenetrable labyrinth of the regulation, decisive planning and preparation must take place now for the creation of well-built systematic processes, compliance procedures and the deployment of suitably capable supporting technology. In a recent engagement with one of our clients who is doing just this, iMeta has been able to assist specifically with the challenge of storing the correct MiFID II client classification, bullet point 2 above.
Amendments to the suitability regime now requires that clients be classified as either retail, professional or eligible counterparties.
At the same time the regulation defines a number of legal entity types; from Credit Institutions through Collective Investment schemes to ‘other’ institutional investors etc. Under MiFID II, and different from various other regulations (ESMA for instance), there now exists a convoluted challenge of needing to use client entity type and the ‘role’ they will play in the given interaction with the bank, to define or derive their precise classification.
In other words, it is now not enough to create one single classification for a client if, for different transactional purposes, the same client will play different roles; i.e. in a direct trading relationship the client would be the Principal, in an agent trading relationship, the bank would interact with the Fund Manager or Investment Advisor but on behalf of an underlying Principal etc.
Other trading relationships that would define different ‘roles’ include Executing Broker and Prime Broker engagements. As part of our client’s broader regulatory solution, iMeta CLM is being deployed particularly to address the need to have a data model flexible enough to store different MiFID II classifications, for the same legal entity.
As we have noted, this is required where a variety of nuances across product type, bank balance sheet and transactional role (at an account level) dictate different regulatory classification. We have been able to achieve this because the design of our data model allows for the efficient specification of the fields required to capture the information and data quality rules needed to enforce the policy.
iMeta CLM‘s configuration tools allow the definition of these policies in one place in a separate tested module that can be deployed on top of a customer’s own KYC policy, or taken and adapted in order to achieve a customer’s own MiFID 11 policy style. It may be a tangle of regulation, but we have the tools to help you navigate the jungle!