Project Description

Recently, on a banking project, there was the requirement to build a new Markets in Financial Instruments Directive questionnaire, more precisely the suitability questionnaire, that would unify and improve the current MiFID questionnaires used by the bank in different applications.

The Markets in Financial Instruments Directive (also known as MiFID) is an European Union law that provides harmonized regulation for investment services across the 31 member states of the European Economic Area (the 28 member states of the European Union plus Iceland, Norway and Liechtenstein).

Basically, if you want to subscribe financial products or services impacted by this directive, you need to fill in a questionnaire that will evaluate how suitable you are to subscribe to that product or service. If you are suitable, you will be able to buy the product or service, but if you are not suitable you may not be able to buy the product or, at least, you will need to sign a disclaimer where you say that you know about the risks of buying that product or service, which consequently proves that you were informed about this fact by your bank. This means that your investment’s responsibility will be imputed to you and not to your bank.

The main objective of this directive is to improve investor’s protection, harmonize investment services and enhance competition in the financial sector within the EU. The directive has impacts on, among other products and services, bonds and derivatives transactions, and the provision of investment advice.

My goal in this article is to explain how I and my team achieved this objective in the context of the user interface, with standard technologies, that sometimes many people forget to use in order to solve this kind of business challenges.

Mifid questionnaire project logo

Mifid directive

The Requirements: the Questionnaire Content and its Rules

An important requirement is that the suitability questionnaire is mandatory. It means that financial firms covered by MiFID cannot provide the advice or management service or product if the client has not completed the test and has not provided all the required information. Despite the importance of this rule, the rule was not implemented in the questionnaire itself. This is something that must be validated in the questionnaire’s workflow before the subscription of the product or service targeted by the MiFID rules.

Another important requirement is the contents of the questionnaire. Accordingly to the MiFID Level 2 Commission Directive 2006/73/EC, art. 35 and 37, the set of items suggested to be included in the suitability questionnaire are summarized in the following table.

Section Information collected
In this section the investor has to provide information regarding the purpose of the investment and the time horizon of his planned investment.

The investor must also choose one of the presented risk appetite and loss tolerance statements, so that the bank may assess its attitude towards risks and thus identify the product or service group(s) that are most appropriate for the investor.

FINANCIAL CAPACITY As a prerequisite for providing investment advice services, the bank must first familiarize itself with the investor’s financial ability.

To accomplish this, the investor must indicate its regular monthly income and income sources, its regular monthly expenditures and their breakdown, and the difference between regular monthly income and regular monthly expenditures.

Finally, the investor must specify the assets (including liquid assets) that he currently owns and their respective approximate share in his portfolio.

The purpose of the appropriateness test is to enable the bank to identify the services, transactions and financial instruments known to the investor, and examine whether he has any relevant experience in any of them.

To accomplish this, the investor is asked about the products whose features and risks he is aware of, and he also has to provide some information about his experience with each financial instrument: government securities, corporate/bank bonds, mortgage bonds; shares; investment funds; real estate funds; structured products and foreign-exchange (FX) options.

Additionally, the investor must provide some information about his educational level and professional experience and tell if he held any position related to financial instruments or requiring financial expertise over the past 5 years.

Even though MiFID indicates the information to be collected by the questionnaire, each financial institution is free to define the specific questions of its own suitability questionnaire, provided that the three main sections are covered. This means that our implementation must include the questions and answers as provided by the customer, no more, no less. Also, the questionnaire must be available in both Portuguese and English languages because the bank works with clients from both nationalities.

Another important concept is that the MiFID suitability requirements vary according to the type of customer: for retail clients (non-professional clients) the sources of information are more numerous, while for professional clients the data requirements are more essential. Additionally, to know if a client has studies in the financial area or if the client has bought financial products over the last years are also important determinants of the questionnaire questions presented to the client. Basically these requirements will dictate which products and services will be presented to the user, and what questions the user must answer regarding the selected products or services.

Finally, in order to make the questions of the questionnaire more understandable by the client, MiFID states that some additional information must be given to the clients regarding some of the questions. In other words it is necessary to implement a help system.

The Requirements: User Experience and Non-Functional Requirements

The MiFID questionnaire was not something new in the context of my clients. However, there was the requirement to unify different questionnaires and to improve them in one unique shared questionnaire. This way, the new questionnaire would need to be available in different applications, including applications built in different technologies like .Net and Java.

One important consequence of this requirement was that the maintenance of the questionnaire would be easier, because in an advent of a questionnaire change, only one change would be needed to be incorporated. Also, the bank wouldn’t need a Java expert and a .NET expert to change the questionnaire, because the questionnaire would be agnostic to those technologies.

in addition to this requirement, it is important to state that an already in place XML representation of the questionnaire should be used. This XML representation of the questionnaire could be obtained by calling a web service method from an existent application. This way, the new questionnaire would need to integrate with this existent solution.

