Companies in the Financial Services sector that take their clients seriously will create a thorough inventory as knowledge about their client(s) and the objectives of these client(s) determine the quality of the advice, and thus ultimately the satisfaction of the client. In practice, there is a big difference between the risks that a client can take and wants to take.

This text comes from a document of the Dutch Authority for the Financial Markets (the AFM). This document provides good practice recommendations concerning Know Your Customer (KYC) information that must be identified.  Unfortunately, all “good practice recommendations” are text examples. Texts are easily accessible, can be well formulated, and are very compact. However, retrieving information from text and maintaining consistency is difficult.  The best way to store information about the KYC inventory process is a database. A database can define and maintain relationships between various types of information. Information like a person’s last name is stored only once and can be reused at different locations.

Information can be changed once and will appear correctly in all locations where the information is being used. Validation of data is also possible. Retrieving information is easy with special query languages like SQL.

A KYC text document versus a relational database   

(This is a KYC inventory in text)

The situation:

“Mr and Mrs Jansen want to invest €600,000. Mr and Mrs Jansen are currently 50 years old. They have told the advisor that Mr Jansen wants to retire at the age of 65.”

In theory, this information can easily be captured in a text document to meet the know your customer requirements. Several wealth managers are still using MS-Word documents and paper inventory forms for the KYC inventory process.

Using paper forms or a MS-Word document for Know Your Customer inventory has many disadvantages. A MS-Word document is very error prone and can lack structure. Other disadvantages may be:

  1. Lack of consistency in the inventory process.
  2. Interpretation of answers is a problem. Tables do a better job.
  3. Great risk that the collected information is incomplete, and many questions are forgotten
  4. The document can be lost.
  5. The KYC history consists of a set of documents. This is not very accessible if there are any issues.

If we store the information captured in a MS-Word document in a KYC portal database, challenges arise. The text must be analysed and structured. This text immediately transforms in multiple database tables with multiple fields and checks.

The text “Mr and Mrs Jansen want to invest €600,000. Mr and Mrs Jansen are currently 50 years old. They have told the advisor that Mr Jansen wants to retire at the age of 65.”  has the following data and database structure consequences:

  1. Multiple people must be registered per household/address;
  2. Sex, full (first and last) name and date of birth must be stored;
  3. A table that describes the relationship between the family members (type of relationship + starting date and possible end date) must be created;
  4. The expected retirement date must be provided per person;
  5. The investment start capital must be entered in a field with a value and a currency;
  6. All provided information needs a timestamp;
  7. Possible “Life Events” (such as a divorce) must also be processed;

Information that must be obtained

The client must always at least answer the following KYC questions: (If an account has more owners than the inventory process concerning the personal information, the following must be registered for each person)

  1. Personal information like name, sex, children etc.
  2. What is the client’s education and profession?
  3. What kind of knowledge of and what kind of experience with the various types of financial instruments does the client have?
  4. What does the client need the capital for?
  5. When does the client want to achieve the capital objective(s)?
  6. What amount does the client need to achieve the objective(s)?
  7. Is the client planning to make interim deposits or withdrawals? And for what amount?
  8. Are there any other short and long-term objectives that may be of interest?
  9. Does the client have a financial buffer set aside for growth?
  10. How dependent is the client financially (now and in the future) on achieving the objective(s)?
  11. How much risk can the client bear given his income and capital position – now and in the future?
  12. Is the client willing to lose his deposit? If so, what is the maximum amount the client is willing to lose?
  13. What chance of not achieving his goal is the client willing to accept?
  14. As the previous section shows, the impact of these questions on the data model of a KYC portal is significant.

Regulations on the move

Besides the regulations of the Dutch Authority for the Financial Markets (the AFM), there is also a rapidly changing European playing field with the MiFID II and the GDPR.

Laws and regulations will continue to change, and the SCOPE KYC Cloud portal must remain compliant with applicable legislation and regulations. This requires attention, legal knowledge and the constant monitoring and interpretation of changes in legislation and regulations. SCOPE FinTech regularly works with lawyers to monitor the compliance of the SCOPE KYC Cloud Portal software with MiFID II and the GDPR. 

The SCOPE of our KYC portal

When we started this project, we had a lot of ideas in mind, because we wanted to create the best know your customer portal possible

We worked together with an expert panel to create the right product for a know your customer inventory. The expert panel consisted of multiple experts from various disciplines like the legal sector, wealth management, user interface and customer due diligence.

As part of the functionality, we integrated software from multiple specialised suppliers in our SCOPE KYC portal, like the FinaMetrica psychological risk tolerance test and AMCET’s Monte Carlo simulation software.

We believe the SCOPE KYC Cloud portal must be state of the art. We started from scratch with the creation of the SCOPE KYC Cloud portal.  Technically, we made sure we worked with the best partners available. Thanks to our experience in data security, we were able to make the right choices. We have selected Microsoft Azure as hosting environment. Microsoft Azure is a cloud provider and is the first hosting party that has committed to be GDPR-compliant.

We developed a know your customer data model with 56 data tables in which all know your customer information can be stored. Each table contains multiple fields and checks. Entered information will never be deleted, except when a client requests to have his or her history deleted (GDPR). The SCOPE KYC Cloud portal saves all the modifications in the information and has the option to go back in time from the first till the last inventory.

The SCOPE KYC Cloud portal has a well-designed user interface based upon Google material design principles. We developed the SCOPE KYC Cloud portal as a self-service application with a lot of functionalities to make give the users a pleasant experience. We also developed a management information cockpit to monitor the ongoing KYC inventory process.

Since the start of the development process of the SCOPE KYC Cloud Portal in November 2016, SCOPE Fintech Solutions has spent approximately 72 months on programming, testing and perfecting the SCOPE KYC Cloud Portal.

Conclusions

Designing, creating and maintaining application software like the SCOPE KYC Cloud portal is a complex process which takes a lot of time. It is a profession. Everybody should stick to what they know. If your core activity is asset management, ensure that your focus remains on serving existing clients as effectively as possible and bringing in the right new clients, instead of distractions in the form of IT projects.

Find the right partner based on your own commercial vision which is similar in terms of the solution and continuity and who can provide you with a state-of-the-art KYC solution suitable for your current and future needs. SCOPE FinTech Solutions is ready to be your strategic partner.

We have made a list for you regarding a standard software package versus custom software package

Pros and cons of standard software packages

The advantages of standard software are:

  1. Standard software packages can be purchased easily and quickly. Standard software packages are cheaper because they need to be developed once and are used by several companies.
  2. Faster to implement. There is support available for standard software, but it has not been developed specifically for you. The implementation is faster and demands less of your employees. Best practices on automation of the specific business processes are often available. These are proven effective practices that have already been used by other companies for years and that you can also benefit from to optimise your business process with relatively little effort.
  3. More reliable, because the standard software package has been used and tested by many clients.
  4. Continuous: maintenance and updates are usually made available.

The disadvantages of standard software are:

  1. The user organisation must adapt to the standard software.
  2. Unnecessary and/or inadequate features.

Advantages and disadvantages of custom software development

Developing custom software is the opposite of the above.

  1. More expensive.
  2. Greater demands on the own organisation because extensive specifications must be delivered. After the software has been developed, testing must take place and the software must eventually be deployed.
  3. The implementation takes longer.
  4. There is little or no support available outside the company.
  5. Continuity is a problem because there is no ongoing development and the original developers are going to carry out other projects.

The advantages of custom software are:

  1. Software adapts, instead of the organisation.
  2. No unnecessary and/or fewer deficient features.
  3. Sold as a standard software package.