PHP (Portfolio Management Expert System)
PHP (Portfolio Management Expert System)
Customer Pierson, Heldring & Pierson
(Amsterdam, The Netherlands)
Objectives
Development Status Developed and delivered a prototype in KEE on a TI-Explorer, during 1987

Highlighted features

1. SUMMARY

Pierson Heldring & Pierson (PHP), the Dutch bank for whom the system was developed is a merchant bank. It is a daughter of one of the biggest banks in Holland, the AMRO bank.
One of the PHP objectives is to be in the front line of information processing technology. AI has been one of their areas of attention over the last four years. In 1988 they found the technology sufficiently mature to bring it into practice within the bank.
UNISYS as their main supplier was asked to assist in the AI project.
The objectives for the AI project were:

  1. to get experience about how to build and use expert systems.
  2. to investigate the possibilities for continuation of the project.

At the start our first concern was to select a feasible project. There were many possibilities and after meetings with different department managers the "Clients Advisory Service" was selected. I will get back to what this department is about later, let me first tell you something about the criteria we used for project selection:

  • available and enthusiastic experts.
  • selection of a problem area of limited extent.
  • the current problem resolution structure.
  • the illustrative value of the system to be developed.

The Clients Advisory Service for which the system was developed gives personal investment advice to clients. It does this through structuring of information, the development of a market view and relating this view to the personal situation and the savings situation of the client.
The results of the project were: a prototype, a general report to position AI within the bank and education for PHP employees.
For development we used KEE (Knowledge Engineering Environment) from Intellicorp which is supported by UNISYS.KEE has several advantages over a less sophisticated environment:

  • it supports modelling and structuring of knowledge through frames and object oriented programming,
  • inheritance can be used to provide for dynamic relations between objects,
  • it supports the use of active values or demons,
  • it is easy to integrate with the AI programming language LISP (in which KEE itself is written),
  • it has an advanced graphics interface, both for the developer and the end user,
  • it provides good documentation,

With the facilities described above domain knowledge can be easily translated into a functional prototype.
Prototyping ensures intensive and in depth communication between experts, end users and system developers. In this way gaps and misunderstandings in the acquired knowledge become apparent at an early stage and can be solved in situ. Experts and end users are closely involved in the development process and are likely to regard the system as their own.

2. KNOWLEDGE ACQUISITION

In the process of knowledge acquisition we can roughly identify the following phases: orientation, think aloud protocols, structured interviews and focused interviews.
These are described below.

  • orientation
    • Get familiar with the domain
    • Gather information on the subject from books and other documentation.
    • Get a feeling for the job, the way things are done.
    • Limit the problem domain.
  • think aloud protocol
    • Which expert tasks can be identified
    • What are the relevant entities
    • Identify relevant information sources

In order to get familiar with the department, meetings were arranged with people at different levels. In this way we also ensured the broad support of people involved directly and indirectly.
About two days were spent with the experts in order to get a good understanding for the job, the circumstances under which they work and what information sources they needed to consult. It should be mentioned that in this case the experts are also the end users of the system.
The acquired "static" knowledge can be structured in KEE through creating and grouping of entities and defining their attributes.
The information sources that were needed for the system were made available through file transfers of selected data sets, in the next phase the development of the total system interfaces to these information sources will be built.

  • structured interviews
    • concepts, formulas, strategies
  • focused interviews
    • details, interdependencies

3. KNOWLEDGE STRUCTURE

The acquired "dynamic" knowledge can be represented as rules. There are ten independent rule groups. They address the following areas of portfolio management:

  • quality of stocks versus quality required and maximum risk accepted,
  • actual attractiveness of stocks in portfolio,
  • minimum post size,
  • relative size of blocks of stock,
  • fiscally attractive or unattractive investment instruments versus income tax rate,
  • actual percentage of bonds versus percentage recommended,
  • allocation per investment object,
  • yearly income from stocks versus yearly required income,
  • allocation per geographic region versus allocation recommended,
  • allocation per industry branch versus allocation recommended.

4. THE USER INTERFACE

The employees that are going to use the system do not all have the same level of expertise. This means that the system has to be able to communicate at different levels with the end users.
This is done with different levels of explanation about the system's generated advice.
In order to make the system easy to use and understand, KEE graphics are used to set up a user interface with self explanatory icons.


Sample screens

 

[TBD]

 

 

Fig.1:

 

[TBD]

 

 

Fig.2- Display of a conclusion, providing additional information when asked by the user



Return to the index