WO1996006402A1

WO1996006402A1 - Portfolio performance analysis system

Info

Publication number: WO1996006402A1
Application number: PCT/CA1995/000491
Authority: WO
Inventors: James A. Knowles; Toomas J. Teder
Original assignee: Financial Models Company Inc.
Priority date: 1994-08-23
Filing date: 1995-08-23
Publication date: 1996-02-29

Abstract

A method of analyzing the performance of a plurality of investments provides both portfolios and benchmarks and enables a user to choose the structure of each, as well as the structure of an attribution model linking them. One or more portfolios are defined, and for each, a class scheme is defined having a variety of nodes, each of which represents an asset class. The nodes can have subsidiary nodes as desired. Each investment is assigned to a respective asset class. At least one market index, which may be a composite of known indexes, is established for monitoring the performance of the investments. A benchmark is defined including at least one market index and including a plurality of separate nodes, each representative of investments of a known type. Again any node structure can be defined and it need not correspond exactly to the node structure of the class scheme. An attribution model is set up linking desired nodes of the class scheme with nodes of the benchmark, whereby the performance of individual asset classes of the portfolio can be analyzed.

Description

Title: Portfolio Performance Analysis System

FIELD OF THE INVENTION

This invention relates to portfolio management systems, and more particularly is concerned with portfolio performance analysis systems enabling comparison of portfolio performance with a known benchmark.

BACKGROUND OF THE INVENTION

Currently, there are large amounts of funds managed by professional money managers. For example, pension funds of various types and mutual funds have large amounts of assets at their disposal. Managers of such funds are usually given some mandate or direction as to how the funds under their control should be managed. This usually depends upon a number of factors. For example, pension fund managers will often have a mandate to invest a particular fund in a particular country, or to invest in equities, bonds, or a certain prescribed mix of equities and bonds. Thus, the manager could be given directions according to geographic criteria, type of financial instruments and others.

Clearly, a key issue is the rate of return that the fund achieves. Since any one fund will typically hold a large variety of investments, which will comprise different financial instruments, in different currencies and in different countries, this presents a difficult problem in evaluating the performance of the fund. For example, in any given period, one could see a significant gain in for, for example, bonds, equities in a particular field, and currency gains for investments in a particular country.

Now, both fund managers and principals responsible for a fund and hiring the management team need to have some way of managing and judging the performance of the fund.

Managers themselves wish to know the performance of the individual sectors of the fund, so that they can make decisions as to whether o buy or hold certain investments. For example, they need to know that the fund's strong performance was due to a strong performance of a significant holding in transportation equities, even though bonds held by the fund were performing indifferently. Similarly, it is important to know that, for example, strong performances of South American stocks were simply due to currency effects, rather than strong gains on local South American stock markets. The process of determining the causes of performance is known as performance attribution.

In many cases, fund managers are advised that their performance will be measured as against some known benchmark and this is in effect the criterion determining how the fund will be invested. For example, a Canadian pension fund manager could be advised that the funds should be invested principally in Canadian equities, and that the performance would be measured as against the TSE (Toronto Stock Exchange) 300 Index. This is a simple example. In many cases, fund managers will have a wide mandate, and it may be necessary to derive some composite index for comparison purposes. Thus, the composite index could include a mixture of both equities and bonds and encompass both domestic and foreign investments. Such a composite index could be derived by taking various available indexes and combining them with appropriate weightings.

The fund's performance could then be measured against such a composite index, and one then obtains an idea as to how well the fund manager is performing. It is expected that a good manager should outperform the composite index, while consistent underperformance suggests that the manager should be replaced, or possibly that the whole investment strategy for the fund needs to be reviewed. In some cases, the fund manager's income will be tied to the fund's performance relative to such an index, so that accurate measurement of such over or under performance is critical. One should also bear in mind that a portfolio management team may manage hundreds of different funds, so that it is important to know the performance of each individual fund, and to break down or disaggregate or breakdown the performance, to determine which investment decisions were good and which were bad over any particular time period.

This desire to monitor the performance of any particular portfolio or fund is widely recognized, and proposals have been made for computer-based portfolio performance analysis systems. However, known systems suffer from a number of disadvantages. Typically, they are restricted and inflexible, and do not cover all possible variables. For example, calculation of portfolio performance attribution results over one month is a simple matter, but known systems do not adequately, or at all, address the issue of covering a multi-year performance attribution analysis.

A common problem with known systems is that they have a fixed structure, forcing the user to fit their own actual portfolio into this fixed structure or classification scheme. In many cases, this necessarily implies severe limitations on the disaggregation or breakdown of the performance of different sectors of the portfolio.

Correspondingly, a common problem in known systems is inflexibility in the benchmark or market indexes against which the portfolio can be compared. Typically, a small number of pre-determined indexes are made available for comparison. The user is not given the possibility of defining their own composite index, relevant to a particular fund or funds.

A further common failing of known systems is the inability to deal with different currencies. Commonly, the ability to attribute any part of the performance to currency effects is not handled at all, or is handled inadequately.

Accordingly, it is desirable to provide a portfolio performance analysis system which has a great degree of flexibility. More particularly, it should be able to define any desired classification scheme for the portfolio, and it should also enable a user to define any desired benchmark based on available data. To maximize analytical possibilities, it should preferably enable the user to set any number of desired links between the benchmark and the portfolio, to enable the performance of the portfolio to be disaggregated or broken down for analysis purposes. More preferably, it should adequately cover currency effects and enable performance over lengthy time periods to be analyzed. It is well recognized that investment decisions can be made on a "top-down" or "bottom-up" management basis. In a "top-down" approach, the manager first selects certain asset classes for investment, and then picks individual securities for investment. In a "bottom-up" approach, the manager makes investment decisions primarily by first selecting securities, rather than asset classes. A common failing of known systems is that, what analysis is available, assumes a "top-down" approach. It is desirable that any portfolio can be analyzed from either a "top-down" or a "bottom-up" approach, at the user's discretion.

SUMMARY OF THE INVENTION In accordance with the present invention, there is provided a method of analyzing the performance of a plurality of investments, the method comprising the steps of:

1. creating at least one portfolio;

2. for each portfolio, defining at least one class scheme having a variety of nodes, each of which represents an asset class, and assigning each investment to a respective asset class;

3. creating at least one market index, for monitoring the performance of the portfolio investments; 4. creating a benchmark from at least one market index and including a plurality of separate nodes, each representative of investments of a known type; 5. defining an attribution model linking nodes of the class scheme of the portfolio with the benchmark, whereby the performance of individual asset classes of the portfolio can be analyzed.

Preferably, step (2) comprises for at least one portfolio, defining a plurality of primary nodes and a plurality of derived nodes, with each of the derived nodes combining a plurality of nodes selected from primary nodes and other derived nodes, and with the primary nodes being at the bottom of the class scheme, and further step (4) comprises, for at least one market index, defining a plurality of primary nodes and a plurality of derived nodes, with each derived node combining a plurality of nodes selected from primary nodes and other derived nodes of the respective market index and with the primary nodes being at the bottom of the respective market index.

Additionally, for at least one portfolio, the portfolio preferably has a respective base currency and includes a plurality of primary, local nodes, each of which is representative of investments denominated in a local currency which in some or all cases may be different from the base currency of the portfolio, with each local node being valued in both the base currency of the portfolio and the local currency; and there is at least one market index which is valued in a respective base currency and includes a plurality of local nodes, each of which is representative of investments in a local currency which may be different from the base currency of the market index, with each local node of that market index being valued in both the respective local currency and the base currency of the market index. The attribution model then enables disaggregation of investment-related effects and currency-related effects for asset classes representative of foreign investments as well as domestic investments.

The method can include a plurality of portfolios as base portfolios, and at least one merged portfolio, which comprises selected ones of the base portfolios, each of which is given a weighting based on its value at various points in time, with the weightings of the base portfolios summing to unity. BRIEF DESCRIPTION OF THE DRAWING FIGURES

For a better understanding of the present invention and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings, which show a preferred embodiment of the present invention, and in which:

Figure 1 is a schematic drawing of the portfolio performance analysis system of the present invention;

Figure 2 is a more detailed schematic drawing showing an attribution model link between a portfolio class scheme and a benchmark; and

Figures 3a - 3m show screens of a preferred implementation of the system of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

The system is intended for implementation on any suitable computer system. A preferred platform is a personal computer with MS-DOS and Windows. The system itself can be written in 'C++' language. Also as detailed below, it can be configured so that report data can be exported to an Excel spreadsheet or equivalent. It will nonetheless be appreciated that the system could be implemented using a wide variety of different computer hardware and software.

To provide a clear description of the system, the description below refers to exemplary screens which are in a Windows environment and to operation in such an environment, although again it will be appreciated that any suitable user interface could be used. Referring first to Figure 1, the overall portfolio performance analysis system is designated by the reference 10. The system shown in Figure 1 and described below is a general system including a number of different features, not all of which need to be included in any particula application or system. Thus, by way of example, the system is shown including a number of separate portfolios, at least one merged portfolio different attribution models, different benchmarks and a number of different market indexes. In its simplest format, the system could be implemented using a single portfolio, a single class scheme, a single benchmark based on just one market index, and a single attribution model linking the class scheme and the benchmark. This could be achieved without any need for the complexities of merged portfolios or composite indexes.

Individual portfolios are indicated at 12, and one portfolio 12 is shown in detail as indicated at 12a with it being understood that the other portfolios 12 would be similar. For each portfolio 12, a number of inputs are provided for data from the user. First, at 14 there is a portfolio raw data input. Currencies and exchange rates are input at 16 and 18 respectively. A class scheme input 20 enables a desired class scheme to be input while input 22 enables the node codes from an external accounting system to be input, for reasons given below. The system would have a base currency and each portfolio has its own base currency, which may or may not be the same, with portfolio base currencies input at 15.

Within each portfolio, as indicated for portfolio 12a, there are primary class scheme nodes 24, in accordance with the class scheme input through the class scheme input 20. Derived nodes 26 of the class scheme, are derived from the primary class scheme nodes 24, and further derived nodes 28 are derived from one or both of the derived nodes 26 and the primary class scheme notes 24. The node structure is explained in greater detail in relation to Figure 2 below. In most implementations, the user will already be tracking basic data on their investments on an accounting system. Such data typically include the quantity of each security or investment held, its current value and possibly also currency information. Accordingly the present invention will then rely on the accounting system to provide regular, e.g. daily, data for the investments. Such an accounting system is indicated at 25, and is connected to the raw data unit 14, the currency unit 16 and the external node codes unit 22, so that the relationship between the external node codes and the class scheme of the portfolio can be determined and the values from the accounting system are applied to the correct investments.

