When developing the professional skills of advisors, skills that serve to getting to know the customer during the inventory process and properly inform the customer are given less attention. The AFM believes that banks and investment firms should pay more attention to the development of these skills. The way in which the consultant obtains information about the customer influences the completeness and depth of the customer profile.

Companies in Financial Services, which take customers seriously, will conduct a thorough inventory because knowledge about the customer(s) and the objectives of the customer(s) determine the quality of the advice and thus ultimately the customer satisfaction. In practice, there is a big difference between the risk that a customer can and wants to face.

Example of good advice practice

In the aforementioned document, the AFM provides examples of what information must be requested and processed under the “an example of good advice practice” heading. You can find texts that can easily be entered but are well formulated but have a major impact on the way in which data have to be stored in a database.

A textual example from page 28: “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.”

This information can quickly be entered in a document to meet the AFM requirements in theory. A number of asset managers work using word processing documents and paper inventory forms. This obviously has many disadvantages. These include but are not limited to:

  • Very error prone
  • No or little structure
  • Consistency in questions and the interpretation of answers is a problem
  • Risk that the information is incomplete and questions are forgotten
  • The document can be lost
  • No real request options
  • The history is difficult to trace

If we want to store the described information in a know your customer database, challenges arise. The text has to be analysed and suddenly looks different. The text example has the following consequences:

  1. Several people must be registered per household/address.
  2. The sex (as long as it is allowed), the (first and last) last name, date of birth, when required. An expected retirement date must be entered.
  3. A table that describes the mutual relationship (type of relationship + starting date and possible end date) must be created, and
  4. The capital must be able to be recorded as a field with a value.
  5. Furthermore, all information must be provided with a timestamp (date/time). However, what is true today does not have to be true tomorrow.
  6. The so-called Life Events (for example a divorce) must also be processed.

A few sentences in the text immediately provide three-four database tables with multiple fields and checks. It is not that simple. The aforementioned document contains 10-15 examples of good advice practice, which often covers a few dozen lines. These are just guidelines. There are also lawsuits and jurisprudence.

Types of information that must be obtained

A list of the information that must be obtained is set out on page 24. This is phrased as follows: The customer must always answer the following questions:

  1. What knowledge and experience with what financial instruments does the customer have?
  2. What is his education and profession?
  3. What does the customer need the capital for?
  4. When does the customer want to achieve his objective(s)?
  5. What amount does the customer need for his objective(s)?
  6. Is the customer planning to make interim deposits or withdrawals? And for what amount?
  7. Are there any other short and long-term objectives that may be of interest?
  8. Does the customer have a financial buffer to set aside for growth?
  9. How dependent is the customer financially (now and in the future) on achieving his objective(s)?
  10. How much risk can the customer face given his income and capital position – now and in the future?
  11. Is the customer willing to lose his deposit? If so, what is the maximum amount the customer is willing to lose?
  12. What chance of not achieving his goal is the customer willing to accept?

As the previous section shows, the impact of these questions on the data model of a know your customer application is very significant.

Legislation on the move

In addition to the AFM publications, there is also jurisprudence and the field is changing rapidly with the MiFIDII and the GDPR. Laws and regulations will continue to change and the KYC software must be and remain compliant with applicable legislation and regulations.

This requires constant attention and legal knowledge and expertise and the 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, MiFID II and the GDPR. 

Scope of the application

We have now developed 56 models in which information must and can be stored. Each model contains multiple fields and checks. In addition, there will also be a user interface, various integrations and a complete management cockpit. In all cases, there are hundreds of manhours of work involved.

Since the kick-off of the development process of the SCOPE KYC Cloud Portal in November 2016, SMT has spent approximately 36 months on the programming, testing and (technical) documentation of the SCOPE KYC Cloud Portal up to June 2018.

In addition to the programming and test work, a lot of time was spent (12 months) on adjusting the expert panel and the continuous functional design and development of a solution.


Designing, creating and maintaining software is a complex process. You must stick to what you know. If the core activity is asset management, ensure that your focus remains on serving existing customers as effectively as possible and bringing in the right new customers, 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 at this time and help you achieve future plans. SCOPE wants to be this strategic partner and we would be happy to convince you in a personal meeting.

Standard software package versus customization

Pros and cons of standard software packages

The advantages of standard software are:

  1. Standard software packages can now 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 for you. The implementation is faster and demands less of your employees. Best practices on automation of the specific business process 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 a large number of customers.
  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 functionality.

Advantages and disadvantages of custom software development

Developing custom software is the opposite of the foregoing.

  1. More expensive
  2. The demands on the own organisation are greater because extensive specifications have to be supplied. After the software has been developed, testing has to 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 it is not under 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.