Another important requirement is the questionnaire’s navigational behaviour and the related user experience. It is important to provide the user a transparent and clean experience while answering to the questionnaire’s questions, so that he can express himself in the most natural way. To accomplish this, it was decided by the business, that the questionnaire should present the questions one by one, and the users should be able to navigate to the next question only after answering to the current question. On the other hand, the user could navigate back to any question of the questionnaire, one question each time.

Finally, the objective was not only to empower users to create new questionnaires but also to enable them to edit not finalized questionnaires; to consult them and to make special changes to finalized questionnaires called as “Add services” with which users may include additional financial services in the questionnaires.

It is important to note that a questionnaire created by this system must be printed and signed by the customer, and then digitized and uploaded again to the system. Only the signed and uploaded questionnaire will have legal validity. Of course the questionnaire could be directly signed using a digital signature but that was not a requirement for this solution.

Plus, after being uploaded, the questionnaire begins a validation process, where the uploaded and signed questionnaire is validated in order to understand if the questionnaire was successfully scanned and if the customer’s signature matches the written signature. Then, the questionnaire is compared with its physical version to see if both match. If they match, the physical copy of the questionnaire is archived.

Of course this questionnaire’s life cycle workflow is out of scope of the present article, but it is important to understand its existence.

The Solution

If you are a web developer, then you should already know the solution. We are receiving a XML structure of the questionnaire and we need to present it in both Java applications and .Net applications. So, a good approach is to use XSL to convert that XML structure in a HTML document. Although the XSL parsers are a little different between these two technologies, we shouldn’t have problems if we stick with XSL version 1.0.

Additionally, the questionnaire was built using standard HTML technologies, mainly HTML, JavaScript and CSS. In its essence, the questionnaire is a big HTML table with more tables inside it. Each table has its headers and its table rows, and represents a questionnaire’s question and its possible answers.

The questionnaire code is organized in four main sections as displayed in the following image.

MiFID Suitability Questionnaire Architecture

MiFID Suitability Questionnaire Architecture

The XSL configuration section is where XSL parameters are specified. These XSL parameters are initialized with default values, but the calling application can overwrite them. The most important parameter is the “viewMode” parameter, that sets the mode how the questionnaire will be opened. The calling application can specify a read only mode, useful to get the questionnaire in a consult mode; an Edit mode so that the customer may populate the questionnaire with data; and an “add services” mode, where only the related section of the questionnaire is displayed and able of being edited.

In the CSS section, the layout of the questionnaire is defined. The CSS is also used to hide and show certain sections of the questionnaire.

In the JavaScript section, all the questionnaire’s business rules and navigation control are implemented.

Finally, in the CSS section it is implemented in the XSL rules that convert the questionnaire’s XML structure in its HTML structure.

When the questionnaire is opened, the “viewMode” value is read from the initialization section, and the questionnaire is displayed accordingly. Only the relevant section of the questionnaire is displayed.

The user can then navigate through the remaining questions of the questionnaire using the back (<<) and the next (>>) buttons. An internal array controls the number of questions of the questionnaire (that can dynamically change depending of the user answers) and the current position of the user. When the user navigates from one question to another question, the current question is hidden and the new question is displayed. This process is always the same, regarding the question the user is answering.

Each time the user navigates to a question, many rules are being validated. For instance, it is calculated whether the user answered the current question, if not, the user will not be able to navigate to the next question, although the user may navigate to previous questions.

Other validations included are related to MiFID’s business rules. For instance, if an investor doesn’t have academic training but has professional experience on any kind of simple or complex financial product, then only the remaining product families will be presented in the knowledge and experience section. Then, for each selected family, the investor will need to answer to specific related questions. This is a good example of an answer that may have impact in subsequent questions.

When the user reaches the final question and all the questions are answered, the user will be able to submit the questionnaire in order to create a new questionnaire or to change an existing questionnaire.

Given the fact that a questionnaire may be called by different applications, the questionnaire is not responsible by the submission of its data to any external system, because different applications may submit its data to different backend solutions.

Instead, the parent application executes a JavaScript method that returns a XML of the questionnaire data. This internal function performs a cycle by all the questionnaire answers and builds a XML of answers that is returned to the parent application. In this way, the parent application doesn’t need to understand the questionnaire structure to get its data.

What Could be Improved

Regarding the functional solution, even though MiFID indicates some advisable questions to be included in the questionnaire, each financial institution is free to define the specific questions of its own suitability questionnaire, provided that the three main sections are covered. This means that each financial firm makes use of its own questionnaire that is likely to be different from the ones used by its competitors. Consequently, the same person can get different scores in different financial firms, what turns the MiFID directive less objective and effective.

At the non-functional level, what we have soon realized was that the JavaScript supporting the questionnaire was getting bigger and complex. Since the questionnaire would be used by home banking solutions, the JavaScript needed to be compatible with different browsers and between different versions of the same browser. But, that is difficult to achieve and specially to maintain. Thus, if we had realized in first hand that the JavaScript would become so complex, we would have used a JavaScript library like jQuery that provides a more transparent browser versions support.

Learning more about MiFID

If you want to learn more about MiFID, then check these useful references.