As indicated at 30, one or more merged portfolios can be provided, which are connected to the appropriate ones of the portfolios 12, for deriving a merged portfolio.

To generate appropriate benchmarks for comparison with the portfolio results, a market index is calculated as indicated at 40, and again 40a indicates one market index in detail. As shown, the market index 40a has an input for market index unit values and weights at 42, and for currency and exchange rates respectively at 44 and 46, the currency and exchange rate information being the same as that provided at the inputs 16, 18 for the portfolios 12. However, the currency and exchange rate information may not be needed, for example if portfolio base currency is the same as the system base currency and market index data is provided in both base and local currencies.

As shown in the detail of market index 40A, primary market index nodes 48 are calculated from the input data. Derived market index nodes 50 are in turn calculated from the primary nodes and further derived market index nodes 52 are derived from one or both of the primary market nodes 48 and derived nodes 50.

As shown at 60, one or more composite indexes can be provided. Each composite index would, in general, be calculated or derived from two or more market indexes. These can be derived in a similar manner to the market index. First, at 62 primary composite index nodes are calculated and derived composite index nodes are calculated at 64. Further derived composite index nodes 66 are derived from one or both of the primary nodes 62 and derived nodes 64.

By way of example, a composite index could be derived from an equity index as a primary composite component, and a bond index which itself is a composite index, i.e. a derived composite index. Such a derived index could be a composite of, for example, indexes from different countries. As indicated at 70, individual benchmarks 70 are derived from the individual market indexes or the composite indexes. A benchmark is defined in this system as a primary market index, a derived market index, a composite index, with a known performance and pre-defined fundamental characteristics, for the purposes of comparison with a managed portfolio for evaluation purposes. As indicated at 72, one or more attribution models are provided, each linking a respective benchmark 70 with a respective portfolio class scheme 20. As detailed below, the attribution models 72 produce attribution results and analysis 74.

Turning now to Figure 2, this shows an attribution model and links between a benchmark 70 and portfolio class scheme 20 in greater detail. The class scheme 20 is shown on the left hand side of the figure while the benchmark 70 is shown on the right hand side. By way of example and to obtain a greater understanding of the invention, this figure is described in relation to an exemplary portfolio class scheme and an exemplary benchmark.

The portfolio class scheme 20 has a domestic equity asset class 80 and a foreign equity asset class 81. The foreign asset class 81 is further broken down into subsidiary asset classes or nodes, representing different countries, for example, the United States at 82, Japan at 83 and Europe at 84. As indicated at 85, the European node or class 84 could be further broken down into individual countries, of which only one is shown. Note that the node 81 is a parent node since it is a derived node with the nodes 82, 83 and 84 as child nodes; the nodes 82, 83 and 84 are sibling nodes to one another.

The portfolio class scheme 20 also includes at 86, 87, 88 further asset classes, for example for domestic bonds at 86, American bonds at 87 and European bonds at 88. The benchmark 70, in this example, is a relatively complex composite index. It is made up by appropriate weightings determined in advance. It includes the TSE 300 index indicated at 90, to give a representation of expected performance of domestic or Canadian equities.

At 91, there is an index representing foreign equities, which have corresponding subindexes 92, 93 and 94 for, respectively, United States, Japan and Europe.

Here, it can be noted that the European index 94 is not further broken down. As explained in greater detail , this is not necessary, and it is not necessary for there to be a direct correspondence between each node or class of a Portfolio class scheme and each node of the benchmark. However where any node, of either a portfolio or benchmark is connected in the attribution model, then all other nodes in the class scheme in the same cluster, or 'sibling nodes', must be connected in the model.

At 95, 96, and 97, there are bond indexes, representative of domestic, U.S. and European bond markets respectively. As shown at 98 and 99, the U.S. bond index is further sub divided into, for example, categories for long term bonds and short term bonds.

Now, the attribution model is represented by dotted lines indicated at 100. Consequently, the correspondence between this particular portfolio class scheme 20 and benchmark 70 as indicated by the lines 100. The domestic and foreign equity asset classes 80, 81 are linked to the TSE 300 index 90 and the foreign index 91.

Each of the individual equity classes or nodes 82, 83 and 84 are correspondingly linked to the corresponding foreign equity indexes 92, 93 and 94. Note that since there is no index corresponding to the individual countries in Europe, as indicated at 85, there is no link for this asset class or node.

The bond classes 86, 87 and 88, are linked to the respective market indexes 95, 96 and 97. Here, the U.S. bond index 96 is provided with finer subdivision, into the long-term and short-term bond indexes 98 and 99.

However, since there are no nodes or asset class corresponding to these, in - li ¬

the portfolio 12, there is no link to the long and short-term bond indexes.

Having established the basic structure of the system, it is necessary to populate the portfolios and provide data for the market indexes, to enable benchmarks to be determined.

SETTING UP THE SYSTEM

In order to set up the system, a number of procedures must be carried out, which broadly could be broken down into initial set up procedures and regular or ongoing procedures. The initial set up procedures are generally implemented only once or infrequently, while the routine procedures are regularly implemented at set intervals.

The initial set up procedures comprise:

1. defining currencies for which exchange rates will be entered into the system;

2. defining the indexes and benchmarks to be used for performance comparisons and performance attributions by one or more portfolios;

3. defining or creating portfolio class schemes and attribution models;

4. defining or creating portfolios and merged portfolios and links between each portfolio and one or more class schemes and attribution models.

The regular procedures comprise:

1. entering currency exchange rates;

2. entering market index weights and unit values; 3. entering portfolio valuation and cash flow data (portfolio raw data);

4. calculating benchmark performance results and weights;

5. calculating portfolio and merged portfolio performance results and weights; and 6. calculating performance attribution results. CURRENCIES

Currencies can be created, viewed, modified, deactivated or deleted.

It is here noted that various objects in the system can be: deactivated; removed; or deleted, and these functions are applicable to individual objects as indicated. To "deactivate" an object means to make an object unusable from the effective date forward; to "remove" means to delete one or more instances of an object from the effective date; and to "eliminate" means to delete all instances of the object for all effective dates. As indicated in Figure 3(a), from the structures command in the main menu, currencies can be selected to give a master or currencies window, as shown in Figure 3(e). This gives the name, effective date and other information for each currency that has been defined. Figure 3(e) shows the use of user currency codes and a numerical currency code, in addition to the SWIFT code. Within this window, an update window can be opened, showing the effective dates for which exchange rates have been entered for the selected or highlighted currency, and an exchange rate window can be opened showing the exchange rates which have been entered for the highlighted or selected currency. A new currency can be added, while in the currencies window, by selecting the appropriate button to obtain an End Effective Date Data Box. The effective date entered should be the first date on which the countrv will become "active" in the system, and may be no more than one day earlier than exchange rates will first be entered for the new currency. The appropriate fields will appear in the currencies window and should be completed in known manner. The data is then committed to the system and currency module can be exited.

EXCHANGE RATES

To modify or enter exchange rate data, the currencie window of Figure 3(e) is selected, and the desired currency selected. The exchange rate and the new effective date for that currency are then altered. Further currencies and their exchange rates can be modified, by selection from within the currencies window. With all the exchange rate data edited as desired, the modifications or changes can be committed to the system.

Note that after modifying exchange rate data all the latest attribution results will be lost, and will need to be recalculated and confirmed.

Currencies can be deleted from within the main currency window of Figure 3(e). Where a currency is deleted, all related attribution results will be lost.

Currency information can be modified in various ways. For example, the country, country adjective and currency name can all be modified. The main currency window of Figure 3(e) is selected. The field to be edited or modified is selected for the chosen currency and the edit mode chosen. The effective date for the change is entered and the field value changed as desired; once checked and corrected it could be committed to the system.

MARKET AND COMPOSITE INDEXES

Turning now to market indexes and composite indexes, like currencies, they can be created, viewed, modified, or deleted. They can also be deactivated. A market index is a primary index or derived index representing the performance of a defined securities market or defined set of securities. In turn, a primary index is a market index which contains no sub- indexes, and is used as a building block for derived indexes and composite indexes; a derived index is defined to be an established market index which can be defined as the weighted sum of two or more sub-indexes, which sub- indexes may be primary indexes or may in turn be derived indexes. A composite index is a weighted combination of market indexes and /or other composite indexes, used as a performance benchmark for one or more portfolios. Each of the market indexes or composite indexes which collectively make up the entire composite index is a composite index component. A composite index is not hierarchical but inherits the hierarchies incorporated in its component market indexes. Thus, a composite index may be, for example, determined as: Index A .5

Index B .4

Composite Index C _L 1.0 The components in turn each represent a hierarchy of primary and derived nodes.

MARKET INDEX

The market index module is used to create a market index, and has four windows, namely a master or market index window, selected from structures in the main menu; the market index window is shown in Figure 3(f). The other three windows are a nodes window, which shows the code, name, short name, currency and effective date of each node of the sub- index and the selected index; a composite index references window, which shows the composite indexes which incorporate the selected market index; and an index data periods window, which shows the periods for which data have been entered for a particular market index.

Market indexes are created or added by a selection from the main menu and an effective date entered. The effective date is the first date as of which the index will become active and may be no earlier than one day after unit values and weights are first available. A blank record will appear in the market indexes window, for entry of index code, name, short name, and the local currency. It is preferred to include the word "Index" in the name. If the index is multi-currency, "multi-currency" designation should be used in the currency field. Otherwise, the single currency in which all local currency unit values will be denominated is presented. The index code will be used to identify the market index and all index raw data files entered. Consequently, it should use a code which is consistent with the codes used by a market index data supplier.

A new market index is invalid, and may not be used, until its nodes or sub-indexes have been entered as detailed below.

After the main record for the new market index has been created, a nodes window button is selected and an empty nodes window will open. The nodes for the new market index are then filled as follows.

An appropriate button is activated to create the record for the index root node. The Effective Date box is completed with a desired date.

Preferably, a default date appears, i.e. the effective date of the index main record, which may be used, or an alternative date inserted. A blank node record will appear in the nodes window, and the node code, the name, the short name, and the local currency for the new root node should be entered. As a system requirement, the code of the root node must be the same as the code for the entire index already entered as described above. If the index is unitary, i.e. it has just this one node, all the entries can be committed and the marked index module exited.

If child nodes are required, an appropriate create child button is activated. Again, the node code, name, short name or local currency for each node is entered. Sibling codes for the child code are created by clicking on the appropriate button and again entering the appropriate data. New siblings are placed in the index in the position immediately below the node which is highlighted when the create sibling command is issued. These steps are repeated until all the nodes of the market index have been entered correctly. The hierarchical relationship between the nodes and index are altered, only when the nodes window is refreshed.

When all the nodes in the index have been correctly entered with the appropriate hierarchical relationships and ordering, all changes can be committed.

The index code and node codes are required fields in market index raw data files. For simplicity, where possible, codes corresponding exactly to those used by an index data supplier should be used.

All indexes require raw data denominated in both system currency and the local currency, for each index node. It is not necessary or desirable to create different "versions" of a given index for use in attribution against portfolios with different base currencies. The system translates any benchmark used for attribution calculations into the base currency of the portfolio as the attribution calculations are carried out, using the appropriate exchange rate.

COMPOSITE INDEXES

Correspondingly, composite indexes can be created, viewed, modified, deactivated or deleted. From the main menu bar, under structures, composite indexes can be selected, to select the composite indexes module, and give the screen shown in Figure 3(d). Within this module, in addition to the master or composite indexes window Figure 3(d), three additional windows can be opened, namely: a components window which shows the market indexes or composite indexes incorporated into the currently highlighted composite index; a nodes window, which shows the code, name, short name, currency and effective date of each node in the highlighted composite index; and a composite index references window, which shows the composite indexes which incorporate the highlighted composite index.

The composite index is created by first creating a new main record. From within the composite indexes and module, the appropriate button or menu selection is made. In the Effective Date dialogue box, which is then opened, the effective date for the new composite index in the appropriate format is entered. Again, this date will be the first date on which the composite index will become "active" within the system, and may be no earlier than one day after unit values or weights are first available for the composite index and its component indexes. A blank record will then appear on the composite indexes window. Name, short name and a local currency for the composite index are entered. It is preferred to include the word "benchmark" or "bench" in the name. If the index includes components which are in different currencies, again it is preferred to use multi-currency in the designation of the currency field. Otherwise, the currency in which all local currency values are stored for all the composite index components should be entered in the currency field.

With the master record created, components can be added to the composite index.

Relevant buttons are used to record a component. The corresponding dialogue box is opened, and the effective dates for the components are entered. Usually, the default date which appears, namely the effective date the composite index main record, will be used. With the date selected, a blank record will appear. For convenience, the type and country of the benchmark to be used as a composite component is selected or highlighted. A benchmark is chosen to which this component is to be applied, and a "weight" field is highlighted and the weight for the new component is entered. This procedure is repeated for all components being added to the composite index with the appropriate weights. Note that the weights of the composite components must sum exactly to 1.

The nodes in a newly created composite index can be viewed from a nodes button. The nodes are inherited from the nodes structure of the composite components. The index contents and structure can be confirmed by running a class scheme report of the new composite.

When choosing a composite index structure, it should reflect the investment policy of the portfolios to which it is to be compared, and should, if possible, incorporate all of the asset classes in the portfolio. The basic currency field of a new composite index is used only to facilitate selection of the composite from the assigned benchmark dialogue box. It does not affect the way in which the performance results are calculated, and when node weights are calculated and stored, as local currency values are inherited from the composite indexes components.

Composite indexes may be "nested" i.e. composite indexes may in turn be components of a larger composite indexes. The same component may appear more than once in a composite index.

Both market indexes and composite indexes can be modified. A market index may be modified, to change the index name or short name, or to change a node name or short name. Also it may be modified, if the structure of the index changes, resulting in a need to add or deactivate nodes, or if the index is no longer needed for performance attribution or other purposes. Within the market index module, names of fields can be edited. By selecting an appropriate button, an index can be deactivated, removed or eliminated, as defined above.

Again, deactivation may, and removal or elimination of a market index will, result in loss of data.

Correspondingly, nodes can be added to a market index, as well as deactivated, removed or eliminated. Nodes are added by selecting a node immediately above the desired location of the new node, and then adding the new node as a child node to the existing node. Alternatively, it can be added as a sibling, if the new node is to be a sibling of the selected node. The effective date and other information of the new node should be entered. Again, deactivation, removal or elimination of an index node will usually result in loss of index data and any associated composite index and related attribution results. A composite index may be modified, to change its name or short name, to change the weights of individual composite components etc. and to add, deactivate or delete composite components, as a result of, for example, changes in the investment policy of a portfolio. This is achieved within the composite index window and /or composite components window of the composite index module. A composite index can be selected and its name edited as desired, and an effective date must be entered. Composite indexes can be deactivated, removed and eliminated. This can lead to loss of data.

Addition of a composite component to a composite index is done within the composite components window of the composite index module. An appropriate button is selected to create a record, and an effective date is entered for the new component. A dialogue box for the Assign Benchmark Name will open, and the type and country of the benchmark to be used as a composite component is highlighted. Then, an "apply" function is chosen and all benchmarks for the chosen type and country are displayed. The benchmark to be used as a component is chosen.

The weight for the new component is then entered. These steps can be repeated for all new components.

The components of a composite index can have their weights changed and can individually be deactivated, removed or eliminated. Elimination of a composite index or any of its components results in the loss of related composite index performance data and performance attribution results.

PORTFOLIO

Turning to the creation of the portfolio, the portfolio module is opened by selecting portfolio from structures in the main menu, to give the screen shown in Figure 3(g). This shows the name, base currency, portfolio type (e.g. base or merged portfolio), the transaction basis date

(settlement or trade date) and the effective date of each portfolio. Within this module, additional windows that can be selected are: class scheme references window which shows the name, the effective date and the dates for which raw data have been entered for each class scheme linked to the selected portfolio; a raw data periods window, which shows the periods for which portfolio raw data have been entered for the currently selected portfolio and class scheme; portfolio components window, which shows the portfolios which are components of the currently selected merged portfolio; and merged portfolio references window, which shows merged portfolios in which the currently selected portfolio is a component.

From within the portfolio module, a portfolio can be created, and again an effective date is entered, which would normally be the first date for which raw transaction data are available (and, possibly, one day after

"start-up" market values are available.) A name, base currency, transaction date basis and portfolio type are entered.

As detailed below, the portfolio will then need to linked to one or more class schemes and attribution models. Usually, the portfolio base currency will be the currency of the country in which the portfolio is domiciled. Each portfolio must have a unique name.

A merged portfolio can be created in a similar manner. However, the portfolio type is selected as "merged" whereas "base" is selected for a regular or base portfolio. As for the base portfolio, it should then be linked to one or more class schemes, with an effective date for each link, usually the effective date of the portfolio.

Components can be added to the merged portfolio. For each component, an effective date is entered. It can be noted that all components of a portfolio must be linked to one or more class schemes used by the merged portfolio and all component portfolios must have their performance measured on the same dates at all times.

CLASS SCHEMES To create a class scheme, "class scheme" is selected from structures in the main menu, to open the class schemes module. The main window of this module is shown in Figure 3(c). Other windows available are: a nodes window which shows the code, name, short name, currency an other information for each node in the selected scheme; a portfolio references window which shows the portfolios which are linked to the selected schemes; and an attribution model references window, which shows the attribution models which are linked to the selected scheme.

To facilitate performance attribution, class scheme structures are created using a benchmark as a "template." This is done using the same "Benchmark Component" dialogue box described above in the sections of

Composite Indexes. This ensures that the class scheme and benchmark have corresponding structures.

For all the nodes in the class scheme, a name and a shortname are attached, which is usually different from those in the corresponding benchmark nodes.

The following information will also be attached to primary nodes in each class scheme: the external accounting system classification scheme used to "feed" this node (this may be a "placeholder" if the portfolio accounting system does not have a corresponding asset class; i.e. the external node code used in the portfolio accounting system to define the asset class represented by the scheme node) .

Node types may be one of the following: total portfolio, for portfolios with securities /currencies only; total portfolio with cash, for portfolios with one or more cash balances; non-cash, for all asset classes except total portfolio and cash balances; and cash (there may be several of these in one classification scheme).

To create a class scheme, individual records are added with an effective date followed by appropriate dialogue box. The effective date should be the first date as of which raw portfolio data will be entered using this class scheme. It should be no earlier than the effective date of the benchmark on which the class scheme is to be based. Following entry of the date, a new class scheme dialogue box opens, and a name and a shortname for the class scheme are entered. It is generally preferable to include the word "scheme" in the name. If performance attribution is to be carried out using the scheme, i.e. the scheme will be used for more than just performance measurement, a name for an attribution model is then entered, which should generally include the word "model" in the name.

Then, an index button is selected, and an assign benchmark name dialogue box opens. The type and country of the benchmark to be used as a template is selected. The function "apply" is then effected, to list the benchmarks corresponding to the selected country and type. Then the desired template benchmark is chosen from the list. If any of the schemes or model names of the template benchmark are incorrect, the appropriate steps are repeated. Then the new class scheme is created and a record inserted in the class schemes window.

To define or modify the nodes in an existing or new class scheme, a nodes window in the class scheme module is opened, and the appropriate field selected and edited. An enter effective date dialogue box will open. To change, i.e. deactivate or change the name of, a node in an existing class scheme, the effective date of the change is entered, and must be no earlier than the default date shown.

For a node in a new class scheme, if it is a primary node, the external scheme code, the external node code, the local currency of the node code type must be entered. For a node in an existing class scheme, either a name, the external scheme code or the external node code may be changed without loss of data. A change to the node type or currency will entail deletion of all portfolio raw data, performance results and performance attribution results based on their class schemes, from the effective date of the change forward. The system then assumes that all changes are for the currently entered effective date until a commit command is issued. When the commit command is complete, the system will require the reentry of an effective date before allowing further changes to the scheme or node. Cash nodes do not require an external scheme code or external node code. Only the names, the local currency and the node type need to be entered.

The class scheme may be modified, to change the name of the scheme or the scheme node, if the structure or related benchmark is changed, or to add, deactivate or delete nodes to allow more or less detailed performance measurement.

To change the name or short name of a class scheme, the class scheme module is opened, the desired class scheme selected and the edit mode entered. The effective date is entered in the appropriate dialogue box, and then the change of name entered.

Class schemes may be deactivated, removed, or eliminated from within the class scheme modules. Similarly, the name or short name of a scheme node can be changed, and a node may be deactivated, removed or eliminated.

A node can be added to a class scheme from within the class scheme module. The nodes window is opened and a node selected. If the selected node is to be a parent node, then the new node is added as a child node, while if the selected node is to be a sibling, the new node is added as a sibling node. Then, the effective date is entered, together with the name, short name, currency, and other data for the new node.

It should be noted that name changes result in a new instance of the class scheme, if the effective date entered is different from the effective date that is current to the time of the change. However, if the change is made as of the current effective date, the old name may not be recovered once the name of the scheme or node is changed.

Deactivation or removal of the scheme will result in the loss of all data stored under the scheme, including portfolio raw data, performance data and performance attribution results, from the effective date of the deactivation /removal forward.

Elimination of a class scheme will result in loss of all data stored thereunder for all dates.

Sibling nodes may not share the same name or short name. Nodes may not be moved without loss of data. To effect a partial "move", a node should be deactivated at its initial location and then added to the node of a new location.

Deactivation or removal of a class scheme node will result in the loss of all data stored in the nodes of class scheme, including portfolio raw data, performance data and performance attribution results, from the effective date of the deactivation or removal forward. Elimination of a class scheme node will result in loss of data.

ATTRIBUTION MODELS

An attribution model is created using the attribution models module, which is selected, again, under structures of the main menu. The main attribution model window is shown in Figure 3(b). This shows name, status and effective date of each attribution model.

Within the attribution model, initial windows that can be selected are: a nodes window which shows the benchmark node name, the class scheme node name and other information for each node in the selected model; a portfolio references window which shows portfolios which are linked to the selected model and the attribution model information window, which explains the status of the currently selected model, including reasons for any invalidity.

Attribution models are most efficiently created simply by specifying a name for the model when the related class scheme is created from a benchmark template. When this is done, the system creates the model automatically, with no further intervention from the user. Alternatively, to create an attribution model independently, the main record of the attribution model is first created, within the attribution model module. The enter effective date dialogue box will open, for entry of the effective date of the attribution model. The effective date should be the first date on which the attribution model will become active and may be no earlier than one day after unit values and weights are first available for benchmark and class scheme(s) which are incorporated into the model. A blank attribution model record will appear in the attributions model window. A benchmark is then assigned to the model by choosing from the benchmark field and the class scheme by choosing a scheme from the class scheme field. For the class scheme and benchmark selected, a new attribution model can be committed. The nodes window shows nodes in the benchmark that are assigned to the model and blank cells indicating that corresponding class scheme nodes are not yet assigned. Class scheme nodes can then be assigned to corresponding benchmark nodes, as required.

The node assignments completed above are confirmed and the model is now valid. The model content and structure can be confirmed by running a model report.

It should be noted that not all nodes in the benchmark or class scheme need to be incorporated in the attribution model. However, if a node is used, all other sibling nodes should be used, for the model to be valid. Thus, for example, in Figure 2, with nodes 82 and 92 linked, then nodes 83 and 84 must also be linked, for the model to be valid.

A single portfolio class scheme may be linked to several different benchmarks to create multiple attribution models for the same scheme. The benchmarks must have compatible structures, at least to the node level, which is used in the attribution models.

An attribution model can be modified, for example: to change the model name; if the model is no longer needed; if the model is invalid due to a change in structure of the associate class scheme or associated benchmark, resulting in model nodes needing to be linked or delinked; the model is to be restructured to increase or decrease the amount of detail provided in its attribution results, so that model nodes need to be linked or delinked; or one or more benchmark nodes in the model have been linked to incorrect class scheme nodes.

It is important to ensure consistency between benchmark structures and class schemes. When a market index changes its structure, the changes are "cascaded" to each composite index which incorporates the market index, and all attribution models which are linked to the market index and its associated composite indexes. The changes are not, however, cascaded to class schemes which are also linked to the same attribution models. Correspondingly, structural changes to a class scheme are cascaded to any related attribution models but not to the associated benchmarks. Consequently, structural changes to either the class scheme or the benchmark in an attribution model may invalidate the model as of the date of the changes. Portfolios linked to an invalid model will not be updated when performance attribution results are calculated.

Invalid attribution models may result in warning messages appearing in an attribution results log file. If this occurs, the status for the models should be reviewed. The system has a function of enabling reasons for validation to be listed. If benchmark nodes exist which are not linked to corresponding class scheme nodes, the class scheme or the benchmark, or both, have been altered in structure.

If both the class scheme and the benchmark have been altered, the nodes window is opened. If benchmark nodes appear which are not linked to class scheme nodes, the linked nodes are highlighted and the dialogue box opened for the same class scheme node. The class scheme node to be linked to the benchmark node is then highlighted and confirmed. This is repeated for all benchmark nodes to correspond to class scheme nodes.

If one but not both of the class scheme and the benchmark are to be changed in structure, the attribution models module should be closed and the necessary changes made in the appropriate module The attribution's model module is then reopened and the steps of connecting or disconnecting class scheme and benchmark nodes is carried out as indicated above.

Portfolios must be linked to one or more attribution models before attribution results can be calculated. This is carried out in the portfolio module (Figure 3(g)) The record-create function is used to open the enter effective date dialogue box. The effective date for the link is entered, which should be no earlier than the latest of the effective date of the portfolio and the model. The attribution model is then selected and committed. It should be noted that to be linked to an attribution model, the portfolio must first be linked to the class scheme referred to by the model. Portfolios may be linked to any number of attribution models, and portfolio- model links may be deactivated, removed or eliminated.

Data Format and Data Loading

First, it is necessary to establish exactly what data needs to be supplied and stored. The data, very generally, is broken down into historical data, i.e. data with dates in the past, and current data, i.e. data for updating the system at regular intervals. Considering first data formats, for the exchange rates, the system uses three letter SWIFT codes, to identify each currency, as shown in Figure 3e. The exact three letter codes are not critical, but by way of example, CAD equals Canadian dollars, DEM equals German marks, etc. Data is input in an exchange rate raw data file, with each line containing three items, namely: the SWIFT code; exchange rate; and effective date. The exchange rate for each currency equals the number of units of system currency per unit of the specified currency. The three items on each line are separated by commas.

The system requires that data for all active currencies in each period be entered.

Concerning raw data for the market index files, these are set out below in an example of a typical market index structure, for an international equity index.

The index is named International Equity, and is identified by the Index Code INTEQ as indicated in the title above. The index is three levels; the first or root node being the total, identified by the node code INTEQ. The second level being two regions, identified by the code INTEQRl, and INTEQR2; the third level is 20 countries distributed betwee regions 1 and 2, and each node or country is identified by a unique node code an alphanumeric of up to 12 characters. The currency code "99" is used for derived nodes, such as th regions and the root node, which have child nodes with multiple loca currencies, and hence whose own local currencies are therefor indeterminate.

A market index raw data file contains the following items: Index Code;

Node Code; Effective Date; End-Effective Date; Local Currency Unit Value; Local Currency Weight;

System Currency Unit Value; and System Currency Weight.

The effective date is the first day of the period (e.g. of th month) and the end-effective date is the last day of the period. If the perio is a single day, the effective and end-effective dates will be identical. Thes two dates must also occur within the same month. The effective date mus be exactly one day following the previous period's end-effective date for tha index. It is necessary to enter an end of the month record for all indexes i every month. As noted above, the index code is the code for the relevan index, while the node code is the code associated with the relevant node i the market index structure.

The "local currency" unit values and weights refer t quantities measured in the local currency for that node. Thus, the exampl given above these would be with respect to the relevant currency for eac country. Correspondingly, the "system currency" unit values and weight are quantities measured with respect to the system currency as opposed to local currency.

Unit values and weights are as of the end-effective date, and are straight forward for primary nodes, i.e. individual countries as in example above. The local currency weight is normally the same as the system currency weight.

For derived nodes, e.g. the regions or the index nodes as a whole, in the example above, local and system currency values for derived nodes should reflect the weights and returns of the child nodes.

Node weights are specified as a proportion between 0 and 1. Weights are expressed as a proportion of the total index not as a proportion of the node's parent. Thus, the weights across any level of the index will sum to 1.00.

Turning now to the data for the portfolio files, as stated above, this could comprise historical unit values and raw data representing current values. Portfolios' historical data are loaded according to the following file format.

Portfolio Historical Unit Values Data File Format

File Format For Historical Asset Unit Values Load File:

Field Format Size Optional

Portfolio code character max. 12 no

Class scheme code character max. 12 no

Class scheme node code character max. 12 no

Unit value type (Al or AC)" character fixed 2 no

Effective date yymmdd fixed 6 no

End effective date yymmdd fixed 6 no

Local currency TR** number variable no unit value Base currency TR number variable no unit value

TR node weight number variable no

Local currency PR* number variable yes unit value

Base currency PR number variable yes unit value

PR node weight number variable yes

* Al = accruals treated as income, AC = accruals treated as capital ** TR = total return

*** PR = price-only return; enter these only if you calculate price-only returns

"AC" values and "Al" values should appear on separate (successive) lines in the data file Price-only returns exclude the effect of dividends and /or interest received from investments in securities. Thus, they reflect only the changes in price of the securities.

In general, historical data should only be entered where it is desirable to carry out any sort of analysis in an earlier time frame. Otherwise, the portfolio can simply be established at an effective date, then updated regularly.

A portfolio raw data file contains one on more data blocks.

Each data block contains data for a total portfolio and for each node or class in the portfolio, as defined under one or more class schemes, for a single period. Consequently, if a portfolio is linked to several class schemes, it may require several data blocks for each unitization period.

Cash is considered to be the pool of funds which are used to fund purchases, to receive the proceeds of sales, and to hold and pay income received or paid out. There can be a cash balance for each currency which the portfolio uses for transactions. When the system is presented with a class for cash, it expects transaction information of two kinds, which can be termed direct and indirect. Direct transactions are cash contributions and withdrawals, interest received on cash (or paid on overdrafts), and fees and other charges. The primary reason for these transactions is to modify the cash balance.

Transactions which affect cash indirectly are security purchases and sales anywhere in the portfolio, carried out using a particular currency, and any dividends or interest received or paid. The primary purpose of these transactions is in order to modify security positions or because of previously established security positions, not to change the cash balance. Both kinds of transactions are used in order to compute a return for the cash balance.

Non-Cash

Everything other than cash is a non-cash class. The value of a class changes over time due to two reasons, changes in the prices of the securities in the class and changes to the holdings of the class through purchases and sales. Income can be either or both of realized income or accrued income. The two are entered separately. Derivatives, including futures and currency forwards, are usually treated as non-cash securities.

Income The system uses income in two forms, realized and accrued.

Realized income is further distinguished as positive and negative. Positive income is income received by the portfolio and negative income is paid out by the portfolio. The accrued income is given as a gross figure, that is to say it is computed for the holdings as of the period ending date (the same date as the market values).

General considerations

1. Any transaction which will change the market value of the portfolio is included. Usually, these will be purchases and sales. A stock split is not explicitly included, as the change in shares is offset by the change in the unit price of the security. A stock dividend however is included as a purchase, with the cash value of the dividend recorded as income.

2. Transactions are considered at market value, not book value, for the purpose of computing performance. Book values reflect the price(s) at which securities were purchased in the past. Book values of transactions are collected separately as a consistency test (previous period ending book value + book value of purchases - book value of sales plus book value adjustments = the period ending book value). If not available, book values should be entered as zero.

3. Cash transactions are recorded separately. If performance of cash is not to be measured, the records for cash do not have to be included.

If cash is being measured, any transaction which will cause a change in the portfolio's cash balance should be included. Transactions which directly affect cash are contributions, withdrawals, interest paid or received on cash, and management fees. All of these can be ignored if performance of cash is not being measured.

Recorded also in each of the cash records is a summary of all non-cash (security-related) transactions which affect that particular cash balance. The items summarized are the purchases, sales and income.

4. The cash balances must be consistent with the basis on which transactions are considered, namely trade or settlement date. If only settlement date cash balances are available, and purchases and sales are being gathered on a trade date basis, the cash balances must be adjusted for any outstanding or unsettled trades as of the end of the period.

5. If management fees and other portfolio expenses cannot all be identified separately in order to record them in the cash record, they can be treated as cash withdrawals (or contributions if appropriate). Note that performance after fees cannot be computed in such a case. Also note that in order to take fees into account in measuring performance, cash must be measured, as the fees are entered in the cash records. The effect of management fees will be attributed to the cash class. If the fees should be attributed to some other class, do not enter the amount of the fees in the cash record, but instead record the fees as negative income for the required class.

Specific circumstances Security Reclassifications

Occasionally, a security will move from one class to another. This can happen in an equity portfolio when the industry classification of a company is changed (for example, the way that a stock is classified in a market index). In a fixed income portfolio which has classes based on term to maturity, the bonds will over time move to different classes as each bond's term to maturity decreases. The result is that a security that was in one class at a previous valuation, and is now in another class for subsequent valuations.

Without any transaction to record such a move, the computed performance of the two classes will be biased by the sudden changes in value. The old class is suddenly lower in value while the new class is suddenly higher in value. To allow for this, the security is "sold" out of the old class, at the market value as of the date of the move, and "bought" into the new class at the same market value. Since the purchase and sale are done at the same value, the two transactions net out to zero, and there is no cash effect. If the old and the new classes each have different local currencies, and a separate cash balance is used for each currency, then there is also a cash withdrawal from the old class of the amount of the sale, and a cash contribution to the new class of the amount of the purchase as well. Without the extra withdrawal and contribution, only total cash will be unaffected by the reclassification. The extra transactions ensure that each of the affected cash balances remain unchanged.

When a fixed income security is reclassified, the interest accrued to the reclassification date must be computed and recorded as positive income in the old class, and as negative income in the new class. This must be done in order to balance the change in the accrued interest computed as of the valuation date (the to-date), as otherwise the income for the old class will be understated, and overstated for the new class. Although the two amounts will offset each other so that there is no cash effect, the computation of the dummy realized accrued interest is required to avoid distorting the returns for the old and the new classes.

The day-weighted amount of the purchase, sale and accrued interest relating to a security reclassification are computed on the basis of the end of the day of the reclassification, rather than the middle of the day as is done for other transactions. The day-weighting factor becomes a

T where n number of whole days remaining in the measurement period T number of days in the measurement period

If for example the reclassification occurs on the 17th day of a 31-day month, the number of whole days remaining is 14, and the day- weighting factor is 14/31, or 0.4516. If the reclassification occurs on the last day of the 31-day month, the day-weighting factor is zero, and if it occurs on the first day of the 31-day month, the day-weighting factor is 30/31, or

0.9677.

Contribution or Withdrawal of Assets

If securities are contributed to the portfolio or transferred out without affecting the cash balance(s) of the portfolio, the transaction is recorded as a purchase or sale in the amount of the market value of the assets, along with an offsetting cash contribution (in the case of an asset contribution) or cash withdrawal (in the case of an asset withdrawal). The principal is the same as for a security reclassification. There must be a transaction to account for the change in the value of the class, because it is not due to security price changes.

The general rule is that if a transaction which has no cash effect has an effect on the holdings of the portfolio, it must be included, with appropriate cash transactions to offset the amount of the transaction, in order to preserve the level of the cash balance.

UPDATING DATA FILES

The following describes the format and contents of the periodic data file which is used by the system to update the valuation and cash flow table in the database.

A portfolio raw data file contains one or more data blocks. Each data block contains data for a total portfolio and for each node (class) in the portfolio, as defined under one or more class schemes, for a single period. Thus, if a portfolio is linked to several class schemes, it may require several separate data blocks for each unitization period.

The following is an example structure for the data blocks of the portfolio data file, and is repeated for each data block.

The first two lines of each data block are:

Record 1 PORT = portfolio code, BASE = currency code,

REQUEST -request ID

Record 2 FROM = from-date, TO-to-date, BASIS = T for trade or S for settlement, INCLASS = number of classes being entered into SYLVAN for this portfolio for this class scheme for this period. These two records provide general information about the data block which follows. The key word PORT = identifies the portfolio, BASE = is the code of the base currency of the portfolio, and REQUEST = is the Request ID, and is unique to each data block/ request instance and must be included. The request ID indicates the portfolio, the dates and the class schemes which are to be "fed" by the data block. All of these appear in the associated Download Request File.

The second record contains the effective and end-effective dates for the data block. The key word BASIS = is the transaction basis code used in the external accounting system when gathering the raw data. The final item, NCLASS =, is a count of the number of cash and class records that are to follow in the data block, and is used as a consistency test to ensure that the file is intact.

There are two records (described next as Record 3 and Record 4) for each class in the portfolio/ class scheme(s), so NCLASS is equal to two times the number of classes (nodes) which are active in the class scheme(s) and which appear (i.e. have non-zero market values and /or cash flows) in the portfolio during the specified period.

In each of the following record descriptions, the data items which relate to transactions always appear twice, once for the simple algebraic sums and once for the day-weighted sums of the transactions by class. The day-weighted value for each transaction is computed by adjusting for the time remaining in the measurement period (based on trade or settlement date). For a single class, this can be computed as:

sum.Ci * <[n+0.5j7T)

where

Ci = cash flow (each of purchases, sales, positive and negative income, cash contributions and withdrawals, and expenses, gathered separately) for each security in the class n + 0.5 = number of whole days remaining in the measurement period plus half a day, for each transaction T = number of days in the measurement period

Each type of transaction (cash flow) is gathered separately. The time remaining in the period is measured in days. A transaction on any given day is assumed to occur in the middle of that day (which gives the half day adjustment). The smallest value for the numerator of the factor in Equation 1 is 0.5 (for the last day of the period), and the largest value for the numerator is (for the first day of the period), thus giving a factor which is always non-zero, positive and less than 1.0.

As noted, reclassified securities are handled slightly differently. When a security is reclassified (i.e. moved from one asset class to another) in the portfolio accounting system, a sale transaction is generated to record the removal of the security from the old asset class, and a purchase transaction should be generated to reflect the introduction of the security into the new class. Such reclassification transactions are normally "priced" at closing prices for the day of the reclassification, and should be handled as though they had occurred at the end of the day.

There are then the records for a cash balance (the cash records appear before the class records):

Record 3 CASHBASE = code of cash balance currency, (which is portfolio base currency code), cash balance at to-date, contributions for period, day-weighted contributions, withdrawals for period, day-weighted withdrawals, positive income for period, 1 day-weighted positive income, 1 negative income for period, 1 day-weighted negative income, 1 fees and other expenses for period, day-weighted fees and other expenses, portfolio purchases using this cash balance for period, day-weighted portfolio purchases using this cash balance, portfolio sales using this cash balance for period, day-weighted portfolio sales using this cash balance, portfolio positive income using this cash balance for period, 2 day-weighted portfolio positive income using this cash balance, 2 portfolio negative income using this cash balance for period, 2 day-weighted portfolio negative income using this cash balance -

Record 3 is all in portfolio base currency.

Record 4 CASHLOCAL = code of cash balance currency, portfolio base currency code, cash balance at to-date, contributions for period, day-weighted contributions, withdrawals for period, day-weighted withdrawals, positive income for period, day-weighted positive income, 1 negative income for period, 1 day-weighted negative income, 1 fees and other expenses for period, 1 day-weighted fees and other expenses, portfolio purchases using this cash balance for period, day-weighted portfolio purchases using this cash balance, portfolio sales using this cash balance for period, day-weighted portfolio sales using this cash balance portfolio positive income using this cash balance for period, 2 day-weighted portfolio positive income using this cash balance, 2 portfolio negative income using this cash balance for period, 2 day-weighted portfolio negative income using this cash balance 2

Record 4 is all in the currency of the cash balance (local). Cash records are maintained separately from non-cash records because there may only be one cash balance for a given currency but there may be multiple non-cash nodes denominated in that currency.

The values for portfolio positive and negative income in any cash balance (indicated by 2 in the above description) do not include the income recorded in the values of positive and negative cash income (indicated by 1 in the above description).

The records for a non-cash class are:

Record 3 CLASSBASE = external scheme identifier,external class code, portfolio base currency code, market value at to-date, purchases for period, day-weighted purchases, sales for period, day-weighted sales, positive income for period, day-weighted positive income, negative income for period, day-weighted negative income, gross accrued interest at to-date (corresponding to market value), book value to correspond to market value, book value of purchases, book value of sales, book value adjustments

Record 3 is all in portfolio base currency.

Record 4 CLASSLOCAL = external scheme identifier,external class code, code of class local currency, market value at to-date, purchases for period, day-weighted purchases, sales for period, day-weighted sales, positive income for period, day-weighted positive income, negative income for period, day-weighted negative income, gross accrued interest at to-date (corresponding to market value), Record 4 is all in the class local currency.

Note that all of the items which appear in Record 4 CLASSLOCAL appear in Record 3 CLASSBASE. Record 3 CLASSBASE has four additional fields to carry book value information to be used by one of the input data tests (book value balancing).

Last records for a portfolio:

There is one summary record for the cash portion of the portfolio (all cash balances added together) labelled TOTALCASH, and another summary record for everything else in the portfolio, labelled TOTALPORT.

For cash:

TOTALCASH = portfolio code,portfolio base currency, cash balance at to-date, contributions for period, day-weighted contributions, withdrawals for period, day-weighted withdrawals, positive income for period, 1 day-weighted positive income, 1 negative income for period, 1 day-weighted negative income, 1 fees and other expenses for period, day-weighted fees and other expenses, portfolio purchases using this cash balance for period, day- weighted portfolio purchases using this cash balance, portfolio sales using this cash balance for period, day-weighted portfolio sales using this cash balance, portfolio positive income using this cash balance for period, 2 day-weighted portfolio positive income using this cash balance, 2 portfolio negative income using this cash balance for period, 2 day-weighted portfolio negative income using this cash balance 2

Record TOTALCASH is all in portfolio base currency.

For the rest of the portfolio:

TOTALPORT = portfolio code,portfolio base currency code, market value at to-date, purchases for period, day-weighted purchases, sales for period, day-weighted sales, positive income for period, 2 day-weighted positive income, 2 negative income for period, 2 day-weighted negative income, 2 gross accrued interest at to-date (corresponding to market value), book value to correspond to market value, book value of purchases, book value of sales, book value adjustments

Record TOTALPORT is all in portfolio base currency. The total portfolio purchases, sales, positive and negative income figures which appear at the end of the TOTALCASH record are the same as those in the TOTALPORT record. In both records, the total portfolio positive and negative income figures (indicated by 2 in the above description) do not include the positive and negative income amounts for cash (indicated by 1 in the above description). The fields appear in TOTALCASH to match the format of the CASHBASE and CASHLOCAL records.

The book value fields appear at the end of the TOTALPORT summary as well, to match the format of Record 3.

FORMULAS USED IN THE SYSTEM

The system uses a number of different formulas for analysis purposes, which can be broken down into four groups; 1. Asset weight calculations 2. Rate of return (unitization) calculations

3. Performance attribution calculations

4. Risk calculations

For uniformity and brevity, the following subscript notation is used: n denotes "in the native currency of the portfolio being evaluated"

1 denotes "in the local currency of the security or asset class" k denotes "of or pertaining to an asset class whose performance is measured in local currency" c denotes "of or pertaining to currency exposure in a multi- currency securities portfolio"

Asset Weight Formulas

Index asset class weights are the proportion of the index represented by a given asset class, as of the date the index value calculation is carried out. They may be based on any of a number of "size" measures such as issue capitalization, float, or issue size; or they may be arbitrary. They are determined by the index sponsor, for example, Morgan Stanley Capital International, Standard & Poors, the Toronto Stock Exchange etc., and simply recorded in the system, without adjustment.

Portfolio asset class weights are of two types: security weights and currency weights. They represent the portfolio weight of each asset class at the beginning of any particular measurement period, adjusted for purchases, sales and income occurring during the measurement period.

The products of security or currency weights, so measured, and corresponding security or currency returns for each asset class, sum exactly to the security or currency return of the entire portfolio.

Cash flow-adjusted security weights for each asset class are calculated as follows:

WP_ntk = (MV_ntk + AI_ntk + (DWP_ntk - DWS_ntk - (DWPI_ntk

DW YNNII_nnttkk))))))//ssuumm((WWPP_nnttkk))

where

WP_ntk = Cash flow-adjusted security weight during period t for asset class k MV_ntk = Previous period market value in native currency during period t for asset class k Al_ntk = Previous period gross accrued interest in native currency during period t for asset class k DWP_ntk = Day-weighted purchases in native currency during period t for asset class k DWS_ntk = Day-weighted purchases in native currency during period t for asset class k DWPI_ntk = Day-weighted positive income in native currency during period t for asset class k DWNI_ntk = Day-weighted negative income in native currency during period t for asset class k If income is ignored then asset class weights are calculated using the formula:

WP_ntk = (MV_ntk + Al_nt_k + (DWP_ntk - DWS_ntk))/sum (WP_ntk) These formulas assume that accrued interest is treated as capital. Cash flow-adjusted currency weights are calculated as follows: WP ntc ⁽WP_ntk * FP k )/ sum(WPn,k * FP_hk)

where

WP ntc Cash flow-adjusted currency weight during period t for asset class k

FPitk Return factor for portfolio asset class k in local currency during period t. [Please clarify why this is called "currency weight"

Rate of Return Formulas

Performance attribution requires that total portfolio and portfolio class performance be consistent, i.e. that the overall return of a portfolio be exactly equal to the sum of the weighted returns of its component asset classes, i.e. that:

RP_nt = sum(WP_ntk * RPntk)

FP_nt = (1 + RP_nt / 100)

where

RP_nt = Return for the portfolio in portfolio native currency during period t, in per cent RP_ntk = Return for portfolio asset class k in portfolio native currency during period t, in per cent P_ntk = Security weight for portfolio asset class k during period t (sum(WP_ntk) = 1) FPn_t = Return factor for the portfolio in portfolio native currency during period t

Many formulas can be used to calculate the return on portfolio asset classes. The preferred formula for non-cash asset class performance is:

MV_l + AU - (P_α - Sj - (Pli - Nl_α)) + (DWP_! - DWSi - (DWPl_α - DWNl,))

MVo + Alo + (DWPi - DWSi - (DWPh - DWN ))

where:

FPNi = return factor for non-cash asset class (FPNi = 1 + RPNiVlOO)

MVi = market value at end of period

Al_l = gross accrued interest at end of period

Pi = purchases during period S = sales during period

Pli = positive income during period

Nli = negative income during period

DWPi = day-weighted purchases during period

DWSi = day-weighted sales during period

DWPli = day- weighted positive income during period

DWNli = day-weighted negative income during period

MVrj = market value at end of previous period

Alo = gross accrued interest at end of previous period

The preferred formula for cash asset class performance is

CBι-(Sι-Pι+Cι-Wι+(Plι-N )-Fι)+(DWSι-DWPι+DWCι-DWWι+(DWPlι- DWNlι)-DWFι)

FPCi = CBo+(DWSι-DWPι+DWCι-DWWι+(DWP -DWNlι)-DWFι)

where:

FPCi = return factor for cash asset class (FP = 1 + RP /100)

CBi = cash balance at end of period

Si = sales using this cash balance during period

Pi = purchases using this cash balance during period

Ci = cash contributions to this cash balance during period

W i = cash withdrawal from this cash balance during period

Pl = total portfolio positive income involving this cash balance during period Nli = total portfolio negative income involving this cash balance during period Fi = total fees paid from this cash balance during period

DWSi = day-weighted sales using this cash balance during period DWPi = day-weighted purchases using this cash balance during period DWCi = day-weighted cash contributions to this cash balance during period DWWi = day-weighted cash contributions to this cash balance during period DWPli = day-weighted total portfolio positive income involving this cash balance during period DWNli = day-weighted total portfolio negative income involving this cash balance during period DWF = day-weighted fees paid from this cash balance during period CBo = cash balance at end of previous period

Portfolio returns can be disaggregated into security-related and currency-related components. These account entirely and exactly for portfolio performance during any period.

Security-related performance is measured in the local currency of each security class. It excludes the effects of exchange rate fluctuations over the measurement period.

FPSi, = 1 + ⁽sum⁽WP_ntk * RPitk) / 100)

where

FPSi_t = Security return factor for the portfolio in local currency during period t

WP_ntk ⁼ Security weight for portfolio asset class k during period t (sum(WP_ntk) = 1) RP_ltk = Return for portfolio asset class k in local currency during period t, in per cent Note that EPS and RP are both designated "1", i.e. are in the local currency, to exclude exchange rate effects, while security weights, WP, are in the native or base currency. Currency-related returns result from exchange rate movements during the measurement period, from the manager's decision to over- or under-weight particular currencies in the portfolio, and from the timing of the manager's intra-period movements into or out of particular currencies. By definition, they are measured in the native currency of the portfolio.

FPC_nt FP_nt / FPS_lt FPC_n, 1 + (sum(WP_ntc * RP_ntc) / 100) WP_ntc (WP_ntk * FP_ltk) / sum(WP_ntk * FP_ltk)

where

FPC nt = Currency return factor for the portfolio in portfolio native currency during period t

WP ntc = Weight for portfolio currency c during period t

RP ntc = Return for portfolio currency c during period t, in per cent

FPitk = Return factor for portfolio asset class k in local currency during period t The first equation indicates that the currency return factor FPC_nt is simply the ratio of the return factors for the portfolio in native and local currencies. Effectively, in the third equation the weight of the asset class is modified by the local return factor for that asset class, while ensuring that sum of all WP_ntc will be unity.

Total portfolio return can also be defined in terms of benchmark effects and management effects, which effects multiply together as indicated by the following equation: FPn, = FB_n, * SWF„ * SSF_h * CWF_n, * CTF_n,

where

FP_nt = return factor for portfolio in portfolio native currency during period t FB_nt = Benchmark return factor in portfolio native currency during period t SWFjt = Asset weighting effect factor in local currency during period t SSFi = Security selection effect factor in local currency during period t

CWF-_t = Currency weighting factor in portfolio native currency during period t CTF-_t = Currency timing factor in portfolio native currency during period t

Performance Attribution Formulas

The attribution factors (management effects) measured by the system include security-related and currency-related effects.

Security-related effects result from differences in the performance of the securities in the portfolio and the performance benchmark, net of the effects of currency fluctuations. They are measured in the local currency of each asset class.

To allow isolation of security-related effects from currency-related effects, securities denominated in different currencies (e.g. Japanese equities vs. French equities) must be allocated to separate primary asset classes in the portfolio, and valued in both their local currency and the portfolio native currency. Derived asset classes may contain securities denominated in multiple currencies. If, for the securities valued in a particular currency, valuation and cash flow data are not available in both native and local currencies, or if a separate primary asset class is not defined, only asset weighting and security selection effects will be measured. These will incorporate any currency-related effects. In a single-currency portfolio being evaluated relative to a benchmark denominated in the same currency, currency- related effects do not exist.

Currency-related effects measure the impact of exchange rate fluctuations on the performance of the securities in a portfolio. They are normally measured in the native currency of the portfolio; this is usually the currency of the country in which the portfolio is domiciled or, in the case of pension funds, the currency in which most or all of its liabilities are denominated.

These are discussed below in the following order: Asset weighting effect formulas

Security selection effect formulas Security timing effect formulas Currency weighting effect formulas Currency timing effect formulas Management effect formulas

Asset Weighting Effect Formulas

Asset weighting effects measure the impact, in local currency terms, of the manager's decision to over- or under-weight particular asset classes relative to the performance benchmark. For a given asset class, the effect is calculated as the difference between the actual security or asset class weight and the benchmark weight, multiplied by the benchmark return factor for the class relative to the return factor for the benchmark as a whole: SW, tk (WP_n,k - WBntk) * <(FB_hk / FB„) - 1) * 100

where

SWi_tk = Asset weighting effect for portfolio asset class k during period t, measured in per cent WB_{n k} = Asset weight for benchmark asset class k, period t (sum(WBntk) = 1) FBi_tk = Security return factor for benchmark asset class k during period t FBj_t = Security return factor for benchmark during period t The asset weighting effects for all classes in the portfolio sum to the total portfolio asset weighting effect. The total asset weighting effect factor for the portfolio can also be calculated directly:

S it sum(SWitk) S Fit (1 + sum(WP_ntk * RBuk / 100)) / FB_h

where

SW_jt = Asset weighting effect for portfolio during period t, measured in per cent SWF i_t = Asset weighting effect factor for portfolio during period t, measured in per cent RBl_tk = Security return for benchmark asset class k during period t, in per cent The asset weighting effect, as calculated above, assumes that weighting decisions are based on anticipated benchmark returns for each asset class. This implies a "top-down" approach to portfolio management, i.e. it assumes that investment decisions are based first on selecting particular asset classes, and secondly on selection of securities within the chosen asset classes, so benchmark returns are largely unaffected by the manager's security selection decisions. A "bottom-up" management process assumes that investment decisions are based first on selecting individual securities, and asset class selection is a secondary issue, i.e., that anticipated asset class returns and related weighting decisions incorporate the effects of the manager's security selection decisions, the asset weighting effect can be calculated as follows:

SW'nk = RP„_k * (WPntk - WB_ntκ) / (1 + sum(WB_ntk *

RP,_tk / 100)) SWF'u = FP_lt / (1 + sum(WB_ntk * RPitk / 100))

where

SW'i_tk = Security weighting effect for portfolio asset class k during period t, assuming "bottom-up" management SWFi_t = Security weighting factor for the portfolio during period t, assuming "bottom-up" management

These equations uses the portfolio return or return factor and the benchmark weights. The portfolio return for an asset class, as opposed to the benchmark return, give an indication of the manager's effectiveness in picking individual securities. The denominator is a return factor for a hybrid portfolio, based on the benchmark weights and portfolio returns.

Security Selection Effect Formulas

Security selection effects measure the impact, in local currency terms, of the manager's decision to invest in a) securities different from those making up each asset class of the benchmark, and /or b) the same securities as those in the benchmark, but in different proportions. Where performance attribution is carried out at the security level (i.e., the asset "classes" are individual securities), the security selection effect captures intra-period security timing and transaction cost effects.

For a given asset class, the security selection effect is calculated as the weight of the asset class in the portfolio multiplied by the return differential for the portfolio class relative to the benchmark class, all divided, again, by the return factor of the "hybrid" portfolio:

SS_ltk = WPntk * ⁽RPitk - RBitk⁾ / ⁽1 + sum⁽WP_ntk* RB k / 100))

where

SSi_tk = Security selection effect for portfolio asset class k during period t, measured in per cent WP_nt = Asset weight for portfolio asset class k, period t (sum(WP_ntk) = 1)

RP_ltk = Security return for portfolio asset class k during period t, in per cent RBj_tk = Security return for benchmark asset class k during period t, in per cent Security selection effects by class sum to the selection effect for the portfolio as a whole: SSi, sum(SSitk) SSF_lt FPit / (1 + sum⁽WPntk * RBι_lk / 100))

where

SSit Security selection effect for portfolio during period t, measured in per cent

SSFi_t Security selection effect factor for portfolio during period t, measured in per cent

FPit Security return factor for portfolio during period t, in per cent

If "bottom-up" management is assumed, the security selection effect is measured as:

SS* ltk WB_ntk * (RPitk - RBuk) / FB„

SSF' ltk (1 + sum(WB_ntk * RPitk / 100)) / FB_U

where

SS^'H Security selection effect for portfolio asset class k during period t, assuming "bottom-up" management

SSF'H = Security selection factor for the portfolio during period t, assuming "bottom-up" management

WB_ntk = Asset weight for benchmark asset class k, period t (sum(WB_n k) = 1)

FBit Security return factor for benchmark in period t

In effect, as compared to the first security selection formula above, the benchmark weight, instead of the asset weight, and the benchmark return factor, instead of the hybrid return factor are used.

Security Timing Effect Formulas

Security timing effects are analogous to security selection effects, but are based on information gathered at the individual security level rather than at the aggregate asset class level. See the Security Selection Effect Formulas section for details.

Currency Weighting Effect Formulas

Currency weighting effects measure the impacts of over- or under-weighting currencies in the portfolio (in most cases, by over- or under-weighting countries) relative to the benchmark. They are analogous to security weighting effects, in that they are based on the relative performances of each currency in the benchmark rather than the currency returns actually experienced by the manager. The effects of differences between the portfolio and the benchmark in their experienced currency returns are incorporated in the currency timing effect, defined separately.

For a given currency, the weighting effect is measured as the difference (between the portfolio and the benchmark) in currency weight, multiplied by the benchmark return factor for that currency relative to the currency return factor for the entire benchmark:

CW_ntc = (WP-t_c - WB_ntc) * ((FBC_ntc / FBC_nt) - 1) *

100

where

CW_ntc = Currency weighting effect for portfolio currency c during period t, measured in per cent WP_ntc = Portfolio weight for currency c during period t WB_ntc = Benchmark weight for currency c during period t

FBC_ntc = Currency return factor for benchmark currency c during period t FBC_nt = Currency return factor for entire benchmark during period t Thus, a positive weighting effect is obtained by over weighting an overperforming currency, or underweighting an underperforming currency.

The currency weighting effects for all classes in the portfolio sum to the total portfolio currency weighting effect. The total currency weighting effect factor can also be calculated directly as the ratio of the

"hybrid" currency return factor (based on portfolio currency weights multiplied by benchmark currency returns) to the benchmark currency return factor: CWnt sum(CW_ntc)

CWF_nt (1 + sum(WP_ntc * RB_nt_c / 100)) / FBC_nt

where

CW nt = Currency weighting effect for portfolio during period t, measured in per cent

CWF_nt Currency weighting effect factor for portfolio during period t, measured in per cent

RB ntc = Return for benchmark currency c during period t, in per cent

The currency weighting effect, as calculated above, assumes that the manager's currency weighting decisions are based on anticipated benchmark currency returns. If currency weighting decisions are more typically based on anticipated portfolio currency returns, the portfolio currency weighting factor is calculated as follows:

CWnt RP_ntc * (WPnt_c - WBntc) / (1 + sum(WB_ntc

* RP_ntc / 100))

CWF'_nt FPCnt / (1 + sum(WBntc * RPntc / 100))

where

CWnt = Currency weighting effect for portfolio currency c during period t, measured in per cent, assuming "bottom-up" management

CWF'_nt Currency weighting effect factor for portfolio during period t, measured in per cent, assuming "bottom-up" management Note that here again a hybrid factor, including benchmark weights and portfolio returns, is included in the denominator.

Currency Timing Effect Formulas

Currency timing effects result from the manager's intra-period movements into or out of the currencies represented in the benchmark and /or portfolio. They are analogous to security timing effects.

Timing effects tend to decrease in size as the unitization frequency increases (i.e., unitization periods become shorter). This is because managers cannot, over a period during which no cash flows into or out of a particular currency take place, "out-perform" that currency; currency-related return during such a period will be strictly a function of exchange rate movements. By contrast, a manager can out-perform the benchmark security return of a single asset class, even without transacting in that class, by virtue of having first selected securities which out-perform the securities in the benchmark.

In practice, as unitization frequency increases, measured currency effects will not change meaningfully in magnitude. However, a larger proportion of overall currency effects will tend to be the result of weighting decisions and a smaller proportion will result from timing decisions.

For a given currency, the timing effect is calculated as the weight of the currency in the portfolio multiplied by the return differential for that currency in the portfolio relative to the same currency in the benchmark, all divided by the "hybrid" currency return factor, which is calculated from portfolio weights and benchmark returns: CT_ntc=WP_ntc * (RPC_ntc - RBC_ntc) / (1 + sum(WP_ntc*RBC_ntc /100)) where

CT-_tc = Currency timing effect for portfolio currency c during period t, measured in per cent P_ntc = Portfolio weight for currency c during period t RPCn_tc = Portfolio return for currency c during period t

RBC_ntc = Benchmark return for currency c during period t The currency timing effect for the portfolio as a whole is the sum of the timing effects for individual classes:

CT_nt = sum(CT_ntc)

CTF_nt = FPC_nt / (1 + sum(WP_nte * RBC_ntc / 100))

where CT_nt = Currency timing effect for portfolio during period t, measured in per cent CTF_nt = Currency timing effect factor for portfolio during period t, measured in per cent If "bottom-up" management of the currency-related elements of the portfolio is assumed, currency timing effects are measured as: CT'ntc WBntc * (RPntc - RBntc) / FBCnt CTF'nt (1 + sum(WBntc * RPCntc / 100)) / FBCnt

where

RP ntc return for portfolio currency c during period t

CT' ntc Currency timing effect for portfolio currency c during period t, assuming

"bottom-up" management

CTF' nt Currency timing factor for the portfolio during period t, assuming "bottom-up" management

Management Effect Formulas

The management effect factor is the ratio of the portfolio return factor to the benchmark return factor. This definition assumes that the benchmark return is always available to the portfolio sponsor and requires no portfolio management skill. The management effect factor is also the product of security-related and currency-related management effects.

MEF_nt FPnt FB_n,

MEF_n, SEF_lt * CEF_n,

where

MEF_nt = Overall portfolio management effect factor in portfolio native currency during period t

FP, nt = Portfolio return factor in portfolio native currency during period t

FB nt = Benchmark return factor in portfolio native currency during period t

SEFi_t = Security effect factor in local currency during period t

CEF nt = Currency effect factor in local currency during period t Composite index results are calculated by opening the calculate module from the main menu. An entire composite index and its associated performance results can be deleted.

Alternatively, to delete the composite index results or related attribution results, without deleting the composite index itself, the composite indexes window is opened and when the appropriate composite index deactivated.

Portfolio and merged portfolio asset weights and performance are calculated from the calculate module. Within this module are the portfolios or merge portfolios can be selected for unitization. Attribution results are calculated from the data command. Performance attribution results may be deleted in several ways, depending on the circumstances.

To delete attribution results for a single portfolio, the portfolio module is opened and the attribution model links window is opened. The portfolio and attribution model for which results are to be deleted are selected.

If no attribution results are needed for the selected model /portfolio combination, the link between them can be eliminated and all associated attribution results will be deleted. If future results are not required but historical results are to be maintained, the link is deactivated.

To delete attribution results for all portfolios linked to an attribution model, the attribution model module is opened and the attribution model selected. If no attribution results are needed for the selected model, it can be eliminated. Again, if it is desired to maintain historical results only, then the model can be deactivated.

It can be noted that results are given attribution models are also deleted when results are linked portfolio, class scheme or benchmark are deleted. Attribution results for all models are deleted if exchange rates are deleted if exchange rates are deleted.

Reporting Overview

Reports are produced in Microsoft's EXCEL spreadsheet program, any report can be manipulated or analyzed in any way permitted by EXCEL without affecting the system database.

The system produces reports using five different report "views". A view encompasses one or more report types:

Report View Report Types

Exchange rates (1) Currency exchange rates Class schemes (1) Portfolio, index and composite index class schemes Attribution models (1) Portfolio and benchmark class scheme correspondence Benchmarks (3) As set w eigh ts, Perfo rm an ce, Performance contribution Portfolios (6) Raw data, Asset weights, Performance,

Performance contribution, Attribution analysis, Risk [details] ; some reports allow direct comparisons to benchmarks

When the report module is run, the main menu and the Report

Directory window appear first. The Report Directory window allows a user to:

(i) specify, run and save new reports; (ii) choose and run previously saved reports;

(iii) change the specifications of saved reports;

(iv) rename saved reports; and

(v) delete saved reports

Configuring Reports Class scheme and attribution model reports need little configuration, requiring only that the desired schemes or models be selected, and display instructions set (see below).

Exchange Rate, Benchmark and Portfolio report views contain a variety of user-controlled report elements, including date ranges, sort order, effect types, reporting currency and others. Configurable elements common to most of these reports include:

• Dates: From- and to-dates are entered. The system will report on as much data as it can find between the specified dates. Where report frequency is less than monthly (i.e., quarterly or annual), quarters or years are determined by working backwards from the latest month-end for which data are found.

• Report currency: Many reports can be produced in local currency, portfolio base currency or a third currency. Base currency may vary among portfolios. Reporting currencies are set in the Data-Currency menu.

• Sort order: Reports can be sorted by date, by portfolio, by class, by attribution effect, by currency etc. The sort order is chosen

10 using the sort drop box in the Data-Sort menu.

Graphs: Graphs can be included or excluded, and graph types and sub-types chosen, within the Format-Graphs menu. All graph

15 types available within Excel can be used.

• Number formats: The number of decimal places, use of commas to demarcate thousands etc. is set via a Data-Display menu. Microsoft Excel's formatting conventions are used.

20 For most reports, one decimal place is shown by default.

Display instructions: Reports may be displayed only; displayed and printed; or displayed, printed and deleted. Display instructions are set in

25 the Data-Display menu. Choosing and Formatting Excel Chart Types

Using the facilities of EXCEL, various chart types can be selected. For example, in EXCEL 4.0, area, bar, column, line, pie, radar, scatter, combination and a variety of 3-D charts are available. A chart type can be set in advance.

Exchange rate, benchmark and portfolio reports, as well as class scheme and attribution model reports can be run. The essential procedure in each case is to open the appropriate window and select, for example, the currency for an exchange rate report, and then run the report.

In the case of portfolio reports, it is necessary to choose a class scheme and attribution model used in the report.

Batch reports can be created by combining two or more individual reports. Benchmark performance can be reported in the local currency of the benchmark or benchmark node. Similarly, data can be reported in system currency or alternatively benchmark returns can be reported in any chosen currency.

Reports can be sorted at run time, so that desired parameters become the X and Y variables of a table.

If notable instances with third variable, for example portfolios, have been selected for inclusion in the report, a separate report table will be produced for each of these.

If charts are requested, a separate chart is produced for each table. Charts can appear on the left hand side of the report in the same vertical order of the report tables.

If several related data types are being reported, these would normally be displayed across the top, i.e. as columns of the table. User- sort preferences are dealt with next. First, a report change returns in two currencies for several classes, for several periods of time would be structured as follows: Batch Reports in SYLVAN

Batch reports are created by combining two or more individual (named) reports. The order in which the individual reports are run, displayed or printed is determined by their order in the list of batch report components.

A batch report may contain any number of individual reports, of any type and in any order. Individual reports may appear several times in a single batch report.

Performance Report Currency Choices Benchmark performance can be reported in the local currency of the benchmark or benchmark node, in system currency or in another selected currency.

Sorting can give various formats as follows:

1. Sorting by "X within Y" will produce a table with the "Y" variable (say, portfolio classes) across the top - in columns - and the "X" variable (say, dates) down the side - in rows.

2. If multiple instances of a third variable (say, portfolios) have been selected for inclusion in the report, a separate report table will be produced for each of these.

3. If a chart is produced, the columns variable will normally be the series variable also. In the example above, the chart would show a different data series for each asset class.

4. If charts are requested, a separate chart is produced for each table.

Charts appear on the left hand side of the report, in the same (vertical) order as the report tables. If several related data types (eg. several attribution effects, or performance in three different currencies) are being reported, these will normally be displayed across the top (i.e. as the columns) of the table. User-specified sort preferences are dealt with next. Thus, in the example in number 1. above, a report showing returns in two currencies, for several classes, over several periods of time, would be structured as follows:

Return in Return in

Period 1 Currency 1 Currency 2 Class 1 Class 2 Class 3

Return in Return in

Period 2 Currency 1 Currency 2 Class 1 Class 2 Class 3

etc.

Claims

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS.

1. A method of analyzing the performance of a plurality of investments, the method comprising the steps of:

1. creating at least one portfolio;

2. for each portfolio, defining at least one class scheme having a variety of nodes, each of which represents an asset class, and assigning each investment to a respective asset class; 3. creating at least one market index, for monitoring the performance of the portfolio investments; 4. creating a benchmark from at least one market index and including a plurality of separate nodes, each representative of investments of a known type; 5. defining an attribution model linking nodes of the class scheme of the portfolio with the benchmark, whereby the performance of individual asset classes of the portfolio can be analyzed.

2. A method as claimed in claim 1, wherein: step (2) comprises for at least one portfolio, defining a plurality of primary nodes and a plurality of derived nodes, with each of the derived nodes combining a plurality of nodes selected from primary nodes and other derived nodes, and with the primary nodes being at the bottom of the class scheme, and wherein step (4) comprises, for at least one market index, defining a plurality of primary nodes and a plurality of derived nodes, with each derived node combining a plurality of nodes selected from primary nodes and other derived nodes of the respective market index and with the primary nodes being at the bottom of the respective market index.

3. A method as claimed in claim 2, wherein, for at least one portfolio, the portfolio has a respective base currency and includes a plurality of primary, local nodes, each of which is representative of investments denominated in a local currency different from the base currency of the portfolio, with each local node being valued in both the base currency of the portfolio and the local currency, and wherein there is at least one market index which is valued in a respective base currency and in includes a plurality of local nodes, each of which is representative of investments in a local currency different from the base currency of the market index, with each local node of that market index being valued in both the respective local currency and the base currency of the market index, and wherein the attribution model enables disaggregation of investment-related effects and currency-related effects for asset classes representative of foreign investments.

4. A method as claimed in claim 2, which provides a plurality of portfolios as base portfolios, and wherein at least one merged portfolio is provided, which comprises selected ones of the base portfolios, each of which is given a desired weighting, with the weightings of the base portfolios summing to unity.

5. A method as claimed in claim 3, which includes a plurality of market indexes, and wherein at least one composite index is provided, with each composite index comprising selected ones of the market indexes provided with desired weightings with the weightings of the market indexes summing to unity.

6. A method as claimed in claim 4, which includes a plurality of market indexes, and wherein at least one composite index is provided, with each composite index comprising selected ones of the market indexes provided with desired weightings with the weightings of the market indexes summing to unity.

7. A method as claimed in 4, 5 or 6, wherein the attribution model provides for at least one of: determining asset weights; determining performance attribution results and disaggregating the results into investment-related and currency-related results; determining asset weighting effects according to at least one of the top- down and bottom-up management decisions; determining security selection effects according to at least one of the top-down and bottom-up management decisions; determining currency weighting effects, according to at least one of the top-down and bottom-up management decisions; determining currency timing effects; and determining management effects.

8. A method as claimed in claim 6, wherein the attribution analysis provides for analyzing at least one of asset weighting, security selection and currency weighting effects according to one of top-down or bottom-up management decisions.

9. A method as claimed in claim 1, 3 or 8, which includes the additional steps of routinely loading portfolio raw data, market index unit values, currency and exchange rates, to enable attribution results to be calculated.

10. A method as claimed in claim 9, wherein portfolio raw data is obtained from an external accounting system, and node codes for the external accounting system are provided, to enable proper assignment of portfolio data for individual investments.