Portfolio Management - User Guide

Release R15.000
June 2015

©2015 Temenos Headquarters SA - all rights reserved.

Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may
result in severe and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents
Introduction 4
Purpose of this Guide 4
Intended Audience 4
Overview 5
Configuration 6
Portfolio Set up 7
Portfolio Constraint 10
Asset Definition 14
Deal Processing 17
Portfolio Performance 18
Portfolio Performance Calculation Methods 23
Performance variation between the last two working days 26
Management and Safe Custody Fees 27
Calculation of Management Fees 31
Accruals of Advisory 48
Safe Custody Safe Keeping Fees 53
Calculation of Safe Custody Fees 59
Safekeeping Account Number 64
Accruals of Safekeep 89
Updating A Portfolio 94
Portfolio Modelling 98
Securities Order Processing 101
Single Portfolio Comparison 102
SC.PORT.COMPARE 102
Group Portfolio Comparison 106
SC.GROUP.COMPARE 106
Order by Customer 112
Order by Customer Purchase 116
Order by customer, Switch 118
Order by Customer,Cash 121
Order by Customer,Sell 123
Service Based Orders 125
Parameter Set up 126
Process work flow for service based orders 127
SC.VALUATION.EXTRACT 141
Margin Calculation 142
Real Time Valuation and Margin Lending 150
Buying Power 156
Margin Lending 159
Customer Facility 164
Short Positions and Other Liabilities 169
Top-up and Sell-Out Margins 171
Diversified Margins 173
Number Count Rule 174
Holdings Rule 174
Issuer Diversification and effect on Portfolio Valuation 174
Segregation of Income 178
Security Margin Ratio 180

Portfolio Management - User Guide - Release R15.000 - Page 2 of 208

Delivery Overview 185
Delivery address for specific Portfolio 185
Enquiries and Reports Overview 187
Portfolio Valuation 187
Portfolio Valuation Enquiries 188
Additional Valuation Information 191
Portfolio Valuation Reports 201
Historical Portfolio Valuation Reports 204
Drill-down enquiries to control portfolio Inflows Outflows 205
First enquiry: SC.VARIATION.PERFORMANCE 205
Second enquiry: SC.VARIATION.PERF.PORTFOLIO 205
Third enquiry: SC.PERFORMANCE.DETAIL 206
Enquiry portfolio performance between two dates SC.DAILY.PERF 207
Installation 208

Portfolio Management - User Guide - Release R15.000 - Page 3 of 208

Introduction

Purpose of this Guide

This document details the types of Portfolio supported by the Portfolio Management in T24. The following sections explains the configuration,
workflow and the enquires/reports involved in this module.

Intended Audience
This User Guide is intended for the use of Internal Temenos users and Clients.

Portfolio Management - User Guide - Release R15.000 - Page 4 of 208

Overview

T24 supports three types of portfolio:

l Banks Own Position Portfolios.

l Customer Portfolios.
l Memo Account Portfolios.

All three have to be set-up on the application SEC.ACC.MASTER, however from there on they are treated quite differently by T24.

Entering in the DEALER.BOOK field on the SEC.ACC.MASTER record signifies a Bank’s Own Position portfolio. If the portfolio is a dealer
book portfolio (i.e. representing the Bank’s own position) it will not be subject to any of the Safe Custody or Management Fees detailed in this
document. Also, T24 will carry out Discount/Premium accruals and revaluation on the portfolio (see the Securities User Guide for more
information on these processes). However, other than the fees, the other functionality described in this document can by carried out on a
Dealer Book Portfolio.

A Customer Portfolio is a portfolio belonging to a customer of the Bank that may be managed by the Bank on the customer’s behalf. All the
functionality described in this document can be carried out on a customer portfolio.

A Memo Account Portfolio is a portfolio where a customer does not enjoy full portfolio management facilities, has no account with the Bank
and the portfolio is for information only. In these cases, the cash-side entries relative to purchases and sales of security are made over-the-
counter by cash, cheque etc.

Entering ‘Y’ in the MEMO.ACCOUNT field on the SEC.ACC.MASTER record defining the portfolio signifies this type of portfolio.

Portfolio Management - User Guide - Release R15.000 - Page 5 of 208

Configuration

The following sections explain the configuration required for Portfolio Management. The Portfolio Management User Guide does not attempt
to provide field by field help on setting-up master files, input of transactions etc – this is the job of the T24 Help Text that can be invoked in
your Browser. Rather, it is intended to provide an overview as to the purpose of each file or transaction and may describe only the more import-
ant fields available to “fine tune” T24 to work for you.

l Portfolio Set up
l Portfolio Constraint
l Asset Definition

Portfolio Management - User Guide - Release R15.000 - Page 6 of 208

Portfolio Set up

Once a CUSTOMER has been entered into T24 one or many portfolios can be defined for that particular CUSTOMER. This is done in two
stages; first a CUSTOMER.SECURITY record is created for the customer and then a SEC.ACC.MASTER record is set-up for each portfolio
linked to the CUSTOMER.

Note; For a Dealer Book Portfolio a “Customer” record on the CUSTOMER file and a corresponding record on the CUSTOMER.SECURITY file
still need to be set-up.

CUSTOMER.SECURITY
Following the input of a CUSTOMER record for a customer, T24 needs to be told that this customer will be linked to the portfolio man-
agement system. To do this a CUSTOMER.SECURITY record needs to be entered as shown in the screenshot below.

CUSTOMER.SECURITY Record

The above screen shot shows the basic set-up of a record on the CUSTOMER.SECURITY application. The frequency and report fields will be
described in the Portfolio Valuation section later in the document. Note; this file is also used to define Brokers, Depositories etc. To use the
CUSTOMER.SECURITY file and how to set-up new records is described in the Securities User Guide.

SEC.ACC.MASTER
An individual portfolio in T24 defined by inputting a SEC.ACC.MASTER record. The key to this application is customer number and a suffix
separated by a hyphen. A single customer can have more than one portfolio attached to it. This is done by defining extra SEC.ACC.MASTER
records and using a different suffix to differentiate the different portfolios. For example 900-1, 900-2, 900-3 etc. would all be portfolios belong-
ing to customer 900. Up to 997 portfolios can be linked to a single customer as suffix 999 is reserved for depositories and 777 is reserved for
Brokers. An example of a SEC.ACC.MASTER record is shown below.

Notice the example record below is used to link the portfolio to an Account Officer (Portfolio Manager - 151) and INVESTMENT.PROGRAM
(INVESTMENT field) for portfolio modelling purposes. It is also used to set-up the cash account defaulting structure for the portfolio.

Portfolio Management - User Guide - Release R15.000 - Page 7 of 208

 SEC.ACC.MASTER example

Before a customer portfolio can set-up, the customer will require at least one customer ACCOUNT to be opened in T24. In the above screen-
shot there are five ACCOUNTrecords for CUSTOMER 888  that are linked to the portfolio, 888-1.

It is possible to set-up a series of defaults to advise the system which of the two accounts to use during transaction input.  This may be
achieved by utilising the AC.DEF.SYS.CODE field together with the fields, AC.DEF.CCY and AC.DEF.ACCT to obtain the precise account
depending upon the level of detail defined in the AC.DEF.SYS.CODE field.

Portfolio Management - User Guide - Release R15.000 - Page 8 of 208

A default of “SC” is required to indicate the default account to be used by the securities module for the subject SEC.ACC.MASTER. Thereafter,
more elaborate defaults may be defined using the application id (in this case “SC”) adding a “-“ separator and then any valid SC.TRANS.TYPE.
In this way, for example, receipts of dividends may be credited to one account, whereas receipts of interest may be credited to another.

If these fields are unpopulated, then the system will attempt to get an account from the ACCOUNT.NOS field in the transaction currency. If
none, then the first mentioned account is used.

The PORT.COMP.ID field is used to hold the HUB Company. The HUB company is where the Portfolio is allowed to Trade. This field auto-
matically defaults from the HUB.COMPANY field in SC.PARAMETER, if set. This is particularly relevant in Client Installations, where all
Trades and Transactions take place in a Centralised HUB for Portfolios belonging to various companies. If no central HUB concept is required,
then this field will default to the Company where the Portfolio is created.

The OWN.COMP.ID field defaults to the Company where the Portfolio is created.

In case of portfolio being shared across companies:

l For Securities and Derivatives transactions - Transaction can be input only in company specified in PORT.COMP.ID field of
SEC.ACC.MASTER. Valuation process consider details only from PORT.COMP.ID.
l For other transactions - Transaction can be input only in company specified in OWN.COMP.ID field of SEC.ACC.MASTER. Valuation
process consider details from OWN.COMP.ID.

SEC.ACC.MASTER record

In SEC.ACC.MASTER application setup is available to deliver messages that are portfolio specific.

Related Topics: Delivery Overview

Portfolio Management - User Guide - Release R15.000 - Page 9 of 208

Portfolio Constraint

This facility allows the control of exposure to a particular issuer within a customer’s portfolio and additionally permits the inclusion or exclu-
sion of trades depending upon criteria defined. For issuer limits, constraints may be defined at issuer level and to impose either a percentage
limit (as a percentage of the portfolio value) or amount limit on the level of trading. If either of these limits is set to zero then trading will be
blocked.

Setting-up constraint records

When a trade is entered (via SEC.TRADE), an override message will be generated if the holding of a particular issuer exceeds either:

l The maximum percentage of the value of the portfolio

l The maximum value permitted for the issuer within the portfolio

This is determined by the constraint defined for the individual portfolio. Constraints may be set up at two levels in the
PORTFOLIO.CONSTRAINT application - i.e. at SYSTEM level and for each individual portfolio.

The following extract shows how the basic “SYSTEM” default record should look. The setting-up of this record ensures that any securities
bought and not containing reference to an issuer will always be accepted for addition to the portfolio holdings.

Default PORTFOLIO.CONSTRAINT

On the other hand, if it is required that, for example, securities issued by a particular issuer should not exceed either a percentage of the total
value of a portfolio or a specific amount, it is necessary to have to define the required details using a reference to the portfolio for which the
checking should take place.

For percentage requests, you can elect to prevent the inclusion of ANY securities belonging to a specific issuer (percentage to be set to “0”, in
this case) or any percentage you like, up to 100% which indicates that there will be no checking performed at all for that particular issuer.

For specific amount requests, you are prompted to supply a currency code as well as the amount to which you wish to restrict a holding to in
the portfolio. This doesn’t necessarily have to be the same as the underlying security issue currency. You may use any currency you like – check-
ing will still be performed to ensure that any addition of security to a portfolio does not cause the total holding to exceed the equivalent spe-
cified in the constraint record.

Additionally, when trading in particular securities or types of financial instruments based on customer directives is required, constraints may
be defined by selecting any field on SECURITY.MASTER to include or exclude the particular security from this portfolio. For example, a cus-
tomer may request the exclusion of any securities for which the issuer is involved in insurance.  In this instance, you may be able to effect the
restriction by the utilisation of the INDUSTRY.CODE field on the SECURITY.MASTER file.

The ability to either block the trade completely or issue a warning that this trade may not be desirable is determined by defining the message
type as either an ‘ERROR’ or an ‘OVERRIDE’. When a trade is executed, (again via SEC.TRADE) it will be validated against the defined con-
straints for this portfolio and either an error message or override will be generated accordingly. Note that the constraints are only triggered
when the issuer is defined in the associated SECURITY.MASTER record.

Portfolio Management - User Guide - Release R15.000 - Page 10 of 208

 PORTFOLIO.CONSTRAINT example

In the above instance, checking will be carried out on all security purchases performed on behalf of portfolio 888-1 to ensure:

l That any securities issued by customer 3610 do not exceed 50% of the total portfolio value.
l For all other issuers, no restriction – up to 100% the portfolio value permitted

Any trades for which the issuer has not been defined on the underlying SECURITY.MASTER are unchecked by the application.

Special Constraints
There may be occasions when it is required to simply block trades in securities issued by an entity. This can be done either in the form of an
error message or by override. You can achieve this by setting-up the required PORTFOLIO.CONSTRAINT record similar to the following
extract:

PORTFOLIO.CONSTRAINT - Example OVERRIDE

You will see that the above very simple test asks that any securities for which the issuer is customer “3434” brings about an OVERRIDE situ-
ation and displays the contents of the NARRATIVE field.  You have a choice as to whether you wish the situation to be covered by an ERROR
or an OVERRIDE situation – specified within the MESSAGE.TYPE field.

Portfolio Management - User Guide - Release R15.000 - Page 11 of 208

In a case where the override has been requested, the following extract of the override portion of a SEC.TRADE illustrates how you are advised
by T24. In this instance it may be seen that the request to check with the account officer has been displayed by the system. Provided the input-
ter of the transaction has sufficient privilege to override, input can continue.

Upon acceptance of the trade by the system, the override is then stored on the SEC.TRADE for future reference.

PORTFOLIO.CONSTRAINT - Override in action

However, in a case where an error message has been specified, as in the next extract, input of the underlying SEC.TRADE cannot continue.

PORTFOLIO.CONSTRAINT - Error Message in action

In those cases where an override message has been specified, inputs can only be effected subject to the user having satisfactory privilege.

Closed Portfolios
TEMENOS T24 updates contain performance related files likeSC. VALUATION. EXTRACT and SC .PORT .PERFORM for a portfolio even after
the portfolio is closed. Similarly, the performance related fields in SEC. ACC.MASTER (relating to the contributions, withdrawals, invested cap-
ital and compare value) continue to be updated every month-end even after the portfolio is closed. In case this information pertaining to closed
portfolios is not going to be used, these updates that adversely affect the COB performance without any resultant benefits, need to be stopped.

If the CALC.CLOSEDPORT field in SC.PARAMETERis set to NO, then the system would ignore closed portfolios while updating the per-
formance related files and fields mentioned in the above paragraph. The updates to SC.VALUATION.EXTRACTwould be stopped from the day
after the closure; the updates to performance fields in SEC.ACC.MASTERwould be stopped from the month after the closure (for example, if
the portfolio is closed on 15th August, updates to these fields would not happen from September month end); and updates to
SC.PORT.PERFORMfile (as part of EOD PORT PERFORM process) would be stopped from the quarter subsequent to the period in which the
portfolio is closed.

The portfolio would be considered closed only if the CLOSURE DATE in SEC ACC MASTER is less than the system date and the fees (both
safekeeping and advisory) have been posted (i.e. there are no dues in respect of these).

Portfolio Management - User Guide - Release R15.000 - Page 12 of 208

 SC.PARAMETER – Closed Portfolio

In the above extract, it can be seen the field CALC.CLOSEDPORT has in the SC.PARAMETER application has been set to “NO” for this func-
tionality to be triggered.

Portfolio Management - User Guide - Release R15.000 - Page 13 of 208

Asset Definition

Assets and liabilities that are linked to a portfolio are divided into Asset Types and Sub Asset Types. Consequently there are two applications
ASSET.TYPE and SUB.ASSET.TYPE to define these divisions.

ASSET.TYPE
This application is used to define the top-level division of the assets and liabilities of a portfolio. T24 modules linked to the portfolio man-
agement system, other than Securities, will need to define an application record on the ASSET.TYPE application before that module is included
in the portfolio management system, such as the one shown in the screenshot below:

ASSET.TYPE application

If a module is not set-up on the ASSET.TYPE file, no assets or liabilities for that module will be recorded in the portfolio management files
even if the transaction is linked to a portfolio. The module is entered in the INTERFACE.TO field. Only those applications that appear in the
drop-down for the INTERFACE.TO field may be linked to the SC (securities) module.

The REPORT.SUB.TOTAL field is linked to the SC.VAL.REP.SUB.TOTAL application and allows the user to group ASSET.TYPE records
together for reporting purposes. If this field is blank for an ASSET.TYPE record that is used to define a group of accounts then any account
linked to this ASSET.TYPE will be considered by the portfolio management system to be for information only and have a zero value.
ASSET.TYPE records linked to assets and liabilities, which are not part of the Securities module, only use the MARGIN.RATE field.

ASSET.TYPE for SC application - Shares

Portfolio Management - User Guide - Release R15.000 - Page 14 of 208

ASSET.TYPE records for the Securities module are used to define a type of security such as Shares or Bonds as in the example above. Thus the
ASSET.TYPE application is the top-level portfolio asset and liability file. You may wish, for example, to separate Bonds so that fixed and vari-
able rate instruments belong to different ASSET.TYPEs.

However, to provide even greater descriptions of each ASSET.TYPE, T24 uses the SUB.ASSET.TYPE application.

SUB.ASSET.TYPE
For modules other than Securities, each module requires a default SUB.ASSET.TYPE record to be set-up, which should be linked to the
ASSET.TYPE record for that module (as shown above). If this default SUB.ASSET.TYPE record is not set-up then no assets or liabilities for
that module will be recorded on the portfolio management files even if the transaction is linked to a portfolio. An example of such a
SUB.ASSET.TYPE record is shown in the screenshot below:

SUB.ASSET.TYPE - Non-SC application

For these non-SC application SUB.ASSET.TYPE records, only one per ASSET.TYPE is permitted. There is no facility, for example, to enable
the splitting of, say, loans, deposits, leases etc. Therefore, if the LD module is linked to the securities module in this way, all LD transactions
in respect of the portfolio are listed together.

Each SECURITY.MASTER record (which defines an individual Security on T24  - see the Securities User Guide) has to be linked to a
SUB.ASSET.TYPE record. As each SUB.ASSET.TYPE in turn has to be linked to an ASSET.TYPE record then this defines the breakdown of a
portfolio’s Securities assets and liabilities.

The SUB.ASSET.TYPE application provides you with an opportunity to separate the various security types into meaningful types of paper that
in turn would enable structured revaluations, statements (both by enquiry and by report) and so on. You may set- up as many
SUB.ASSET.TYPE records as you wish and unlike the non-SC applications, any number may be linked to one ASSET.TYPE record.

A SUB.ASSET.TYPE record id may be set-up to comprise of up to 5 either/or/both alpha and numeric characters. Each SUB.ASSET.TYPE
record must be linked to the Securities module as shown in the screenshot below:

SUB.ASSET.TYPE - SC application

Portfolio Management - User Guide - Release R15.000 - Page 15 of 208

In addition to using the default ASSET.TYPE and SUB.ASSET.TYPE the assets and liabilities of a particular CATEGORY can be linked to a spe-
cific SUB.ASSET.TYPE (and hence to a corresponding ASSET.TYPE) by using the ASSET.BY.CATEG application.

ASSET.BY.CATEGORY application

In the above screenshot forward FOREX contracts (CATEGORY 20000) are linked to SUB.ASSET.TYPE id 2 rather than use the default
SUB.ASSET.TYPE for the FOREX module. Another use of this file would be to link different types of ACCOUNT(identified by having different
CATEGORY codes) to different SUB.ASSET.TYPE records thereby allowing the system to report on them separately.

Portfolio Management - User Guide - Release R15.000 - Page 16 of 208

Deal Processing

The following sections explain the deal processing associated with Portfolio Management

l Portfolio Performance
l Portfolio Performance Calculation Methods
l Performance variation between the last two working days
l Management Fees
l Updating A Portfolio
l Portfolio Modelling
l Order by Customer
l Service Based Orders
l SC.VALUATION.EXTRACT
l Margin Calculation
l Real Time Valuation and Margin Lending
l Segregation of Income
l Security Margin Ratio

Portfolio Management - User Guide - Release R15.000 - Page 17 of 208

Portfolio Performance

T24 retains details of the Portfolio Valuation Amount for a number of months specified in the PERFORM.MONTHS field of the
SC.PARAMETER ap"Portfolio Performance" aboveplication. As well as the value of the portfolio it also holds details of Contributions and With-
drawals made across the portfolio in fields associated with the end of month date and portfolio value for the relevant month end. These fields
are held on the SEC.ACC.MASTER record for the portfolio concerned, as shown in the screenshot below.

SEC.ACC.MASTER - Cash Flow details

Contributions and Withdrawals

A movement across a portfolio is specified as a contribution or withdrawal on the application TRANS.FUND.FLOW. This application has one
record per company and is used to define which accounting transactions and which Securities transactions should be considered as con-
tributions or withdrawals as shown in the screenshot below. Totals for a portfolio contributions and withdrawals are held on the
SEC.ACC.MASTER record for the portfolio as shown above.

TRANS.FUND.FLOW - Example settings

Portfolio Management - User Guide - Release R15.000 - Page 18 of 208

If a Securities movement is made across the portfolio for a transaction that is specified as a contribution or withdrawal in the SETUP.SEC.TR
field on the TRANS.FUND.FLOW record for the company of the portfolio then the contributions and withdrawals fields on the
SEC.ACC.MASTER record for the portfolio and the SC.FUND.FLOW record for the portfolio are updated online. Similarly if an accounting entry
is made across one of the accounts linked to the portfolio which has a transaction code that is specified in the SETUP.CASH.TR field on the
TRANS.FUND.FLOW as a contribution or withdrawal then the contributions and withdrawals fields on the SEC.ACC.MASTER record for the
portfolio are updated with the entry amount at Close of Business. The SC.FUND.FLOWrecord for the portfolio is also updated at this time.

The application SC.FUND.FLOW is keyed on the portfolio number and holds details of all the contributions and withdrawals made across the
portfolio. This application can be used to correct erroneous contributions and withdrawals - for example account movements that have used
the wrong transaction code - as it is a standard T24 input application.

ENQUIRY - SC.FUND.FLOW

An example of an SC.FUND.FLOW record is shown above. One entry, the second shown, corresponds to a FUNDS.TRANSFER transaction that
initially updated the ACCOUNT  no. 9999000000025 linked to the portfolio 950-1.

The smaller entry is quite different. In this case, it relates to a free receipt of securities that the customer requested be delivered to his safe cus-
tody account by a third party. This receipt was delivered “free of payment” and therefore there is no physical cost associated with the trans-
action.

In these cases, T24 requests the cost only for informational purposes otherwise the securities would be treated as having been received totally
free. This may be seen in the following example SECURITY.TRANSFER transaction.

Portfolio Management - User Guide - Release R15.000 - Page 19 of 208

 SECURITY.TRANSFER - Free receipt of security

When entering the transaction, a price of 125p was entered, which was the market price prevailing at the time the request to receive was made
to the Bank. At the same time, the Bank charges GBP 15.00 for receiving securities into safe keeping, shown in the CHARGES field.

SECURITY.TRANSFER - Delivery fields

It can be seen by reference to the DELIVERY.INSTR field that there was no cost, so although the SECURITY.TRANSFER above shows GBP
1,515.00, the real cost was GBP 15.00 for charges.

Portfolio Management - User Guide - Release R15.000 - Page 20 of 208

 SECURITY.TRANSFER - Example STMT.ENTRY

Therefore, although the accounting is just GBP 15.00 as can be seen by reference to the STMT.ENTRY extract above, as far as we are con-
cerned in respect of SC.FUND.FLOW and the population of the SEC.ACC.MASTER fields, CONTRIBUTIONS and WITHDRAWALS, the cost of
the security is GBP 1,515.00.

This is why it is vital that the correct transaction codes are used to drive the process through the TRANS.FUND.FLOW application.

It is not simply a case of adding every available TRANSACTION code or SC.TRANS.NAME in an attempt to pick up every movement across a
portfolio. For example, if your customer buys say, GBP 5,000 worth of securities for which we debit his current account associated with his
portfolio, then the reduction in funds available in his account will be offset by the receipt of the security. The initial net result is no movement,
no contribution and no withdrawal.

Portfolio Management - User Guide - Release R15.000 - Page 21 of 208

 SC.FUND.FLOW - Example

Portfolio Profit and Loss

As well as the month end values for the portfolio T24 retains the starting value of the portfolio. This set of values can be used to calculate the
profit and loss of the portfolio since inception, since the start of the calendar year, over the last three months etc. This is often used by the spe-
cially tailored Portfolio Valuation Reports to show portfolio performance but can also be used by enquiries such as SC.VAL.COST as shown pre-
viously in the totals page for the Enquiry.

Portfolio Management - User Guide - Release R15.000 - Page 22 of 208

Portfolio Performance Calculation Methods

T24 core system provides two methods of calculating performance:

The Modified Dietz Method

For performance measurement, it is possible to have T24 use The Modified Dietz Method, also known as The Daily Method.

The first two sub-chapters below outline the kinematics of treatments in T24 and also the calculation formulas respectively for each of these
methods.

The third sub-chapter below describes coexistence of both methods in T24.

The fourth chapter describes specific release notes for Banks already using daily method as a local development.

Modified Dietz method

The diagram below outlines how performance is calculated using the Modified Dietz method.

By using Portfolio and Fund flow details the system calculates the performance using Modified DIETZ Method.

Where :

MVB Market value at the beginning of the period, including accrued income from the previous period
MVE Market value at the end of the period, including accrued income for the period
F Sum of the cash flows within the period (contributions to the portfolio are positive flows and withdrawals are negative flows)
FW Sum of each cash flow, Fi – multiplied by its weight Wi
W The proportion of the total number of days in the period that the cash flow Fi has been in (or out of) the portfolio.  The for-
mula for Wi is
CD The total number of days for the period
Di Number of days since the beginning of the period in which cash flow Fi occurred

NOTE: The numerator is based on the assumption that the cash flows occur at the end of the day.

Daily Valuation method

The diagram below outlines how performance is calculated using the Daily Valuation method in T24.

By having additional details like the daily value of the portfolio, withdrawals and contributions, it is possible to calculate performance using the
Daily valuation method between two given dates.

Where S1, S2 through Sn are the sub-period indexes for sub-periods 1,2 through n.

Note: Calculating RDAILY does not require determining the sub-period returns. If desired the sub-period return, Ri, can be determined from
the sub-period index by using the formula:

Sub-period 1 extends from the first day of the period up to and including the date of the first cash flow. Sub-period 2 begins the next day and
extends to the date of the second cash flow, and so forth. The final sub-period extends from the day after the final cash flow through the last
day of the period.

Each of the sub-period indexes is calculated using the formula:

Where MVEi is the market value of the portfolio at the end of sub-period і, before any cash flow in period і but including accrued income for
the period.

MVBi is the market value at the end of the previous sub-period (i.e the beginning of this sub-period), including any cash glow at the end of the
previous sub-period and including accrued income.

NOTE: The calculation of the Daily implemented here is founded on the assumption that the cash flow occurs at the end of the day: so that
they are not available to invest in the day they occur, otherwise it could have an impact on daily performance.

Portfolio Management - User Guide - Release R15.000 - Page 23 of 208

Co-existence of both methods from T24 release G11.2
In T24 release G11.2 the existing Modified Dietz calculation and the new daily method calculation will coexist, using respectively the data and
process scheme described in diagrams above.

Displays or outputs of performance figures under Modified Dietz existing before G11.2 are not impacted by G11.2.

For the Daily Method performance figures will be displayed by a new enquiry: SC.DAILY.PERF.

The availability of the performance figures calculated under daily valuation method will start from the starting date of the G11.2. : There is no
historical data recovery.

Specific Release Notes

Those Banks already using the Daily Method as a local development will have to apply a specific upgrade process.

This upgrade process will consist in:

Remove Performance Routines

Remove Performance routines from the batch that launched this routine: SC.BATCH.REP.

Routines to be removed from SC.BATCH.REP:

Performance Routines

From G11.2 a new Performance batch, SC.BATCH.PERF, will launch these performance routines.

Maintain Daily Performance files and their content

These files are the following:

Daily Performance Files

Portfolio Management - User Guide - Release R15.000 - Page 24 of 208

SC.PERF.DETAIL and SC.CASH.FLOW.TRANS

Performance File Definitions

The release G11.2.01 has been designed for multi-company: company code as part of the file-name: FCOMPANYmnemonic.SC.PERF.DETAIL
for SC.PERF.DETAIL

E.g.: FBNK.SC.PERF.DETAIL

If existing SC.PERF.DETAIL, SC.PERF: DETAIL.CONCAT, SC.CASH.FLOW.TRANS and SC.CASH.FLOW.TRANS.CONCAT are presently used
without company mnemonic they must respectively be copied to:

FCOMPANYmnemonic.SC.PERF.DETAIL
FCOMPANYmnemonic.SC.PERF.DETAIL.CONCAT
FCOMPANYmnemonic.SC.CASH.FLOW.TRANS
FCOMPANYmnemonic.SC.CASH.FLOW.TRANS.CONCAT

SC.CASH.FLOW.HIST

Performance File Definitions

If this file is used the routine updating it must be removed from SC.BATCH.REP and inserted at the end of SC.BATCH.PERF.

The file type of SC.CASH.FLOW.HIST must be adapted according to its existing type and if it is used as multi-company or not.

Portfolio Management - User Guide - Release R15.000 - Page 25 of 208

Performance variation between the last two working days

Overview
This is a report launched in batch mode: COB.

l It is entitled: LIST OF PERFORMANCE VARIATIONS – DAILY LIST

It prints portfolios having a performance variation > x% (absolute value) between the last working day and the previous day.

The threshold percentage is recorded in a performance parameter file: SC.PERF.PARAMETER.

Displayed information
The displayed information is: the previous date, the current date, the threshold and the following details for each portfolio matching the cri-
teria:

Performance Variation Report: Selection Criteria

Performance Variation Report: Columns

Performance Variation Report: Complementary Information

Drill-down enquiries to control portfolio Inflows/Outflows are detailed in the Enquires and
reports section

Portfolio Management - User Guide - Release R15.000 - Page 26 of 208

Management and Safe Custody Fees

The T24  portfolio management system contains functionality that allows a user to set-up a fee charging structure to automatically charge man-
agement fees (sometimes referred to as advisory charges) to the customer portfolios on the system at a pre-defined frequency. These are fees
charged by a Bank for managing a customer portfolio as opposed to Safe Custody or Depository fees that are charged for looking after stock
held within a portfolio. Safe Custody fees are described in the next section of this document.

Before management fees can be calculated for a portfolio the user needs to set-up a charging structure for the portfolio. This charging structure
begins at the CUSTOMER.CHARGE record, which is automatically created when the CUSTOMER record is authorised. This is linked to a
SCPM.GROUP.CONDITON record, which sets out which FT.COMMISSION.TYPE record to use for different types of assets. This in turn is
linked to a SCPM.CHARGE.PARAMETER record for details of individual charge levels.

Default Charging Structure

When a CUSTOMER record is created in T24 a CUSTOMER.CHARGE record for that CUSTOMER will be created automatically. If the Secur-
ities module has been installed on the system the SC.APPLICATION field will be updated with a set of fields for the “application”
SC.MANAGEMENT as shown in the screenshot below

CUSTOMER.CHARGES - Input Screen

As can be seen, beneath the SC.APPLICATION field are three associated fields allowing the user to link a portfolio to a particular
SCPM.GROUP.CONDITION record. For example a portfolio of 888-1 is linked to SCPM.GROUP.CONDITION record 004 for Management
Fees whereas all the other portfolios of CUSTOMER888, with the exception of 888-3, are linked to SCPM.GROUP.CONDITION record 003.
The customer’s portfolio 888-3 is linked to the default condition.

For information, the SCPM.GROUP.CONDITION record, for a particular portfolio is linked to ADV.CHG.SCALE field on the
SEC.ACC.MASTER recordthat defines the portfolio.

The SCPM.GROUP.CONDITION record used by the portfolios of a particular customer is defaulted according to the set-up of the application
SCPM.GEN.CONDITION an example of which is given in the screenshot below:

Portfolio Management - User Guide - Release R15.000 - Page 27 of 208

 Portfolio GEN Conditions Input Screen

This record will result in any CUSTOMER record being set- up with a SECTOR.CODE of 1001, 1201 or 606 to have the
SCPM.GROUP.CONDITION record 003 as the default for the calculation of Management Fees for its portfolios.

Note, a blank SCPM.GEN.CONDITION must exist on the system as the default, i.e. a record with no selection criteria in any of the fields
shown above (other than the DESCRIPTION field). The id of this record should be “999”.

For further information on the creation of the CUSTOMER.CHARGE record for a CUSTOMER see the System Tables User Guide.

Detailed Charging Structure

As detailed above for the calculation of Management Fees each portfolio will be linked to an SCPM.GROUP.CONDITION record. This record
allows the user to charge different fees on the different types of asset within the portfolio or to calculate Management Fees on the total value of
the portfolio. The SCPM.GROUP.CONDITION application has an effective date associated with its ID. Thus if a particular fee structure was
scheduled to change at some future, already known date the SCPM.GROUP.CONDITION record could be set-up before that date and T24
would automatically pick up the new record for management fees calculated for periods beginning after the effective date of the fee structure.
For example a SCPM.GROUP.CONDITION record could be set-up to calculate individual assets that make up the portfolio and then totalled
together to calculate the final Management Fee (CALC.METHOD field set to DETAIL rather than TOTAL). The user can include country code
in the SECURITY.TYPE field of XX.group.condition along with a valid XX.CHARGE.PARAMETER record, provided if SECURITY.TYPE
begins with A- or S- (Asset type or Sub asset type).

Portfolio Management - User Guide - Release R15.000 - Page 28 of 208

 SCPM.GROUP.CONDITION Example Screen

Detailed charges are set- up on the SCPM.CHARGE.PARAMETER application and then linked to SCPM.GROUP.CONDITION by
SECURITY.TYPE. This will be used to return a figure against which a fee is calculated using the FT.COMMISSION.TYPE record in the asso-
ciated DET.COMM.CODE field. Once a fee for this part of the holding has been calculated, the user can choose to only charge the portfolio a
percentage of this fee.

In the above example, we have specified the charging using FT.COMMISSION.TYPE record “BB” in any instances of security number 004000-
000. We have also indicated that any occurrences of securities that belong to ASSET.TYPE 40 are charged using FT.COMMISSION.TYPE
record “COHC”. There is also a specific charge defined for SUB.ASSET.TYPE 101 where the request is to utilise the FT.COMMISSION.TYPE
record SCPM002. It is also necessary to define a default, identified by “ALL” in the above extract.

SCPM.CHARGE.PARAMETER Input Record

Any entry in the SECURITY.TYPE field on SCPM.GROUP.CONDITION must exist on the application SCPM.CHARGE.PARAMETER. An
SCPM.CHARGE.PARAMETER record is in the screenshot above. Notice that the fee can be calculated at a NOMINAL or VALUE level and the
user may choose whether to take the HIGHEST or LOWEST calculated figure. The user also has the ability to choose whether to request the

Portfolio Management - User Guide - Release R15.000 - Page 29 of 208

calculation using either the AVERAGE, CLOSING balance, MONTH.AVERAGE,CLOSE.PERIOD and (for daily accrual exclusively) the
PREV.MONTH.CLOSE option.

It is also possible to specify a SECOND.FEE.CODE in SCPM.GROUP.CONDITIONrecord. In this case, the amounts calculated for individual
assets based on DET.COMM.CODE(and after applying DET.PERCENTAGE) will be totalled up to form the base amount on which the
SECOND.FEE.CODE will be applied. The amount calculated based on SECOND.FEE.CODE and SECOND.FEE.PERC will be the Management
fee posted to the customer. It must be noted that SECOND.FEE.CODE can only be set-up with CALC.METHOD ‘DETAIL’ and if fee accruals
are to be performed daily. TOTAL DETAILS cannot be set when the SECOND.FEE.CODE is specified.

It must be noted that with SECOND.FEE.CODE set-up, the amount calculated based on DET.COMM.CODE and DET.PERCENTAGE will
only be used as a base amount for the management fee calculation and will not be construed as management fees to be charged to the cus-
tomer.

The fee accruals and minimum/maximum amount checks will all be based on the fee amount calculated using the SECOND.FEE.CODE.

No pro-rating will be performed when either the charge parameter or group condition percentage fields are amended. The calculations will
always use the latest value. If a change in group condition setting (such asDET.PERCENTAGE) requires incorporation into the pro-rating pro-
cess then this should be done using new group condition records and an associated charge scale change on the SEC.ACC.MASTER record. If
there is a change in charge parameter setting (say, PERCENTAGE), the latest charge parameter values will continue to be applied for the full
charge period to establish the calculation basis values.

Portfolio Management - User Guide - Release R15.000 - Page 30 of 208

Calculation of Management Fees

Management Fees are calculated during the Close of Business as part of the Batch job SC.SAFE.ADV.CHG. The frequency of calculation can be
defined at a company or portfolio level through the set up of the SAFECUSTODY.VALUES application, which is keyed on the company ID, as
shown in the extract below.

Portfolio Management - User Guide - Release R15.000 - Page 31 of 208

 SAFECUSTODY.VALUES - Example record

Portfolio Management - User Guide - Release R15.000 - Page 32 of 208

The SAFECUSTODY.VALUES application is used to set-up both Management Fees and Safe Custody Fees, and is used to specify the top level
information including the CATEGORY to which to post the fees and the transaction codes to use. The Management Fees run frequency is con-
trolled by whatever is specified in the CHARGE.FREQ field associated with the CHARGE.TYPE of “IC”.

For an explanation of how the date range fields (CALC.TYPE to DELIV.END) function, refer to the Safe Custody Fees section of the user guide.

Similarly, the COUNTRY.CHECK field can be set to include the security domicile or security country domicile or stock exchange domicile
based on which system calculates the base amount for management fees.

In the screenshot example above, Management Fees are calculated on a frequency that is set-up at the portfolio level, as the COMPANY.CALC
field is set to “NO” whereas, not shown in the above extract, Safe Custody Fees are calculated for all portfolios at the same time, i.e. there is a
company wide Safe Custody Fees run, because the associated COMPANY.CALC field is set to ‘Y’. In addition to the periodic management fees
calculation, management fees are also calculated for a portfolio whenever a portfolio is closed (input of a date in the CLOSURE.DATE field on
the SEC.ACC.MASTER record that defines the portfolio) to charge the portfolio for any fees not yet taken. The point is that safekeeping and
management fee runs may be performed independently of one another.

Notice too that posting of management fees is controlled from the SAFECUSTODY.VALUES record, by the COMPANY.POST field. If this field
is set to ‘Y’ then all the posting of all management fees for portfolios on the company concerned are posted together. If it is set to “NO” then
the application SC.ADV.FEES.POST can be used to post management fees for particular portfolios at a time (or all the portfolios of a particular
Account Officer at the same time).

SC.ADV.FEES.POST - Example record

Whether the Management Fees are calculated company wide or on a portfolio basis the frequency of calculation will be shown among the Man-
agement Fees calculation fields on the SEC.ACC.MASTER record that defines the portfolio. These are shown below:

SEC.ACC.MASTER - Define Management Fees

Portfolio Management - User Guide - Release R15.000 - Page 33 of 208

The date of the next Management Fees run for this portfolio is held in the ADVISORY.FREQ field together with the frequency. If the field
COMPANY.CALC on SAFECUSTODY.VALUES is set to “NO” then the frequency may be amended by the user, otherwise it is for information
only. The date of the last run and the ID of the SCPM.GROUP.CONDITION record to which this portfolio is linked are also given for inform-
ation purposes. Also on the SEC.ACC.MASTER application is the PORTFOLIO.FEES field. Here it is set to AUTOMATIC, which means that
the fees will be automatically calculated by the system. If it is set to MANUAL or NONE no fees will be calculated by the system. For a cus-
tomer portfolio this field will default to AUTOMATIC.

During the Close of Business, the system will check the system date against the date in the ADVISORY.FREQ field for any customer portfolio
where the PORTFOLIO.FEES date is set to AUTOMATIC . If the date is less than the next working day, automatically calculate the Man-
agement Fees for that portfolio, provided that the value in the MANAGED.ACCOUNT field on the SEC.ACC.MASTER record for the portfolio
corresponds to one of the MANAGED.ACCOUNT file ID’s specified in the ACC.CALC field, associated with a CHARGE.TYPE of IC on the
SAFECUSTODY.VALUES application.

Posting Of Management Fees

Details of the calculated Management Fees will be written to the SC.ADVISORY.CHG file. They will remain here so that the Account Officer of
a particular portfolio will have an opportunity to review the calculated management fees and amend them if necessary before performing the
posting of the Management Fees.

SC.ADV.FEES - Example portfolio record

Note: Some of the fields can be amended such as the ACCOUNT.NO,VALUE.DATE and LOCAL.FEES.LCY fields.

The Portfolios can be locked at this stage in order to block any new back dated transaction which would have an impact on the
SC.ADVISORY.CHG.

Portfolio Management - User Guide - Release R15.000 - Page 34 of 208

In case the portfolio is locked at the CALCULATED status and a new back dated transaction is input, then the same would not have any
impact on the SC.ADVISRORY.CHG record. Provided the locking date is equal to or greater than Advisory charge frequency date. If the locking
is removed and a new backdated transaction is input, then the transaction will be processed as per the existing functionality.

For more information on Locking of portfolio, refer “Locking Client Reporting” User Guide.

Once all the SC.ADVISORY.CHG records have been reviewed the Management Fees can be posted. As mentioned above, this is controlled by
how the SAFECUSTODY.VALUES application for the company concerned has been set-up. If a posting run is to be made posting all the cal-
culated management fees for all the customer portfolios in the company at the same time (i.e. the COMPANY.POST flag is set to ‘Y’) then the
postings can be made by setting the POST.CHARGES field, associated with IC in the CHARGE.TYPE field on the SAFECUSTODY.FEES
record, to “Y”. The charges will then be posted automatically during the next COB session.

Alternatively, the fees may be posted online by running the program SC.ADV.FEES.POST.  However, if this option is required, then the
POST.CHARGES field, referred to above, must be set to “NO”. The SC.ADV.FEES.POST application is shown below.

SC.ADV.FEES.POST - Account Officer request

The application SC.ADV.FEES.POST is used to Input and Authorise some or all the un-posted SC.ADVISORY.CHG records for the company.

The record above is keyed on ACCOUNT.OFFICER field of SEC.ACC.MASTER and therefore any portfolio(s) belonging to that officer may be
entered, using the multi-value fields as required.

Alternatively, it is possible to request that all un- posted SC.ADVISORY.CHG records are posted. This is achieved by keying the
SC.ADV.FEES.POST record with the word “ALL” as in the next example screen extract.

SC.ADV.FEES.POST - Post ALL records request

Note: In this case the PORTFOLIO.NO field obviously becomes no input.

If the COMPANY.POST flag is set to “NO” then the management fees can be posted for an individual portfolio or for any or all the portfolios for
a particular Account Officer (type ALL in the PORTFOLIO.NO field). If the POST.ONLINE field is set to “NO” then the posting will take place
in the start of day by SC.SAFE.CHGS.ACC, otherwise it will take place in real time. Alternatively, the Management fees, as in the table

Portfolio Management - User Guide - Release R15.000 - Page 35 of 208

SC.ADVISORY.CHG,can be posted through the application SC.ADV.FEES.POST by input and authorising the record. After the authorisation,
the TSA.SERVICE record SC.ADV.FEES.POST is set to “START” status in the SERVICE.CONTROL field automatically.

TSA.SERVICE - Advisory Fees posting

As can be seen the record is now activated. Now, provided the TSA.SERVICE service manager is also started, you should invoke it by typing
and entering START.TSM -DEBUG at the jBase prompt and starting the respective service agents manually. This will allow the processing of all
the SC.ADVISORY.CHG records with PROCESS.STAGE as “CALCULATED” and post the Management fees.

The Portfolios can be locked at this stage in order to block any new back dated transaction which would have an impact on the
SC.ADVISORY.CHG.POSTED

In case the portfolio is locked at the POSTED status and a new back dated transaction is input, then the same would not have any impact on
the SC.ADVISRORY.CHG.POSTED record for the blocked month. Provided the locking date is equal to or greater than Advisory charge fre-
quency date. If the locking is removed and a new backdated transaction is input, then an REPOST or ADJUST entry would be posted based on
the setup at Portfolio Level.

For more information on Locking of portfolio, refer “Locking Client Reporting” User Guide.

The field Fee.Adjustment.Type in AM.PARAMETER can hold values namely 'REPOST/ADJUST'. The values cannot be modified once set and
the default value is set to ADJUST. 'ADJUST' indicates posting of differential fees between already posted and the newly computed fees and
whereas the 'REPOST' indicates the new fees to be posted as a new entry and the old posted entries are to be reversed.

Portfolio Management - User Guide - Release R15.000 - Page 36 of 208

 AM.PARAMETER record-FEE.ADJUSTMENT.TYPE

The field FEE.ADJUSTMENT.TYPE is available in SEC.ACC.MASTER and defaults the value from the AM.PARAMETER and the same can be
amended by the user at any point in time at portfolio level.

Portfolio Management - User Guide - Release R15.000 - Page 37 of 208

 SAM record-FEE.ADJUSTMENT.TYPE

When a backdated transaction is input with the portfolio in unlocked status, then the system would REPOST/ADJUST as per the set up in
SEC.ACC.MASTER. The posting can be made to ADJUST at the SC.ADVISORY.CHG.POSTED record level, by setting the field ADJUST.FEES
as YES and ADJUST.VALUE.DATE with a valid Value date. This will overwrite the setup at portfolio level.

Portfolio Management - User Guide - Release R15.000 - Page 38 of 208

 SC.ADVISORY.CHG.POSTED record

The field ADJUST.FEES can hold the values YES/NULL. If this is set as 'YES', ADJUST.VALUE.DATE needs to be entered by the user.

The value date of posting the Adjustment Entries is entered in the field ADJUST.VALUE.DATE.

Portfolio Management - User Guide - Release R15.000 - Page 39 of 208

 SC.ADVISORY.CHG.POSTED-Adjust

STMT.ENTRY - ADJUST.FEES is set to 'YES'.

Portfolio Management - User Guide - Release R15.000 - Page 40 of 208

 SC.ADVISORY.CHG.POSTED-Adjust-STMT entry

CATEG.ENTRY - ADJUST.FEES is set to 'YES'.

SC.ADVISORY.CHG.POSTED-Adjust-CATEG entry

Portfolio Management - User Guide - Release R15.000 - Page 41 of 208

 SC.ADVISORY.CHG.POSTED-Repost

STMT.ENTRY - ADJUST.FEES is set to 'NULL'.

Portfolio Management - User Guide - Release R15.000 - Page 42 of 208

 SC.ADVISORY.CHG.POSTED-Repost-STMT entry

CATEG.ENTRY - ADJUST.FEES is set to 'NULL'.

SC.ADVISORY.CHG.POSTED-Repost-CATEG entry

Note: The agent records are preceded by the company mnemonic, which in the example case, is “CH1”.

For greater, in depth instructions as to the operation of TSA.SERVICE and its agents, please refer to the User Guide describing the COB (Close
of Business) application.

Portfolio Management Fees - Monthly Average Balances & Accruals

As an alternative to the previously described process, you may instead require to extend the average balance method so that this can be based
on the average daily balance for each month during the charge cycle. This process enables fees to be accrued monthly to P/L while the contra
entry is posted to an internal pre-defined suspense account. All calculations are performed in the System local currency.

This method requires some additional set-up and is intended to cater only for instances where the charge frequency is global (i.e. the same for
all customers). It is not designed to run alongside the earlier described process.

Should your organisation already be using this earlier described process, you should first ensure that you have completed the current charge
cycle for all customers. You will then have to ensure that the COMPANY.CALC field on the SAFECUSTODY.VALUES application is set to "Y"
so that all customers are charged at the same time in accordance with the frequency defined in the CHARGE.FREQ field of the same file.

Portfolio Management Fees - Setting-up parameters for Daily Average Balance

To set-up this process, you should first define the requirement using the SAFECUSTODY.VALUES file.

Portfolio Management - User Guide - Release R15.000 - Page 43 of 208

 SAFECUSTODY.VALUES - Setting-up accruals 1

Firstly, the set the COMPANY.CALC field to “Y” as the daily average calculation process may only be applied if all portfolios undergo the same
accrual set-up. Here too, add a new CATEGORY code for the ACCRUAL.CATEG field. You may have to define a new category for this purpose.

SAFECUSTODY.VALUES - Setting-up accruals 2

You should also set the DAILY.EXTRACT field to "YES" to indicate that you wish the daily balances to be extracted and held on the
SC.ADV.FEES.ACTIVITYandSC.ASSET.BAL files.

In addition to the above, you would need to set- up the field AVERAGE.CLOSING on all the SCPM.CHARGE.PARAMETER files to
'MONTH.AVERAGE' as shown in the screenshot below.

SCPM.CHARGE.PARAMETER - Default record

The field AVERAGE.CLOSING can be set to 'MONTH.AVERAGE' only if the DAILY.EXTRACT field on the SAFECUSTODY.VALUES file has
been set to 'YES'.

Portfolio Management - User Guide - Release R15.000 - Page 44 of 208

With the above set-up the system will extract daily balances and store these in the file SC.ADV.FEES.ACTIVITY as shown in the next screen
example.

SC.ADV.FEES.ACTIVITY - Example balance

The above extract illustrates a typical position in a bond.

Positional details are stored monthly. The id of the record above indicates the following:

888-1 Portfolio number

003175-000 Security

200101 Year and Month (January 2001)

Within that particular record we can see the daily balance details.

This particular position opened the month with a balance as indicated in the details for day '01'. Since the data relates to a test account, there
were only 3 working days that particular month! Each day’s balance details can be seen above for days 01, 30 and 31.

The average balances for the month can be seen in the final multi-value field set relative to day 31. In the example, the average nominal balance
of the bond is derived as follows:

29 days x 10,000 = 290,000

1 day x 15,000 = 15,000
1 day x 35,000 = 35,000

Portfolio Management - User Guide - Release R15.000 - Page 45 of 208

 = 340,000 / 31 = 10,967.74

The other balances are calculated similarly.

Each month-end, that month’s accrual is posted to the Profit/Loss account relative to the Management/Advisory fees as shown in the extract
below.

ACCOUNTING - Profit and Loss entries

The contra accrual is posted to the suspense account defined in the ACCRUAL.CATEG field on the SAFECUSTODY.VALUES file for the Bank.
In the example case this has been specified as “13333”.

ACCOUNTING - Safekeeping Accrual Suspense

Accruals remain on the suspense account until the T24 arrives at the end of the charge period when the suspense balances are cleared down
and charged to the relevant customer accounts. The process then starts again for the new charge period.

Portfolio Management Fees - Setting-up parameters for Monthly Accruals

The first step is to define a category to which you wish the monthly accruals to be posted. This can be done by specifying an appropriate cat-
egory code, in the range of 11000 to 19999, as shown in the ACCRUAL.CATEG field in the following screenshot.

Portfolio Management - User Guide - Release R15.000 - Page 46 of 208

 SAFECUSTODY.VALUES - Define accrual suspense category

Further you will need to advise T24 that you wish accruals to be made by setting the PERFORM.ACCRUAL field to monthly as shown below.

SAFECUSTODY.VALUES - Specify accruals required for Mgmt Fees

The above settings will perform accruals at each month-end. These accruals are based on the average daily balance for each month during the
charge cycle that in turn can be monthly, quarterly, half yearly or annually as required.

Advisory Fees Accrual Accounting Rules

Advisory fee accrual entries will be raised at month end as follows:

DR Advisory Fee Accrual A/C (ADVISORY.ACCR.ACCT on SAFECUSTODY.VALUES

CR P&L (CR.CATEG.CODE on SAFECUSTODY.VALUES for CHARGE.TYPE = 'IC')

If any adjustments are made to the calculated charges on the SC.ADVISORY.CHARGE file then the system passes the adjustment entries to
adjust the accruals.

If charge has been increased then:

DR Advisory Fee Accrual A/C with the increase

CR P&L with the increase

If the charge has been decreased then: 

Portfolio Management - User Guide - Release R15.000 - Page 47 of 208

 CR Advisory Fee Accrual A/C with the decrease

DR P&L with the decrease

On final posting of the charges the accounting that follows is as shown under: 

CR Advisory Fee Accrual A/C

DR Customer’s charge account

Accruals of Advisory
Accruals of Advisory Charges are posted in a separate identifiable accrual PL Category codes.

Following is the field available in SEC.ACC.MASTER application to post the accruals of Advisory.

1. ADVISORY.ACCR.PL

Field Name Description

ADVISORY.ACCR.PL Accrual PL category for Advisory

Sample screen shot of ADVISORY.ACCR.PLin SEC.ACC.MASTER application.

Portfolio Management - User Guide - Release R15.000 - Page 48 of 208

Overrides in SEC.ACC.MASTER
The field ADVISORY.ACCT.ACCT in SEC.ACC.MASTER allows to have internal account of different category, that are not specified in
ACCRUAL.CATEG field of SAFECUSTODY.VALUES

Sample screen shot of SEC.ACC.MASTER application raising an override.

Discount on Advisory Fees

Discount on Advisory Fees is posted, in a different PL category code, in SAFECUSTODY.VALUES application.

Following is field available in SC.ADVISORY.CHG application to post the discount on Advisory.

Portfolio Management - User Guide - Release R15.000 - Page 49 of 208

 Field Name Description

DISCOUNT.PL Profit loss category for discount posting.

To be added in associated multivalue set with CHARGE.TYPE field.

Replace MV.RESERVED04 field.

Note: During accruals, Accrual Categ in SEC.ACC.MASTER will take precedence over SAFECUSTODY.VALUES application.

During discount postings, Discount PL category specified in charge files will take precedence over DISCOUNT.PL specified in
SAFECUSTODY.VALUES application.

Sample screen shot of DISCOUNT.PL in SAFECUSTODY.VALUES application.

Portfolio Management - User Guide - Release R15.000 - Page 50 of 208

 SC.ADVISORY.CHG - DISCOUNT.PL

Discount on Advisory Fees Posted

Discount on Advisory Fees is posted, in a different PL category code, in SC.ADVISORY.CHG.POSTED application.

Following is the field available in SC.ADVISORY.CHG.POSTED application to post the discount on Advisory.

Field Name Description

DISCOUNT.PL Profit loss category for discount posting.

To be defaulted from SAFECUSTODY.VALUES but can be over-

ridden.

Sample screen shot of DISCOUNT.PL in SC.ADVISORY.CHG.POSTED application.

Portfolio Management - User Guide - Release R15.000 - Page 51 of 208

 SC.ADVISORY.CHG.POSTED - DISCOUNT.PL

Portfolio Management - User Guide - Release R15.000 - Page 52 of 208

Safe Custody Safe Keeping Fees

The T24 portfolio management system contains functionality that allows a user to set-up a charging structure to automatically charge Safe Cus-
tody and Depository fees to the customer portfolios on the system at a pre-defined frequency. These are fees charged by a bank or depository
for looking after the stock held by the portfolio as opposed to Management fees, which are charged for managing a customer portfolio. Man-
agement fees are described in the previous section of this document.

Before Safe Custody fees can be calculated for a portfolio the user needs to set-up a charging structure for the portfolio. This charging structure
begins at the CUSTOMER.CHARGE record for the customer, which is automatically created when the customer record is authorised. This is
linked to a SCSK.GROUP.CONDITION record, which sets out which FT.COMMISSION.TYPE record to use for different types of assets. This
in turn is linked to an SCSF.CHARGE.PARAMETER record for details of individual charge levels.

The Safe Custody Fees themselves are calculated whenever a portfolio is closed - for fees due up to the date of closure - or at the Safe Custody
Fees Run the frequency of which can be maintained at company or portfolio level - as with Management Fees.Once the fees have been calculated
they are recorded on the SAFEKEEP.HOLDING application for review before posting.

Default Charging Structure

When a CUSTOMER record is created on T24 a CUSTOMER.CHARGE record for that CUSTOMER will be created automatically. If the Secur-
ities module has been installed on the system the SC.APPLICATION field will be updated with a set of fields for the “application”
SC.SAFEKEEPING as shown below:

CUSTOMER.CHARGE - Example record

As can be seen, beneath the SC.APPLICATION field are three associated fields allowing the user to link a portfolio to a particular
SCSK.GROUP.CONDITIONrecord. In the example above, portfolio 900-1 is linked to SCSK.GROUP.CONDITION record 001 for Safe Custody
Fees whereas all the other portfolios of CUSTOMER900 are linked to SCSK.GROUP.CONDITION record 001. The user can change this link
so that portfolio 900-1 could be linked to, say, record 005 in the future, for example. For information, the SCSK.GROUP.CONDITION record
for any particular portfolio, is linked to show in the SAFE.CHG.SCALE field on the SEC.ACC.MASTER record that defines the portfolio.

The SCSK.GEN.CONDITION record used by the portfolios of a particular customer is defaulted according to the set-up of the application
SCSK.GROUP.CONDITION. An example screenshot of the SCSK.GEN.CONDITION is shown below:

Portfolio Management - User Guide - Release R15.000 - Page 53 of 208

 SCSK.GEN.CONDITION - Example

This record will result in any customer having a SECTOR of 4100 or 4500 being assigned the SCSK.GROUP.CONDITION record 001 as the
default for the calculation of Safe Custody Fees for its portfolios. Note; if T24 cannot work out a SCSK.GROUP.CONDITION record to use,
the system will use the default SCSK.GROUP.CONDITION ID entered in the DEPOSITORY.GROUP field of the CUSTOMER.CHARGE record
for the Depository where the stock for which the Safekeeping Charges are being charged is held.

For more information on the creation of the CUSTOMER.CHARGE record for a CUSTOMER see the System Tables User Guide.

Detailed Charging Structure

As detailed above, for the purposes of calculation of Safe Custody Fees, each portfolio will be linked to a SCSK.GROUP.CONDITION record.
This record allows the user to charge different fees on the different types of asset within the portfolio and by the depository of the holding, or
to calculate Safe Custody Fees on the total value of the portfolio in a similar way that SCPM.GROUP.CONDITION application is used for Man-
agement fees. As with the TAX application the SCSK.GROUP.CONDITION application has an effective date associated with its ID. Thus if a
particular fee structure was to change at some future, pre-defined date the SCSK.GROUP.CONDITION record could be set-up before that date
and T24  would automatically pick up the new record for Safe Custody fees calculated for periods beginning after the effective date of the fee
structure. In the example of a SCSK.GROUP.CONDITION record shown below, the fees are set-up to be calculated on the individual assets
that make up the portfolio and then totalled together to calculate the final Safe Custody Fee (CALC.METHOD field set to DETAIL rather than
TOTAL).

Detailed charges are set- up on the SCSF.CHARGE.PARAMETER application and then linked to SCSK.GROUP.CONDITION using the
SECURITY.TYPE field. This will be used to return a screenshot against which a fee is calculated using the FT.COMMISSION.TYPE record in
the associated DET.COMM.CODE field. Once a fee for this part of the holding has been calculated the user can choose to only charge the port-
folio a percentage of this fee.

Portfolio Management - User Guide - Release R15.000 - Page 54 of 208

 SCSK.GROUP.CONDITION - Example record

Thus in the example above any portfolio asset with a SUB.ASSET.TYPE of 101 (“S” denotes SUB.ASSET.TYPE, therefore S-101) will have a fee
calculated using the FT.COMMISSION.TYPE record SCSK001 but only 55 % of this calculated fee will be added into the final Safe Custody Fee
charged to the portfolio. Note that as well as setting up a fee at a SUB.ASSET.TYPE level, fees can be set-up at ASSET.TYPE or individual
Security level as well as specifying a default of ALL. It is also possible to specify different parameters by depository.System allows user to
include country code in the field SECURITY.TYPE of XX.group.condition along with a valid XX.CHARGE.PARAMETER record. provided if
SECURITY.TYPE begins with A- or S- (Asset type or Sub asset type). Where various levels of settings are used the system will select a charge
parameter in the following order of priority:

MATCHING ORDER CLASSIFICATION ID FORMAT EXAMPLE

1 Security Number ’.’ Depository nnnnnn-nnn ’.’ Depos- 123456-000.100001
itory
2 Security Number nnnnnn-nnn 123456-000
3 SUB.ASSET.TYPE ‘.’ Depos- “S-“n to “S-“nnnn ‘.’ S-300.100001
itory Depository
4 SUB.ASSET.TYPE “S-“n to “S-“nnnn S-300
5 ASSET.TYPE ‘.’ Depository “A-“n to “A-“nnn ‘.’ A-20.100001
Depository
6 ASSET.TYPE “A-“n to “A-“nnn A-20
7 Default ‘.’ Depository “ALL” ‘.’ Depository ALL.100001
8 Default “ALL” ALL

Charge Parameters in order of priority

It will also be possible to define the charging structure based on user-defined criteria. The system will allow grouping based on a local reference
field in SECURITY. MASTER in addition to the ASSET TYPE, SUB.ASSET.TYPE and SECURITY.MASTER Options defined above. If for
example, the bank has to have a separate charging structure for certain group of securities based on a local reference field in
SECURITY.MASTER, say, FEE.GROUP, this can be activated in SAFE.CUSTODY.VALUES.

SAFE.CUSTODY.VALUES

Grouping of securities based on value of Local Reference field FEE.GROUP of SECURITY. MASTER is now enabled. Now it is only the ques-
tion of linking it to the charge structure as shown below:

Portfolio Management - User Guide - Release R15.000 - Page 55 of 208

SCSF.CHARGE.PARAMETER record set at User defined local reference ‘.’ Depository level with “PREV.MONTH.CLOSE” method

SCSF.CHARGE.PARAMETER record set at User defined local reference level with “PREV.MONTH.CLOSE” method.

Once this is done, this can be linked to a SCSK.GROUP.CONDITION record as shown below:

Portfolio Management - User Guide - Release R15.000 - Page 56 of 208

SCSK.GROUP.CONDITION record with different percentages set at User defined local reference ‘.’ Depository level and also at User defined
local reference level

The order of priority with user-defined fields would be:

Matching Order Classification ID Format Example

1 Security Number ‘.’ Depository nnnnnn-nnn ‘.’ Depository 123456-
000.100001
2 Security Number nnnnnn-nnn 123456-000
3 User defined local reference ‘.’ “L-“n (n – a valid value in user defined local reference) L-1.100001
Depository ‘.’ Depository
4 User defined local reference “L-“n (n – a valid value in user defined local reference) L-1
5 SUB.ASSET.TYPE ‘.’ Depository “S-“n to “S-“nnnn ‘.’ Depository S-300.100001
6 SUB.ASSET.TYPE ‘.’ “S-“n to “S-“nnnn ‘.’ COUNTRY.CODE S-300.GB
COUNTRY.CODE
7 SUB.ASSET.TYPE “S-“n to “S-“nnnn S-300
8 ASSET.TYPE ‘.’ Depository “A-“n to “A-“nnn ‘.’ Depository A-20.100001
9 ASSET.TYPE ‘.’ COUNTRY.CODE “A-“n to “A-“nnn ‘.’ COUNTRY.CODE A-20.GB
10 ASSET.TYPE “A-“n to “A-“nnn A-20

Portfolio Management - User Guide - Release R15.000 - Page 57 of 208

 11 Default ‘.’ Depository “ALL” ‘.’ Depository ALL.100001
12 Default “ALL” ALL

A similar set-up can also be done for Advisory fees where the order of priority will be as under:

Matching Order Classification ID Format Exampl-

e
1 Security Number nnnnnn-nnn 123456-
000
2 User defined local reference “L-“n (n – a valid value in user defined local reference) L-1
3 SUB.ASSET.TYPE ‘.’ “S-“n to “S-“nnnn ‘.’ COUNTRY.CODE S-
COUNTRY.CODE 300.GB
4 SUB.ASSET.TYPE “S-“n to “S-“nnnn S-300
5 ASSET.TYPE ‘.’ COUNTRY.CODE “A-“n to “A-“nnn ‘.’ COUNTRY.CODE A-20.GB
6 ASSET.TYPE “A-“n to “A-“nnn A-20
7 Default “ALL” ALL

SCSF.CHARGE.PARAMETER - Example SUB.ASSET.TYPE level

Any entry in the SECURITY.TYPE field on SCSK.GROUP.CONDITION must exist on the application SCSF.CHARGE.PARAMETER. The
SCSF.CHARGE.PARAMETER record for SUB.ASSET.TYPE 101 is shown above. Notice that the fee can be calculated at a NOMINAL or
VALUE level and the user can choose whether to take the HIGHEST or LOWEST calculated screenshot. The user also has the ability to choose
whether to do the calculation on the AVERAGE, CLOSING or MONTH.AVERAGE balances or if daily accruals are required, then PREV.
MONTH.AVERAGE (previous month’s closing balance).

It is also possible to specify aSECOND.FEE.CODEin SCSK.GROUP.CONDITION record. In this case, the amounts calculated for individual
assets based on DET.COMM.CODE(and after applying DET.PERCENTAGE) will be totalled up to form the base amount on which the
SECOND.FEE.CODE will be applied. The amount calculated based on SECOND.FEE.CODE and SECOND.FEE.PERC will be the safekeeping
fee posted to the customer. It must be noted that SECOND.FEE.CODE can only be set-up withCALC.METHOD‘DETAIL’ and if fee accruals are
to be performed daily. This will only be applicable for customer charges and not for depository charges.

It must be noted that with SECOND.FEE.CODE set-up, the amount calculated based on DET.COMM.CODE and DET.PERCENTAGE will
only be used as a base amount for the safekeeping fee calculation and will not be construed as safekeeping fees to be charged to the customer.

The fee accruals and minimum/maximum amount checks will all be based on the fee amount calculated using the SECOND.FEE.CODE.

No pro-rating will be performed when either the charge parameter or group condition percentage fields are amended. The calculations will
always use the latest value. If a change in group condition setting (such as DET.PERCENTAGE) requires incorporation into the pro-rating pro-
cess then this should be done using new group condition records and an associated charge scale change on the SEC.ACC.MASTER record. If
there is a change in charge parameter setting (say,PERCENTAGE), the latest charge parameter values will continue to be applied for the full
charge period to establish the calculation basis values.

Portfolio Management - User Guide - Release R15.000 - Page 58 of 208

Calculation of Safe Custody Fees

Safe Custody Fees are calculated during the Close of Business as part of the Batch job SC.SAFE.ADV.CHG. The frequency of calculation can be
defined at company or portfolio level from set-up of the SAFECUSTODY.VALUES application, which is keyed on the company ID.

SAFECUSTODY.VALUES - Safe Custody Fees

As stated in the Management Fees section above, the SAFECUSTODY.VALUES record is used for both Management Fees and Safe Custody
Fees, and is used to specify the top level information concerning the CATEGORY to post the fees to and the transaction codes to use. The
CHARGE.FREQ field associated with the CHARGE.TYPE of SC controls the Safe custody Fees run.

Different date ranges need to be specified in the SAFECUSTODY.VALUES record, to allow calculation of fees to be performed correctly for
opening and closing accounts.

These four ranges are specified in the CALC.TYPE field:

PERIODIC.OPEN Used when the Charges run is an automatic charging run controlled by the frequency in the
CHARGE.FREQ field and the portfolio was opened since the last automatic run.

PERIOD.NORMAL Used when the charges run is an automatic charging controlled by the frequency in the
CHARGE.FREQ field and the portfolio was open at the time of the last fee run.

Portfolio Management - User Guide - Release R15.000 - Page 59 of 208

 CLOSURE.NORMAL Used when the fees are being calculated because a portfolio is being closed and the portfolio was open
at the time of the last fees run.

CLOSURE.OPEN Used when the fees are being calculated because a portfolio is being closed and the portfolio has been
opened since the last fee run.

The associated fields PERIOD.START, PERIOD.END, NO.OF.MONTHS, DELIV.START and DELIV.END have a particular type of input. This
is done using the characters :

 “-“,”+”,”L”,”C” and “O”

where;

“O” represents the date of the portfolio opening.

“L” represents the date of the Last Fees Run.

“C” represents today's system date.

These are entered together with numeric input to build a date.

Thus

“C-1” is the calendar date before today.

“O+1” is the calendar date after the opening date of the portfolio.

The safe custody fees system works on a month basis, so if the user wants to have the Safe Custody fees calculated from the last run date up
and including the current date, input should be made as follows:

PERIOD.START L+1

This is because of the monthly calculation. For example, if the current working date is 31/03/99 and the last run was done on 31/12/98 then
the values of the variables are L = 199812 and C = 199903. As the system takes the last run date to be the first of the month, this translates a
PERIOD.START of 'L' and a PERIOD.END of 'C' as the period 01/12/98 to 31/03/99 which is 4 months. Whereas the PERIOD.START of 'L+1'
and a PERIOD.END of 'C' gives a period of 01/01/99 to 31/03/99 and hence a period of 3 months

A minimum and maximum value for the safe custody fees can be specified using the fields MIN.MAX.CCY,MIN.AMOUNT,MAX.AMOUNT and
DEF.MIN.MAX.CCY. The maximum and minimum screenshots are calculated based on the safekeeping charge less the discount only, it does
not cover any depository charges.

Below is a typical set-up for safe custody fees:

SAFECUSTODY.VALUES - Typical "Quarterly in arrears"

Portfolio Management - User Guide - Release R15.000 - Page 60 of 208

In the screenshot below, the Safe custody Fees are calculated on a frequency that is set-up at the company level as the COMPANY.CALC is set
to ‘Y’. Thus for this company the value of the SAFECUSTODY.FREQ field on the SEC.ACC.MASTER records of customer portfolios will the
same as the CHARGE.FREQ field on the SAFECUSTODY.VALUES record. In this case the job SC.SAFE.ADV.CHG, run during the COB (Close
of Business), will check the system date against this date and if the date is less than the next working day, automatically calculate the Safe Cus-
tody Fees for all the customer portfolios on the system.

SEC.ACC.MASTER - Safe custody fees set-up

Whether the Safe Custody Fees are calculated company wide or on a portfolio basis the frequency of calculation will be shown in the Safe Cus-
tody Fees calculation fields on the SEC.ACC.MASTER record that defines the portfolio. The date of the next Safe Custody fees run for a port-
folio is held in the SAFECUSTODY.FREQ field together with the frequency of calculation. If the COMPANY.CALC field on
SAFECUSTODY.VALUES is set to “NO” then this field can be amended by the user, otherwise it is for information only. The date of the last
run and the ID of the SCSK.GROUP.CONDITION record that this portfolio is linked to are also given.

The COUNTRY.CHECK field allows user to define security domicile or security country domicile or stock exchange domicile based on which
system will calculate base amount for safekeeping Fees.

Portfolio Management - User Guide - Release R15.000 - Page 61 of 208

 SAFECUSTODY.VALUES - Country Check field

Portfolio Management - User Guide - Release R15.000 - Page 62 of 208

During the Close of Business the system will check the system date against the date in the SAFECUSTODY.FREQ field for any customer port-
folio where the PORTFOLIO.FEES date is AUTOMATIC and if the date is less than the next working day, automatically calculate the Safe Cus-
tody Fees for that portfolio.

Posting of Safe Custody Fees

Details of the calculated Safe Custody Fees will be written to the SAFEKEEP.HOLDING file. They will remain here to enable the Account
Officer of a particular portfolio to have an opportunity to review the calculated Safe Custody Charges and amend them if necessary before the
Safe Custody Fees posting is made

SAFEKEEP.HOLDING - Posting request

Note: Some of the fields can be amended such as the ACCOUNT.NO, VALUE.DATE, FOREIGN.CHG.LCY, DISC.AMOUNT.LCY and
LOCAL.FEES.LCY fields.

SAFEKEEP.HOLDING
The Portfolios can be locked at this stage in order to block any new back dated transaction which would have an impact on the
SAFEKEEP.HOLDING.

In case the portfolio is locked at the CALCULATED status and a new back dated transaction is input, then the same would not have any
impact on the SAFEKEEP.HOLDING record. Provided the locking date and is equal to or greater than Advisory charge frequency date. If the
locking is removed and a new backdated transaction is input, then the transaction will be processed as per the existing functionality.

Portfolio Management - User Guide - Release R15.000 - Page 63 of 208

The Portfolios can be locked at this stage in order to block any new back dated transaction which would have an impact on the
SC.ADVISORY.CHG.POSTED

For more information on Locking of portfolio, refer “Locking Client Reporting” User Guide.

Safekeeping Account Number

While generating safekeeping and management entries, a suspense account or an account belonging to another customer or portfolio can be
used in SAFEKEEP.HOLDING and SC.ADVISORY.CHG, in order to charge the customers.

Override messages are generated (same overrides as used in SEC.TRADE) when the account number is modified in
SAFEKEEP.HOLDING/SC.ADVISORY.CHG records or in SAFEKEEP.HOLDING.POSTED/SC.ADVISORY.CHG.POSTED
records.

Override messages will be generated as given in the matrix table below:

Application/Account Different Customer / Sus- Different Portfolio of same

Owner pense Account customer

SAFEKEEP.HOLDING Account Not part of this Portfolio Account Not part of this Portfolio
Owner

SAFEKEEP.HOLDING.POSTED Account Not part of this Portfolio Account Not part of this Portfolio
Owner

SC.ADVISORY.CHG Account Not part of this Portfolio Account Not part of this Portfolio
Owner

SC.ADVISORY.CHG.POSTED Account Not part of this Portfolio Account Not part of this Portfolio
Owner

1. When an account field is modified with an account of another portfolio, belonging to the same customer, the override message is gen-
erated as shown:

Portfolio Management - User Guide - Release R15.000 - Page 64 of 208

 SAFEKEEP.HOLDING_ACCOUNT NOT PART OF THIS PORTFOLIO

The account number modified in SAFEKEEP.HOLDING record is automatically updated in SAFEKEEP.HOLDING.POSTEDrecord.

This also applies for SC.ADVISORY.CHG and SC.ADVISORY.CHG.POSTED records.

2. When an account does not belong to the same customer, the override message is generated as shown.

Portfolio Management - User Guide - Release R15.000 - Page 65 of 208

 SAFEKEEP.HOLDING_A/C CUST DIFFERS FROM PORTFOLIO OWNER

When the account number is modified in SAFEKEEP.HOLDING record, the account is automatically updated in
SAFEKEEP.HOLDING.POSTEDrecord. This also applies for SC.ADVISORY.CHG and SC.ADVISORY.CHG.POSTED records.

An account can also be directly modified in SC.ADVISORY.CHG.POSTED/SAFEKEEP.HOLDING.POSTED record.

An example of SAFEKEEP.HOLDING.POSTED record for account number modified is as shown below:

Portfolio Management - User Guide - Release R15.000 - Page 66 of 208

 SAFEKEEP.HOLDING.POSTED_A/C CUST DIFFERS FROM PORTFOLIO OWNER

Once all the SAFEKEEP.HOLDING records have been reviewed the set-up of the SAFECUSTODY.VALUES application for the company con-
cerned can post the Safe Custody Fees. If the COMPANY.POST flag on SAFECUSTODY.VALUES is set to ‘Y’, i.e. the posting of Safe Custody
Fees is made for all the customer portfolios at the same time then the postings can be made by setting the POST.CHARGE field, associated
with SC in the CHARGE.TYPE field on the SAFECUSTODY.VALUES record, to “Y”. The charges will then be posted during the next Close of
Business. Alternatively they can be posted online by running the application SC.SAFE.FEES.POST.

Portfolio Management - User Guide - Release R15.000 - Page 67 of 208

 SC.SAFE.FEES.POST Application

If the COMPANY.POST flag is set to ‘Y’ then the only ID allowed is ‘ALL’ and the only fields where input is allowed are POST.ONLINE and
RETURN.OVERRIDE. Using the Input and authorisation function on this record will post all the unposted SAFEKEEP.HOLDING records for
the company.

SC.SAFE.FEES.POST – Example record

If the COMPANY.POSTflag is set to “NO” then the Safe Custody Fees can be posted for an individual portfolio or for all portfolios for a par-
ticular Account Officer (type ALL in the PORTFOLIO.NOfield). If the POST.ONLINE field is set to “NO” then the posting will take place in the
start of day phase of the Close of Business otherwise it will take place in real time. Again the Input (and Authorise) or Verify functions should
be used to affect the posting. Alternatively, the Safe Custody fees as in the table SAFEKEEP.HOLDING can be posted through the application
SC.SAFE.FEES.POST  by verifying the record. After the verification, the TSA.SERVICE record SC.SAFE.FEES.POST should already have been
started automatically. Further the service agent needs to be invoked by typing START.TSM -DEBUG at the jBase prompt and starting the
respective service agents manually. This will allow the processing of all the SAFEKEEP.HOLDING records with PROCESS.STAGE as
"CALCULATED” and post the safekeeping fees.

In case the portfolio is locked at the POSTED status and a new back dated transaction is input, then the same would not have any impact on
the SAFEKEEP.HOLDING.POSTED record for the blocked month. Provided the locking date is equal to or greater than Advisory charge fre-
quency date. If the locking is removed and a new backdated transaction is input, then an REPOST or ADJUST entry would be posted based on
the setup at Portfolio Level.

The field Fee.Adjustment.Type in AM.PARAMETER can hold values namely 'REPOST/ADJUST'. The values cannot be modified once set and
the default value is set to ADJUST. 'ADJUST' indicates posting of differential fees between already posted and the newly computed fees and
whereas the 'REPOST' indicates the new fees to be posted as a new entry and the old posted entries are to be reversed.

Portfolio Management - User Guide - Release R15.000 - Page 68 of 208

 AM.PARAMETER record-FEE.ADJUSTMENT.TYPE

The field FEE.ADJUSTMENT.TYPE is available in SEC.ACC.MASTER and defaults the value from the AM.PARAMETER and the same can be
amended by the user at any point in time at portfolio level.

Portfolio Management - User Guide - Release R15.000 - Page 69 of 208

 SAM record-FEE.ADJUSTMENT.TYPE

When a backdated transaction is input with the portfolio in unlocked status, then the system would REPOST/ADJUST as per the set up in
SEC.ACC.MASTER. The posting can be made to ADJUST at the SAFEKEEP.HOLDING.POSTED record level, by setting the field
ADJUST.FEES as YES and ADJUST.VALUE.DATE with a valid Value date. This will overwrite the setup at portfolio level.

Portfolio Management - User Guide - Release R15.000 - Page 70 of 208

 SAFEKEEP.HOLDING.POSTED record

The field ADJUST.FEES can hold the values YES/NULL. If this is set as 'YES', ADJUST.VALUE.DATE needs to be entered by the user.

The value date of posting the Adjustment Entries is entered in the field ADJUST.VALUE.DATE.

Portfolio Management - User Guide - Release R15.000 - Page 71 of 208

 SAFEKEEP.HOLDING.POSTED-Adjust

STMT.ENTRY - ADJUST.FEES is set to YES'.

Portfolio Management - User Guide - Release R15.000 - Page 72 of 208

 SAFEKEEP.HOLDING.POSTED-Adjust-STMT entry

CATEG.ENTRY - ADJUST.FEES is set to YES'.

SAFEKEEP.HOLDING.POSTED-Adjust-CATEG entry

Portfolio Management - User Guide - Release R15.000 - Page 73 of 208

 SAFEKEEP.HOLDING.POSTED-Repost

STMT.ENTRY - ADJUST.FEES is set to 'NULL'.

Portfolio Management - User Guide - Release R15.000 - Page 74 of 208

 SAFEKEEP.HOLDING.POSTED-Repost-STMT entry

CATEG.ENTRY - ADJUST.FEES is set to 'NULL'.

SAFEKEEP.HOLDING.POSTED-Repost-CATEG entry

Safekeeping Fees - Monthly Average Balances & Accruals

As an alternative to the previously described process, you may instead require to extend the average balance method so that this can be based
on the average daily balance for each month during the charge cycle.  This process enables fees to be accrued monthly to P/L while the contra
entry is posted to an internal suspense account. All calculations are performed in the System local currency.

This method requires some additional set-up and is intended to cater for instances where the charge frequency is global (i.e. the same for all
customers). It is not designed to run alongside the earlier described process.

Should your organisation already be using this earlier described process, you should first ensure that you have completed the current charge
cycle for all customers. You will then have to ensure that the COMPANY.CALC field on the SAFECUSTODY.VALUES file is set to "Y" so that
all customers are charged at the same time in accordance with the frequency defined in the CHARGE.FREQ field of the same file.

Safekeeping Fees - Setting-up for Daily Average Balance

To set-up this process, you should first define the requirement using the SAFECUSTODY.VALUES file.

SAFECUSTODY.VALUES - Setting-up average balances (Step 1)

Portfolio Management - User Guide - Release R15.000 - Page 75 of 208

You should set the DAILY.EXTRACT field to “Yes” to indicate that you wish the daily balances to be extracted and held on the
SC.SAFEKEEP.ACTIVITY and SC.ASSET.BAL file (described below).

SAFECUSTODY.VALUES - Setting-up average balances (Step 2)

In addition, as shown in the following screenshot, you would also need to set up the field AVERAGE.CLOSING on each of the
SCSF.CHARGE.PARAMETER file records to 'MONTH.AVERAGE'.

SCSF.CHARGE.PARAMETER - Setting to MONTH.AVERAGE basis

The field AVERAGE.CLOSING can be set to 'MONTH.AVERAGE' only if the DAILY.EXTRACT field on the SAFECUSTODY.VALUES file has
been set to 'YES'. The above set-up will advise the system to extract the daily balances into the SC.SAFEKEEP.ACTIVITY file. Since the data is
informational only, this file is what we call a “live” file and therefore you may only interrogate the data.

Portfolio Management - User Guide - Release R15.000 - Page 76 of 208

 SC.SAFEKEEP.ACTIVITY - Example activity

Positional details are stored monthly. The id of the record above indicates the following:

888-1 Portfolio number

Portfolio Management - User Guide - Release R15.000 - Page 77 of 208

 4447 Depository

003175-000 Security

200102 Year and Month (February 2001)

Within that particular record we can see the daily balance details

This particular position opened the month with a balance of 35,000 and 5th is the first working day of the month. There are only 6 working
days during the test month!

These average balances are calculated in the same way for both nominal and asset values. The nominal value shown in the above extract from
the SC.SAFEKEEP.ACTIVITY file is as follows:

Date Balance Days Products Avg Bal

5 35000 5 175,000 35,000.00

6 42000 1 42,000 36,166.67

7 55000 5 275,000 44,727.27

12 55000 8 440,000 49,052.63

20 55000 8 440,000 50,814.81

28 50000 1 50,000 50,785.71

Table 5  Calculation of Average Balance

The above extract illustrates how the average balance is computed – the test month was a February in a non-leap year, hence the 28 days total
number days.

Each end-of-month, the averaged nominal and asset value amounts are passed to the SAFECUSTODY.EXTRACT file for storage until the end
of the charge period.

Portfolio Management - User Guide - Release R15.000 - Page 78 of 208

 SAFECUSTODY.EXTRACT - Example

The above "live" file is used to store the closing monthly balances for each candidate position extracted from within the
SC.SAFEKEEP.ACTIVITY file.

These details are used collectively by the System to calculate the various charges that are then totalled on the SAFEKEEP.HOLDING file, of
which a description can be found earlier in this chapter.

Safekeeping Fees - Setting-up parameters for monthly accruals

The first step is to define a category to which you wish the monthly accruals to be posted. This can be done by specifying an appropriate cat-
egory code in the range of 11000 to 19999 as shown in the ACCRUAL.CATEG field below where CATEGORY 13333 has been opened for this
purpose.

Portfolio Management - User Guide - Release R15.000 - Page 79 of 208

 SAFECUSTODY.VALUES - Setting-up accruals

You now need to advise that you wish accruals to be made by setting the PERFORM.ACCRUAL field to “MONTHLY”.

SAFECUSTODY.VALUES - Setting-up accruals 2

This tells the System to perform accruals at each month-end. These accruals are based on the average daily balance for each month during the
charge cycle that in turn can be monthly, quarterly, half yearly or annually as required.

Accruals are performed at each month end and posted to the account opened using the ACCRUAL.CATEG value set-up and shown in the
SAFECUSTODY.VALUES extract above and an example STMT.ENTRY is shown in the next extract.

Portfolio Management - User Guide - Release R15.000 - Page 80 of 208

 STMT.ENTRY - Accrual safe custody fee

It can be seen the accrual is posted to the suspense account CHF-13333-0001. Accruals are always made in local currency which for this test
account happens to be CHF (Swiss Francs).

The contra entry to the above accrual to suspense is that made to the Profit and Loss account as in the next extract that illustrates a typical
CATEG.ENTRY record.

CATEG.ENTRY - Safe custody fees accrued profit

Portfolio Management - User Guide - Release R15.000 - Page 81 of 208

After posting of the fees, the field PROCESS.STAGE would be displayed as “POSTED”. The Statement Entries would also show the respective
entries as posted to the client’s account.

SAFEKEEPING FEE - Customer account update (STMT.ENTRY)

Safekeeping Fees Accrual Accounting Rules

Safekeeping fee accrual entries will be raised at month end as follows:

DR Safekeeping Fee Accrual A/C (SAFEKEEP.ACCR.ACCT on SEC.ACC.MASTER)

CR P&L (CR.CATEG.CODE on SAFECUSTODY.VALUES forCHARGE.TYPE ='SC')

If any adjustments are made to the calculated charges on the SAFEKEEP.HOLDING file then the system passes the adjustment entries to
adjust the accruals.

If charge has been increased then: 

DR Safekeeping Fee Accrual A/C with the increase

CR P&L with the increase

If the charge has been decreased then: 

CR Safekeeping Fee Accrual A/C with the decrease

DR P&L with the decrease

On final posting of the charges the accounting that follows is as shown under:

CR Safekeeping Fee Accrual A/C

DR Customer’s charge account

Portfolio Management - User Guide - Release R15.000 - Page 82 of 208

Safekeeping and Management Fees – Previous Month closing balance based
In addition to calculation based on Average or Closing balance as mentioned above, the user also has the ability to calculate the fee based on
previous month closing balance by setting AVERAGE CLOSING field to PREV.MONTH.CLOSE in SCSF.CHARGE.PARAMETER/SCPM
CHARGE PARAMETER. The only condition is that all the charge parameter records have to be set to PREV MONTH CLOSE if this method is
to be used. It will not be possible to have some records with PREV MONTH CLOSE set and others with CLOSING or AVERAGE.

The system will calculate the safe custody fee, foreign charges (depository charges) and the advisory charges on portfolio value or nominal (as
the case may be) as of previous month end. The portfolio base values as of previous month end will be picked up from the SAFECUSTODY
EXTRACT/SC ASSET BAL files (as the case maybe).

If the fee charge period is from January 1st to March 31st (Q1), the total fee for Q1 would be ((Value at end December * rate * month days/year
days) + (Value at end January * rate * month days/year days) + (Value at end February * rate * month days/year days).

The month days and year days would vary based on the Day Basis set in SAFECUSTODY.VALUES.

If there are any rate changes during the period, the system will re-calculate the fee for the entire period based on the current rate. However, if
there is a requirement to pro- rate the calculations based on rate changes during the period, the same can be achieved by setting the
DAILY.ACCR.TYPE field in SAFECUSTODY VALUES to DAILY.RATES.

For example, if there is a rate change from r1 to r2 on 11th of January, then the Q1 fee would be (PVbase of Dec * r1  for 10 days)+ (PVbase of
Dec * r2 for remaining Jan days)+(PVbase of Jan *r2 for Month days)+ (PVbase of Feb*r2 for month days).

If PREV MONTH CLOSE option is chosen, the fees are calculated based upon the portfolio value as of end of previous month. For the port-
folios opened in the middle of the charge period, there will be no balances as at previous month end. In such cases, the number of days from
the opening date to month end will be carried forward to the next month for the calculation of fees. The table below is self explanatory with
regard to portfolios opened at different stages of the charge cycle:

Portfolio opened in January Portfolio opened in Febru- Portfolio opened in

(first month) ary (second month) March (third
month)

Opening of a Opening on 20th January: Opening on 20th February: Opening on 20th March:
portfolio
Q1 will have 0 fee for January + Q1 will have 0 fee for January There will be no fee in
(PVBase at January end * rate for 40 + 0 fee for February + (PVBase Q1 and 12 days of Q1
days) + (PVBase at February end * rate at February end * rate for 40 will be added to Q2
for 31 days) days) (April days).

‘* - assuming Day basis as Actual and ‘* - assuming Day basis as ‘* - assuming Day basis
for a non-leap year Actual and for a non-leap year as Actual and for a non-
leap year

Fee Review within the charge cycle

With PREV MONTH CLOSE option, it will be possible to configure the system to calculate the fee for the whole calculation period on any day
of the last month of the charge cycle. As part of Close of Business processing on the day before the date specified in DAILY.POST.DATE, the
system will calculate the charge for the whole period based on parameters set and update the same in show-fee records – SAFEKEEP
HOLDING and SC ADVISORY CHG. They will enable the Account Officer to review the calculated charges, make amendments to the same and
post them within the charge cycle.

In our example, if the DAILY.POST.DATE is set to 1st, the fee records will be created with the full period charges as part of Close of business
on the last day of February. These will be available for the Account Officer to review on the 1st of March. The entire review and posting process
can be completed within the charge cycle. Otherwise, the fee records will be available for review only on the 1st of April which actually falls in
the next charge period.

Fee calculation on portfolio closure

If a portfolio is closed in the middle of the charge period, the fee will be calculated only till the closure date. The fee will be applied for number
of days from the last calculation period (or portfolio opening date whichever is later).

The following table illustrates the handling of closure at different stages of the charge period:

Portfolio Management - User Guide - Release R15.000 - Page 83 of 208

 Portfolio closed Portfolio closed Portfolio closed in March (third month) –
in January (first in February after show fee date
month) (second month)

Closure of a Closing on 20th Closing on 20th Closure on 10th March

portfolio January: February:
Fees will be (PVBase at December end * rate * Jan days)
Q1 will have Q1 will have + (PVBase at January end * rate * Feb days) + (PVBase
(PVBase at Decem- (PVBase at Decem- at February end * rate for 10 days).
ber end * rate for ber end * rate * Jan
20 days). The cal- days) + (PVBase at Since on show fee date, the whole period fee would have
culations will stop January end * rate been calculated and updated in SAFEKEEP.HOLDING
on that date for 20 days) and SC.ADVISORY.CHG, these need to be reworked. As
part of closure processing, these records would be
amended to include the fee only till closure date.

All the above processing – days carry over for newly opened portfolios, closed portfolios fee processing as above, pro-rating of fees for rate
changes and fee review within the charge cycle – will be allowed only for PREV MONTH CLOSE option for now.

A  SAFECUSTODY.VALUES record with all these parameters set is shown below:

SAFECUSTODY.VALUES

As mentioned in the “CALCULATION OF SAFE CUSTODY FEES” section above, the fees system works on a month basis for other methods of
fee calculation. For PREV MONTH CLOSE, however, the system would work on number of days basis. The number of days in the period will
be calculated based on the day basis set. The ranges specified in the CALC.TYPE field (PERIODIC.OPEN, PERIODIC.NORMAL, etc.) and the
associated fields (PERIOD.START, NO.OF.MONTHS, etc.) will not have a bearing on the fee calculation under this method.

Safekeeping and Management Fees – Daily Accrual

Daily accrual of safekeeping and management fees can be done if the fees are set to be calculated on the previous month closing balances. The
first step is to “switch on” the daily accrual in SAFECUSTODY.VALUES.

SAFE.CUSTODY.VALUES

PERFORM ACCRUAL tells the system to perform accruals on a daily basis if set to “DAILY”.

Different date ranges specified in the CALC.TYPE field (PERIODIC.OPEN, PERIODIC.NORMAL, etc.) would not have a bearing on the cal-
culations if Daily Accrual is set.

Accruals are performed every day and posted to the Profit and loss categories defined for the same. There can be different Profit and loss cat-
egories defined for safekeeping charges, depository charges and the management fees. Separate accrual entries will be raised for these different
types of fees.

Set of entries raised for a portfolio on a particular day in the fee cycle is shown below:

Portfolio Management - User Guide - Release R15.000 - Page 84 of 208

These entries have been raised for accrual of safekeeping and depository charges.

The contra entry to the above is a RE.CONSOL.SPEC.ENTRY (due pending capitalization) as shown below:

RE.CONSOL.SPEC.ENTRY

It is also possible to configure the system to raise accrual entries every day by reversing the previous accruals booked (I/O method). The cat-
egories for which the reversals and rebooking would be required need to be configured in ACCR. REV. PARAM.

Portfolio Management - User Guide - Release R15.000 - Page 85 of 208

 ACCR.REV.PARAM

In the above extract, I/O method of booking accruals has been configured for the management fee, safekeeping fee and depository charge cat-
egories.

Example shown above

In the above example, the accruals of earlier day have been reversed and rebooked (including the current day accruals).

If the calculated fee is amended prior to posting, then the accrual booked would also be adjusted to the extent of amendment.

Safe custody fees – Account balances for fee calculation

Account balances, in general, are not considered for safekeeping fee calculations. However, if there is a requirement to include designated
account balances for the purpose of safekeeping fee calculation, this can be done by configuring the same in SAFECUSTODY. VALUES

Portfolio Management - User Guide - Release R15.000 - Page 86 of 208

 SAFE.CUSTODY.VALUES

Based on this set-up, all accounts with currency ‘XAU” will now be included for fee calculation. For example, if metal trading is done for a port-
folio by using an ACCOUNT to hold the metal account balance and if safe keeping charges are to be levied for these holdings, then this func-
tionality can be used.

Safekeeping and Management Fees – Performing Daily Accruals

Daily accrual of fees can also be set-up for safekeeping and management fees. The first step is to “switch on” the daily accrual in
SAFECUSTODY.VALUES.

The accruals will always be for the exact number of days in the period. For example, if the charge period is from 1st January to 31st March
2007, on Feb 10th, the accrual would be for 41 days. On March 31st, the accrual would be performed for 90 days.

The accrual details are stored in EB.ACCRUAL, an extract of which is shown below:

Portfolio Management - User Guide - Release R15.000 - Page 87 of 208

 Example of EB.ACCRUAL

On realisation of the fee, the statement entries would be raised for debiting the client account. The contra for the same would be
RE.CONSOL.SPEC.ENTRY for capitalization of fees. Prior to realisation of the fee, the anticipated charge for the period is reflected in an F
entry which can be viewed in the STMT.ENTRY application.

After posting the fees, the field “POSTING STAGE” in SAFEKEEP.HOLDING would be changed to Posted.

Portfolio Management - User Guide - Release R15.000 - Page 88 of 208

 Example of SAFEKEEP.HOLDING

The statement entry and  RE.CONSOL. SPEC. ENTRY for the posting is shown below:

Example of a statement entry

Example of a RE.CONSOL.SPEC.ENTRY

Till the time of fee posting, the accruals performed daily in the next calculation period would include the fees pending. Once the posting is
done, the accruals will only be for the current period fees.

If the calculated fee is amended prior to posting, then the accrual booked would also be adjusted to the extent of amendment.

Wherethe DETAIL method has been defined in SCPM.GROUP.CONDITION /SCSK.GROUP.CONDITION the supporting detail for the fee cal-
culation can be viewed in the application SC.DAILY.ACCRUAL.DETAIL.

Accruals of Safekeep
Accruals of Safekeep Charges are posted in a separate identifiable accrual PL Category codes.

Following is the field available in SEC.ACC.MASTER application to post the accruals of Safekeep.

Portfolio Management - User Guide - Release R15.000 - Page 89 of 208

 1. SAFEKEEP.ACCR.PL

Field Name Description

SAFEKEEP.ACCR.PL Accrual PL category for Safekeep

Sample screen shot of SAFEKEEP.ACCR.PLin SEC.ACC.MASTER application.

Overrides in SEC.ACC.MASTER
In order to exclude Safekeep charges from valuations, the link between SAFEKEEP.CHRG.ACC and ACCOUNT.NOS fields in
SEC.ACC.MASTER application is removed.

Note: Override record is released with type as error, thereby giving flexibility to raise as error or override on Safekeep fees.

The field SAFEKEEP.ACCT.ACCT in SEC.ACC.MASTER allows to have internal account of different category, that are not specified in
ACCRUAL.CATEG field of SAFECUSTODY.VALUES

Sample screen shot of SEC.ACC.MASTER application raising an override.

Portfolio Management - User Guide - Release R15.000 - Page 90 of 208

Discount on Safekeep Fees
Discount on Safekeep Fees is posted in a different PL category code, in SAFEKEEP.HOLDING application.

Following is field available in SAFEKEEP.HOLDING application to post the discount on Safekeep.

Field Name Description

DISCOUNT.PL Profit loss category for discount posting.

To be defaulted from SAFECUSTODY.VALUES but can be over-

ridden.

Portfolio Management - User Guide - Release R15.000 - Page 91 of 208

Sample screen shot of DISCOUNT.PL in SAFEKEEP.HOLDING application.

SAFEKEEP.HOLDING - DISCOUNT.PL

Discount on Safekeep Holding Posted

Discount on Safekeep Fees is posted , in a different PL category code, in SAFEKEEP.HOLDING.POSTED application.

Following is field available in SAFEKEEP.HOLDING.POSTED application to post the discount on Safekeep.

Field Name Description

DISCOUNT.PL Profit loss category for discount posting.

To be defaulted from SAFECUSTODY.VALUES but can be over-

ridden.

Sample screen shot of DISCOUNT.PL in SAFEKEEP.HOLDING.POSTED application.

Portfolio Management - User Guide - Release R15.000 - Page 92 of 208

 SAFEKEEP.HOLDING.POSTED - DISCOUNT.PL

Portfolio Management - User Guide - Release R15.000 - Page 93 of 208

Updating A Portfolio

Once a portfolio has been defined on T24 , by inputting a SEC.ACC.MASTER record as described earlier, it can be updated by various T24
applications. There are essentially three ways of updating the value of a portfolio on T24 :

1. From an ACCOUNT linked to the portfolio

2. Through the Securities module.
3. Through the other T24 applications that are linked through the ASSET.TYPE file as described earlier

Updating a Portfolio from an Account

As can be seen from the description of SEC.ACC.MASTER above, a customer portfolio can be linked to accounts on the system. However,
because a customer may have several portfolios and any number of cash accounts, it is necessary when opening a SEC.ACC.MASTER to define
precisely which accounts belong to the portfolio. This is done using the appropriately named multi-value field ACCOUNT.NOS into which all
accounts that are to be linked to the portfolio must be entered.

When calculating the value of a portfolio the balance of those accounts will be included in the valuation. T24 takes the balance of the
ACCOUNT from the ONLINE.ACTUAL.BAL field on the ACCOUNT record for that ACCOUNT . T24 will prevent a user from closing an
ACCOUNT linked to a portfolio. The ACCOUNT must be removed from the SEC.ACC.MASTER record before it can be closed.

As the T24 Portfolio Management System will include any future Securities entries, then any forward accounting entries generated by the Secur-
ities module will be added to, (or subtracted from depending on the sign of the entry) the balance on the ACCOUNT record, to find the account
balance used by the Portfolio Management System.

By way of example, the next extract shows how an account may appear on a SEC.ACC.MASTER : where it can be seen that account
99990000000252 has been designated as belonging to the underlying portfolio.

SEC.ACC.MASTER - ACCOUNT.NOS set-up

Portfolio Management - User Guide - Release R15.000 - Page 94 of 208

Having set-up the new portfolio to include the id of any accounts belonging to the customer that are deemed to be part of the portfolio com-
ponents, we can now see how this affects the portfolio value by providing the customer with some funds.

FUNDS.TRANSFER - Funds to be invested

The extract above shows we have credited the account with GBP 100,000. To see how this affects the portfolio value, it is necessary to per-
form a portfolio valuation. This can be done on-line simply by running one of a number of enquiries that are described later in this User Guide.
For illustrative purposes, the enquiry SC.VAL.MARKET is run for the portfolio.

SEC.ACC.MASTER valuation after cash inflow

Now it can be seen how the account appears in the valuation. It is of interest to mention here that we can now appreciate how
SUB.ASSET.TYPE is used to provide a break and total in the enquiry.

Updating a Portfolio from the Securities Module

Any Securities transaction must include the id of one or more portfolios. Thus any transaction input into the Securities module would as a res-
ult update a portfolio with the value of that transaction. In addition to this, forward value security transactions are included in the portfolio
valuation.

Portfolio Management - User Guide - Release R15.000 - Page 95 of 208

Since portfolios must have one or more accounts associated with them, it follows that, for example, an against payment purchase would create
a security holding together with a reduction of the cash account from which the cost was met. The opposite applies should the portfolio be dis-
posing of a security, in which case, the value of the security is added to the customer account.

In cases where a security is received or delivered free, there is, of course, no cash movement except perhaps a processing charge of some form.

The Securities User Guide covers the use of Securities applications to update portfolios in greater depth.

Updating a Portfolio from Other Modules

Other non-SC applications can update a portfolio, subject to their having been linked to the securities module through the ASSET.TYPE file as
described earlier. We also saw how the FT application recorded the receipt of funds into a notional portfolio.

In all cases the user will have to make an input into the PORTFOLIO.NO field on the transaction concerned to update the portfolio. If the
PORTFOLIO.NO field is not updated then the system will not consider the transaction as being linked to the portfolio.

By way of example, we shall assume the customer has invested some of her cash into a deposit account with the Bank. In this case, the T24
LD application is used as in the following example transaction:

LD Deposit linked to portfolio

In this example, we can see that “1” has been entered into the  “PORTF.SUFFIX” field. Note the extract is a version and the true field name is
PORTFOLIO.NO.

However if the PORTFOLIO.NO had been left blank in the transaction then the contract will not be included in the valuation of portfolio 950-
1.

Note; The exception to this is when the module concerned (in this case LD)has been entered in the DEFAULT.SUFFIX field for the
SC.PARAMETERrecord keyed on the ID of the company in which the portfolio is included. If it has then when the system calculates the valu-
ation of the portfolio it will link any transaction for a portfolio customer which has a blank portfolio field to the portfolio of that customer with
the lowest suffix, i.e. if a customer had two portfolios 888-1 and 888-2 the transaction with a blank in the PORTFOLIO.NO field would be
linked to portfolio 888-1. For this reason, and to avoid erroneously allocating a transaction to an incorrect portfolio, it is recommended that
this facility be used only if all customer portfolios are set-up with a “-1” suffix, as described earlier.

To understand the process more fully, we shall run another valuation on the same portfolio so that we may see the deposit included.

Portfolio Management - User Guide - Release R15.000 - Page 96 of 208

 VALUATION showing customer deposit

In the above extract, it can be seen the customer’s current has been reduced from GBP 100,000 to GBP 75,000 as GBP 25,000 has been
taken on deposit by the Bank. This may be confirmed by drilling down and checking the current account movement.

VALUATION - Interrogating valuation details

Now we are able to confirm both the original and current balances and obtain details of cash movements.

In the example portfolio the cash GBP 25,000 has been invested in securities and therefore the portfolio value remains more or less constant
until, for example, the underlying securities are revalued.

Portfolio Management - User Guide - Release R15.000 - Page 97 of 208

Portfolio Modelling

T24 provides functionality to the user to define a portfolio investment model, link that model to a portfolio and produce comparisons between
the actual holdings of the portfolio against its model - both as hardcopy reports and screen enquiries. In addition, if the model is defined at a
Security level then the system can produce suggested buy and sell orders to put the holdings as close as possible in line with the model.

Defining a Portfolio Model - POLICY.PARAMETER

A portfolio model is defined on T24 by input of a POLICY.PARAMETER record . A POLICY.PARAMETER record can be defined at
SUB.ASSET.TYPE or ASSET.TYPE level and the type of model can be a SECURITY or COUNTRY model.

An example of a SECURITY level portfolio model defined at ASSET.TYPE level is shown below. As can be seen from the screenshot, the total
percentage of the model must equal 100. Elements within the model can consist of an ASSET.TYPE, which can further be broken down into
individual securities.

In the example, it can be seen that it is required that the portfolio maintains at least 15% of its value in cash. However, it is requested that the
remaining funds in any portfolio running under this model invest in the listed securities at varying percentages between 10 and 20%.

POLICY.PARAMETER - Example model

Maturity Bands within a Portfolio Model

This facility allows the grouping of securities instruments by maturity band when defining investment portfolios. This will generally apply to
bonds and ‘bond like’ instruments since few other instruments will have maturity dates. Maturity bands are defined within a portfolio and may

Portfolio Management - User Guide - Release R15.000 - Page 98 of 208

be in the form of days, weeks, months and years. Definition of the maturity bands involves entering a ‘from’ and ‘to’ period, which indicate the
period within which the maturity date of a security (on SECURITY.MASTER) must fall in order to satisfy the portfolio criteria.

POLICY.PARAMETER - Setting maturity bands

Please note that the setting up of maturity bands within a portfolio for asset or Sub.Asset types must be done at Security level. Failure to do so
or mixing Asset and Sub.Asset types may produce unreliable results. Once the portfolio model with maturity bands has been created in
POLICY.PARAMETER, it is advisable to re-run both the SC.PORT.COMPARE and SC.GROUP.COMPARE applications to ensure the validity
of the models and results produced.

Linking A Portfolio to a Portfolio Model - INVESTMENT.PROGRAM

A portfolio is defined on T24 through its SEC.ACC.MASTER record. On the SEC.ACC.MASTER record there is a mandatory field called
INVESTMENT.PROGRAMthat enables a SEC.ACC.MASTER record to be linked to an INVESTMENT.PROGRAM record. Invest-
ment.program  records are then linked to a POLICY.PARAMETER record using the POLICY.PARAMETER field as in the screenshot below.

INVESTMENT.PROGRAM - Linking to POLICY.PARAMETER record

Portfolio Management - User Guide - Release R15.000 - Page 99 of 208

Therefore any portfolio (SEC.ACC.MASTER ) record in which the field INVESTMENT.PROGRAM is set to “25” will be linked to the
POLICY.PARAMETER record “FUND01” Thus these portfolioswill use this model in comparisons of actual holdings against the pre-defined
investment model.

Portfolio Management - User Guide - Release R15.000 - Page 100 of 208

Securities Order Processing

Securities Order Processing Overview

Portfolio Management - User Guide - Release R15.000 - Page 101 of 208

Single Portfolio Comparison

SC.PORT.COMPARE
Given a portfolio entered on the T24 system with its current valuation a comparison can be made between its actual valuation and its asso-
ciated portfolio model.

SC.PORT.COMPARE - Single portfolio comparison

For example given the portfolio in the extract, 3005-1 is linked to POLICY.PARAMETER record UK-SECTOR, we can use the application
SC.PORT.COMPARE to produce an enquiry to show the differences between the models defined using this POLICY.PARAMETER and the
actual valuation of the portfolio. The application SC.PORT.COMPARE is completed as shown above. Notice the key to this file is the
ACCOUNT.OFFICER of the portfolio which in our case is “101” and that there is an option to print off the comparison. Should you wish T24
to build the required orders to shape the underlying portfolio so that it matches, as close as possible, the required model, you should enter
“YES” into the GENERATE.ORDERS field.

As mentioned, T24 will generate orders if requested. These are not real orders, known as SEC.OPEN.ORDER in the system, rather they are
known as SC.PORT.ORDER transactions. The request to build orders therefore builds a single SC.PORT.ORDER that contains the movements
of cash and security that would need to be processed in order to synchronise the underlying portfolio to the required model.

Whether or not the building of the orders has been requested, upon successfully running the program, you should be able to enquire upon the
results. This is done by running the ENQUIRY SC.PORT.COMPARE, an example of which can be seen below.

Portfolio Management - User Guide - Release R15.000 - Page 102 of 208

 ENQUIRY : SC.PORT.COMPARE - Results of program

As can be seen, this particular portfolio has too much cash in its Financial Accounts and does not have holdings in any of the preferred secur-
ities.

If, when running the program, the request was made to generate orders, then please proceed to the next section of your User Guide.

Single Portfolio Order Generation - SC.PORT.ORDER

The portfolio comparison displayed above would produce an SC.PORT.ORDER record that contained details of the potential orders for the 8
securities listed in the ENQUIRY SC.PORT.COMPARE. A sample of the SC.PORT.ORDER record generated by this ENQUIRY is shown below.

The actual record is quite long and therefore the extract has been reduced to show only the first two securities and the amount of potential
order to be made to bring the portfolio into line with the model requirements.

Portfolio Management - User Guide - Release R15.000 - Page 103 of 208

 SC.PORT.ORDER - result of SC.PORT.COMPARE

The system calculates the potential orders as follows:

It takes the valuation amount and using the percentage entered into the model it calculates an amount in the REFERENCE.CURRENCY of the
portfolio that represents that percentage of the total portfolio value. It then takes value for the asset concerned and compares the two to see if
there is any difference. If there is a difference the system compares this difference against the maximum and minimum tolerances defined for the
model element on the POLICY.PARAMETER record that defined the model. If the difference is outside the tolerance values then it takes the
market price of the security from the SECURITY.MASTER application and calculates how many securities would need to be bought or sold to
bring the portfolio back into line with its model.

In the screenshot above, the model has defined that portfolio 3005 -1 should have 5% of its value invested in “Betterware” GBP 50p Shares
(Security 003600-000).

The value of the portfolio 3005 -1 is currently 80,000 USD. Thus as 5% of 80,000 is 4,000 USD the value of portfolio 3005-1 holdings in
“Betterware” GBP 50p Shares should be approximately this amount.

This means that the preferred holding in the share should therefore comprise a value of USD 4,000 / 1.8834 (the current USD/GBP exchange
rate) = GBP 2,123.82. Note, there may be rounding differences as the final result depends upon the price per share of all the securities that
have to be bought/sold to produce as close a result as possible to the required model.

Since there are no holdings at all in the security, the recommended order is a purchase of 1,648 of the share for which the current market price
is GBP 130p (GBP 1.30 per share). This would cost GBP 2,142.40 or USD 4,035.01.

The process continues through all shares taking into consideration factors such as the minimum denomination, as would be the case for a
bond order.

NOTE, despite the fact that the result will be that required to being the portfolio components into line with the model requirements, you can
amend the SC.PORT.ORDER record to change the suggested orders. For example in the above extract you may wish to generate an order for
1,650 “Betterware” GBP 50p Shares rather than 1,648 recommended. Once you are satisfied that the SC.PORT.ORDER record is correct the ‘V’
(Verify) function can be used to generate SEC.OPEN.ORDER records from the SC.PORT.ORDER record. See the Securities User Guide for a
description of using SC.PORT.ORDER to generate Security Trades.

By way of example :

Portfolio Management - User Guide - Release R15.000 - Page 104 of 208

 SC.PORT.ORDER - Input mode

As can be seen above, you may change the order amount, the settlement currency, prices and exchange rate and so on before committing the
transaction.

Portfolio Management - User Guide - Release R15.000 - Page 105 of 208

Group Portfolio Comparison

SC.GROUP.COMPARE
The application SC.GROUP.COMPARE allows an Account Officer to undertake a comparison of all the portfolios under their control against
the models to which the portfolios are linked.

SC.GROUP.COMPARE - Example

As can be seen from the above, the Account Officercan choose to do the comparison for specific investment models or for all models. In both
cases only those portfolios for which the Account Officer is responsible are considered for inclusion in the modelling process. The key to the
SC.GROUP.COMPARE record, as with the SC.PORT.COMPARE application is the ACCOUNT.OFFICER. This will produce a comparison
ENQUIRY for the portfolios selected in the same way as the application SC.PORT.COMPARE.

However, for the application SC.GROUP.COMPARE there are four ENQUIRY records that can potentially be called, these are:

1. SC.GROUP.COMPARE.ASSET
2. SC.GROUP.COMPARE.COUNTRY
3. SC.GROUP.COMPARE.GEOGRAPHIC
4. SC.GROUP.COMPARE.SECURITY

Which ENQUIRY is called, depends on the value of the DETAIL.LEVEL field. For example, if the DETAIL.LEVEL field contains
”GEOGRAPHIC” then you are, by default, requesting a Geographical Block comparison of holdings against the model and therefore the
Enquiry SC.GROUP.COMPARE.GEOGRAPHIC will be used.

Alternatively, you may input a specific model to be run which will then be applied to all portfolios belonging to the ACCOUNT.OFFICER. The
following extract illustrates how a typical request is made.

Portfolio Management - User Guide - Release R15.000 - Page 106 of 208

 SC.GROUP.COMPARE - Account officer model request

The above request will process all portfolios having an INVESTMENT.PROGRAM that is linked to the POLICY.PARAMETER record
“FUND01”.

Group models are first input to create a record and subsequently verified, should you wish T24 to work out the necessary orders to raise to
shape the portfolios as set out in the particular model requested.

SC.GROUP.COMPARE - Verify and order request

If orders are required, then the GENERATE.ORDERS field should be set to “YES” either when creating the record or by inputting before the
verification stage of the transaction. Whether or not orders were requested, you may then examine the results by invoking the required
ENQUIRY, in this case, SC.GROUP.COMPARE.SECURITY.

Portfolio Management - User Guide - Release R15.000 - Page 107 of 208

 ENQUIRY - SC.GROUP.COMPARE.SECURITY (cut down)

In the extract, the original model shows at the top together with the required percentages of total portfolio holdings for 7 imaginary secur-
ities/funds and also shows that 15% of each portfolio should comprise cash.

Group Portfolio Order Generation - SC.SECURITY.ORDER

If the DETAIL.LEVEL field in the SC.GROUP.COMPARE application is set to SECURITY you may wish T24 to generate orders from the com-
parison. If you set the GENERATE.ORDERS field to “YES” then SC.SECURITY.ORDER records will be generated. These are not “real” orders,
rather these are requests to build the real orders, SEC.OPEN.ORDER transactions.

Portfolio Management - User Guide - Release R15.000 - Page 108 of 208

 SC.SECURITY.ORDER - List orders arising from GROUP comparison

There were seven preferred securities listed in the underlying model (POLICY.PARAMETER) and therefore seven orders are produced.

The three portfolios 925-1, 930-1 and 935-1 were recently set-up (new customers) and therefore their only asset was cash. T24 must therefore
build purchase orders for the preferred seven securities, as close as possible to the preferred percentage value of each portfolio total value.

Of course, this is a simple scenario to provide an example. It is possible that to shape a portfolio to fit in with its model, currently held secur-
ities may have to be sold to enable to purchase of new securities.

Examining the above, the first record shows an id of 151.222333-000 which indicates the account officer who made the request and the secur-
ity master file id.

The first portfolio, 925-1, has a cash only value as follows :

ENQUIRY - SC.VAL.MARKET portfolio "925-1"

The model preferred holding in this security is 10% of the portfolio value. Given the portfolio value, shown above, is GBP 115,000, the system
must calculate how many of these shares may be bought for GBP 11,500 (10% of GBP 115,000).

The result of this is shown in the next extract :

Portfolio Management - User Guide - Release R15.000 - Page 109 of 208

 SC.SECURITY.ORDER - "order" for security purchase

In which it may be seen the recommendation for portfolio 925-1 is a purchase of 822.53 units stock at the current price of 13.98125 per unit.
(The security is a unit trust and therefore fractions of a unit are permitted).

Portfolio Management - User Guide - Release R15.000 - Page 110 of 208

 SC.SECURITY.ORDER - Example record

The above extract shows a typical SC.SECURITY.ORDER transaction. Note that the  SC.SECURITY.ORDER is keyed on Account Officer and
Security Number.

The application SC.GROUP.COMPARE can generate a number of such records from a single comparison. In a similar way to the
SC.PORT.ORDER application these records can be amended before being committed to generate a SEC.OPEN.ORDER record. A single
SEC.OPEN.ORDER record generated by SC.SECURITY.ORDER will contain all the portfolios on the original SC.SECURITY.ORDER record,
thus allowing the Account Officer to bulk-up orders for all the portfolios under their control which have differences between the model and
actual holding in a particular security. When calculating the potential orders in the SC.SECURITY.ORDER record the same logic is used as that
applied in building the SC.PORT.ORDER record described above.

Portfolio Management - User Guide - Release R15.000 - Page 111 of 208

Order by Customer

The ORDER.BY.CUST application is a powerful front-end securities order generation process. Using user defined selection criteria the applic-
ation allows portfolio managers to obtain a selection of required portfolios and apportion the nominal amount bonds or number of shares
based upon the order type. These order types can allocate based on a variety of rules as listed below.

GENERAL POINTS – ORDER.BY.CUST – all order request types

Portfolios considered for the orders can be selected using any combination of fields from the main portfolio record SEC.ACC.MASTER.

When the suggested orders are calculated it is possible to amend the nominal before generating any orders. It is not possible to either add addi-
tional securities or portfolios to the suggested orders. If additional portfolios are required to be included then the selection criteria should be
modified to include them or additional transactions added with different criteria. Additions to the securities involved will require additional
ORDER.BY.CUST transactions.

There are a number of versions supplied with your T24 System that cover some of the order types, these are currently:

ORDER.BY.CUST, SELL
ORDER.BY.CUST, PURCHASE
ORDER.BY.CUST, SWITCH
ORDER.BY.CUST,CASH

These versions behave rather like an enquiry in that you may add one or more selection criteria using the standard fields from the
SEC.ACC.MASTER record (Portfolio files). For example, you could specify all portfolios having an INVESTMENT.PROGRAM of "25". Sim-
ilarly, it is possible to define both INVESTMENT.PROGRAM and MANAGED.ACCOUNT.

Service and Non-service based Orders

Non-service based option would list all the proposed Orders on the screen and users can make the amendments before committing the record.
On authorising the ORDER.BY.CUST record, the Orders are generated on HLD.

Service Option is used when the Proposed Orders exceed 50 nos. In this case, it is not possible to view the proposed orders on the screen.
Once the record is authorised, the service AM.SC.MOVEMENT automatically creates the proposed orders on HLD. The user can then
amend the records if needed.

Parent Child Orders

If the field PARENT.CHILD is set to YES, then the Orders created out of the ORDER.BY.CUST application will be Parent Child Orders . The
common reference to link the Parent Child Orders, needs to be specified in the field PARENT.REFERENCE

The following additional ORDER.TYPE can be processed by service or non service based option.

ORDER.TYPES:

TARGET:

When TARGET is entered the fields TRANS.TYPE.DB & TRANS.TYPE.CR must be populated, also the selection of TARGET will only be valid
when the field PERCENTAGE is used. It is not possible to use TARGET in conjunction with the fields ORDER.NOMINAL, GROSS.AMOUNT
or CASH.AMOUNT.

The value of the target percentage is compared to the value of the current security holding. The difference in these two values will be used to cal-
culate how many of the security need to be purchased or sold to achieve this value. If the percentage is specified as zero then the entire holding
will be sold.

PURCHASE.INCR:

The selection of PURCHASE.INCR is only valid when the field PERCENTAGE is used. It is not possible to use PURCHASE.INCR in con-
junction with the fields ORDER.NOMINAL, GROSS.AMOUNT or CASH.AMOUNT.

The value of the current holding is calculated and this value will be increased by the specified percentage. The difference in these two values will
be used to calculate how many of the security need to be purchased to achieve the new value.

SELL.PERC

Portfolio Management - User Guide - Release R15.000 - Page 112 of 208

The selection of SELL.PERC is only valid when the field PERCENTAGE is used. It is not possible to use SELL.PERC in conjunction with the
fields ORDER.NOMINAL, GROSS.AMOUNT or CASH.AMOUNT. The increase of a position by a certain percentage of the portfolio is already
possible using order type PURCHASE and setting PERCENTAGE as the amount of the position to be bought.

The calculated specified percentage of the valuation will be used to calculate how many of the specified security must be sold to achieve this
value. If the number of securities to be sold exceeds the current holding then only the current holding will be sold. The customer will not sell
short.

Example of the Order Types

The field NOMINAL.ROUNDING has the options NATURAL, UNDER or OVER, commissions and charges are not considered in the cal-
culations.

This method of rounding can be set on the ORDER. BY.CUST in the field NOMINAL.ROUNDING as it differs from the current apportionment
method where the nominal difference is allocated in proportion to the valuation amounts.

NATURAL or Null: is selected then the naturally rounded value will be used (i.e. <0.5 down , >0.5 up).

UNDER: The theoretical nominal will be rounded down to the lower trading unit

OVER: The theoretical nominal will be rounded up to the next trading unit.

The field INC.OPEN.ORDERS can be set to yes or no to either include or not include the current open orders in the calculations of the above
order types.

The valuation program will calculate the portfolio valuation including any open orders. This value of the open orders is stored in the
SC.POS.ASSET record in the following three fields, NET.OPEN.ORDER.NOM, NET.OPEN.ORDER.EST and NET.OPEN.ORDER.AI one for
the open order nominal, one for the value of the nominal and one for the accrued interest.

The total valuation amount including open orders is also stored in the SEC.ACC.MASTER record in the NET.OPEN.ORDER.VAL. When the cal-
culations above reference the valuation amount either the value including or excluding open orders will be selected depending on the setting in
INC.OPEN.ORDERS in ORDER.BY.CUST.

When you are happy you have specified the required selection criteria and security information T24 will search for candidate portfolios and
apportion the order nominal over each depending upon their overall values.

When authorised the ORDER.BY.CUST application will generate the SEC.OPEN.ORDER records from the suggested orders, portfolios with a
zero nominal will not be carried through.

The suggested method to obtain most benefit from the ORDER.BY.CUST application is to complete the relevant selection criteria.

Portfolio Management - User Guide - Release R15.000 - Page 113 of 208

When entering an order request to generate an amount of cash, a decision can be made as to whether to allow for potential charges, taxes and
commission that would be made once the request reaches SEC.TRADE status.

A field called CASH.AMOUNT represents the amount in cash that the fund manager will apply across all the portfolios that the application
selects.

Once this field has been populated with a cash amount the system will cross-reference this with field SECURITY.CURRENCY on the
SECURITY.MASTER record and it will assume the cash currency is the same. If the user at this point wishes to specify a different cash set-
tlement currency then fields SETTLE.CCY.DB for a SELL and SETTLE.CCY.CR for a BUY order can be modified. If the user selects a different
currency then he/she will have an option at this level to enter an exchange rate for the conversion, fields EXCH.RATE.DB for a SELL and
EXCH.RATE.CR for a BUY order are the fields to be entered.

This CASH.AMOUNT field is linked to another field, CU.CASH.AMOUNT. The field, NOMINAL, will take the default from CASH.AMOUNT
but once all the portfolios have been selected will give the users a manual override opportunity to tailor individual cash amounts per portfolio if
they so wish.

The field NOMINAL can now be updated and calculated as the fields MARKET.PRICE and MARKET.PRICE.CR depending upon whether the
trade is a purchase or sale will hold the current market price from the SECURITY.MASTER record.

The field, CU.CHRGS.DEF, is used to enable the specifying of the standard default for each portfolio that is selected. The default will be “NO”
but other options will be “NET” and “GROSS”. If the default “NO” is kept then the field default per portfolio for the fields CALC.CHRGS and
CASH.CHRGS will both be “NO”. If “NET” is chosen the field defaults will be “YES” and “NET” respectively. If “GROSS” is chosen then the
field defaults will be “YES” and “GROSS”. The user can still change individually these defaults per portfolio if required or otherwise continue
using these values.

The field, CALC.CHRGS, provides an option for the user to calculate charges automatically in the ORDER.BY.CUST application rather than hav-
ing to wait until the final SEC.TRADE is built. The default will be “NO” so as to keep existing functionality consistent for current users. If
“YES” is selected the system will calculate charges automatically now and populate the relevant fields.

The field, CASH.CHRGS, will enable the user to have the option to calculate charges and commission on a “NET” or “GROSS” basis.

If “NET” is chosen then the cash amount populated in the field CU.CASH.AMOUNT should include all charges and commissions. The system
will work out how much nominal the portfolio can purchase based on the current price inclusive of charges and commissions. The system will
make necessary adjustments down and purchase less nominal so as to take into consideration charges and commissions. The charges and com-
mission fields will then be populated in the same way as a normal SEC.TRADE.

If “GROSS” is chosen the system will calculate the nominal from the CURR.PRICE and add charges and commission on top.

This field will only allow input if the field CALC.CHARGES is set to “YES”.

The field, CASH.ROUNDING, is activated only if the field CU.CHRGS.DEF is set to “GROSS”. The options then will be EXACT or
UNDER/OVER.

There may be a situation when the nominal balance converted from cash including commission and charges will never be equal to the cash
amount originally selected. In this situation an adjustment will need to be made.

If EXACT is selected then the system will calculate the nominal balance to the nearest security unit from the cash amount specified including
charges and commissions. Any under or over adjustments will be taken from the CU.COMMISSION amount. This then gives the customer an
exact match to the cash amount initially specified.

If UNDER/OVER is specified then for a BUY transaction the cash amount will be adjusted down based on the nearest nominal amount includ-
ing commission and charges that can be purchased. For a SELL transaction the cash amount will be adjustment over based on the nearest nom-
inal including commission and charges.

The field, ADJUST.COMMISSION, accepts the input of “YES” or “NO”. If “YES” is selected then the system will automatically adjust the com-
mission if found necessary. if “NO” is selected then in the case of the system being unable to calculate the exact figure, a warning message will
be displayed thus giving the user the option to override.

The field, SPLIT.CHRGS, is used in conjunction with the field ORDER.TYPE when set to ”SWITCH”. If “SWITCH” is selected then you will be
able to specify in this field how the charges and commissions are applied. The default will be NULL but you will be allowed to input a range
from 0 to 100. This means that if 50 is entered into this field then charges and commissions will be calculated 50% on the BUY order and
50% on the SELL order. The system will automatically default between the BUY and SELL linked orders the remaining percentage i.e. if 50
entered in the SPLIT.CHARGES on the BUY side then 50 will default on the SELL side.

If you input 25 into this field then charges and commissions will be calculated 25 pct on the BUY side and 75 pct on the SELL side.

If 100 is selected then all charges and commissions will be on the BUY side only and no charges will be calculated on the SELL order.

Portfolio Management - User Guide - Release R15.000 - Page 114 of 208

The only exception to this is on a SELL transaction where compulsory charges are endorsed from the stock exchange i.e. CU.STAMP.TAX. In
this case commissions will be on a percentage basis but the CU.STAMP.TAX will be 100 pct.

Other fields, CU.BR.BK.COMM, CU.FOREIGN.FEE, CU.COMMISSION, CU.COMM.TAX, CU.STAMP.TAX, CU.EBV.FEES, CU.FEES.MISC,

CU.DISC.PCENT, CU.DISC.AMT, COMM.CODE, COMM.PERCENT, COM.TAX.CODE, COMTAX.BCUR and COM.TAX.XRTE will be pop-
ulated automatically by the system with the relevant amounts. Some fields are manually keyed, usually the case when there is no default. Those
that default will be dependent on the correct flag setting in fields CALC.CHRGS and CASH.CHRGS.

Depending on what fields are selected to drive this application ORDER.NOMINAL, GROSS.AMOUNT, PERCENTAGE or CASH.AMOUNT, the
field CU.CASH.AMOUNT per portfolio will be enriched with the cash equivalent.

Portfolio Management - User Guide - Release R15.000 - Page 115 of 208

Order by Customer Purchase

To illustrate the process, the following extract shows an imaginary ORDER.BY.CUST,PURCHASE. In this instance, the portfolio manager, 101,
has access to 4,000 of security id 003605-000, currently trading at GBP 5.725 a share.

By simply adding his id, the portfolio manager can enter the number of security he has available and T24 will check whether those portfolios
for which he is responsible have any available cash. This request has been flagged in the version by entering “YES” in the CASH.AVAIL.REQD
field. Those that have, will be considered eligible to purchase an amount of the stock. The actual amount of security allocated by the program
will depend upon the overall value of each eligible portfolio.

ORDER.BY.CUST,PURCHASE - Purchase version

Having entered the relevant information, it is possible to VALIDATE the transaction which will prompt T24 to work out the allocations of the
security using the criteria set in the order. The transaction then remains on view.

Note that the validate process enables you to have a preview of the results of the request as the transaction remains on view. On the other
hand, assuming all the minimum required information is present, the commit function would immediately process the transaction, making it
available for the next-stage authorisation process without your seeing the suggested orders.

The next extract, shortened to 2 multi-value fields, as there were 5 candidate portfolios eligible for a share of the 4,000 available security
offered, shows how the allocations are returned for the user for approval.

Portfolio Management - User Guide - Release R15.000 - Page 116 of 208

 ORDER.BY.CUST,PURCHASE - Suggested Orders

To calculate the allocations, T24 first works out the total value of the candidate portfolios and uses this total as a divisor as follows :

Portfolio Valuation Calculation of order allocation Allocation

940-1 89,641.07 4,000 / 386,050.77 x 89,641.07 = 929 round up 930

945-1 47,659.17 4,000 / 386,050.77 x 47,659.17 = 493 493

950-1 148,879.10 4,000 / 386,050.77 x 148,879.10  = 1,542 round up 1,543

955-1 57,204.76 4,000 / 386,050.77 x 57,204.76 = 592 592

3005-1 42,666.67 4,000 / 386,050.77 x 42,666.67 = 442 442

386,050.77 4,000

Table 6  - ORDER.BY.CUST – Allocation methodology

More often than not, there will be some rounding adjustments that are made according to the overall value of the portfolio as can be seen in the
above table.

Portfolio Management - User Guide - Release R15.000 - Page 117 of 208

Order by customer, Switch

The ORDER.BY.CUST application can generate orders to sell one or many different securities and reinvest up to the amount generated in one
or many other securities, resulting in an n-to-m relationship regarding the number of securities involved respectively in the sell and the buy side
of the switch order. It is therefore possible to process One-to-One, One-to-Many and Many-to-One orders. It should be stressed that the pro-
ceeds from the sale side of the transaction are the upper limit to be reinvested.

On the sell side of the switch operation, the user can specify the percentage(s) (in value) to be sold for each security in PERCENTAGE.DB.
Each security can therefore be assigned up to 100%. Similarly, on the buy side the user can allocate the amount generated by the sell to each
security. This means that the sum of the allocations for all buy-side securities should be 100% or less that will be input in
PERCENTAGE.CR

Multiple securities can be selected for the “sale” and the “buy” side of the operation, but no duplicate security id’s can be involved in the order.
The securities that are intended to be sold must be specified in the filed SECURITY.NO.DB that can be multi-valued to specify any number
ofSECURITY.MASTERrecords. Similarly, the target securities for which the resultant buy order needs to be generated should be input in
SECURITY.NO.CR whichagain is a multi-value field thereby enabling the user to sell and buy multiple securities in a single order.

The Order types that are available in ORDER.BY.CUST are MARKET, BEST, PRICE, and STOP as defined inSC.ORDER.TYPE. When a
limit order type is specified, it will be mandatory to provide the LIMIT.PRICE for valuation purpose instead of the market price defaulted
from LAST.PRICE in SECURITY.MASTER.

The price of the “sale” security can be specified by the user in the field MARKET.PRICE.DB. If the price is not provided, T24 will use the
last known price in the SECURITY.MASTER record to calculate the cash amount that will result from the security’s sale. The cash generated
will be allocated 100%in proportion to percentages specified on the buy side of the other securities.

For the “buy” side, price has to be provided in MARKET.PRICE.CR and when not supplied with this information, will be defaulted from the
LAST.PRICE value in the respective SECURITY.MASTER record.

One settlement currency can be defined for both sides of the operation. This will be used to guide the system to select the correct accounts
from each customer’s portfolio i.e.T24 will look into each customer portfolio and select a customer account in the settlement currency. If such
account does not exist, another account (typically the first account in the SEC.ACC.MASTER list) will be selected for the debit / credit of the
transactions’ cash.

The customer cash account selection is done on the following priorities:

If a transaction is done in a currency for which the customer portfolio has an account, that account will take priority. If a transaction is done in
a currency for which the portfolio has NO account, then the account in the REFERENCE.CCY is to be used. The user may choose the
SETTLEMENT.CCY at the ORDER.BY.CUST level, which will enable the choice of customer account to be defaulted for the settlement of
the Trade. Please note that the SETTLEMENT.CCY on the Sell and Buy sides will have to be the same.

The SECURITY.CCY.DB and SECURITY.CCY.CR are automatically populated from the respective SECURITY.MASTER records for each
of the specified securities on the BUY/SELL side.
The currency exchange rate to be used in case the settlement currency is different from the security currencies can be defined by the user. If
not specified, the last recorded FX rate (with a customer spread applied) between the two currencies will be used.

The minimum trading unit is defaulted by T24 as per definition in the SECURITY.MASTER record of each security involved, but can be over-
ridden. This information is therefore defaulted in the field TRADING.UNIT.DR from the SECURITY.MASTER records and by the same rule
in TRADING.UNIT.CR for the buy side.

Provision also has been made to give the broker details for each of the buy/sell multi-value sets, which will be carried over to the
SEC.OPEN.ORDER. To provide details of sell side execution, enter a valid broker id in the BROKER.NO.DB field. In case, the user has
details of the buy side execution details, the details may be input in BROKER.NO.CR.

The user also has the option to define the (preferred) STOCK.EXCHANGE for the trades and if unspecified, T24 will default each security’s
primary stock exchange as defined in the SECURITY.MASTER record.  This can be overridden later on by the dealers.

An order may be passed on to a particular trader specified in TRADER.CODE,which should be a valid DEPT.ACCOUNT.OFFICER record.
There is provision for input of instructions or comments, to be passed on to the dealers in TRADER.DESC, at the ORDER.BY.CUST level.
This is a multi-value field to record any message or instructions to the trader concerned, which is carried over to SEC.OPEN.ORDER.

Since Switch Orders are enabled to sell & buy multiple securities through a single bulk order, the DEAL.STATUS of the Order will be
TRADED.To generate these Orders via the Service Agent, the field AUTO.SELECT has to be set as SERVICE.

Portfolio Management - User Guide - Release R15.000 - Page 118 of 208

The sale consideration from the first leg of the switch order can be inclusive/exclusive of any open orders that may be in the system. Open
Orders are those that are not authorised, put on hold, deleted or failed. This is controlled at the parameter level file SC.STD.SEC.TRADE where
the field INCL.OPEN.ORDERS can be set to value YES or NO. This may be overridden at the ORDER.BY.CUST level by the user, to spe-
cify if the sale consideration should include/exclude any open orders that may exist in the system for the selected portfolios by entering appro-
priate value in the field INCL.OPEN.ORDERS.

A simple Switch Order between 2 securities is illustrated below:

ORDER.BY.CUST - Switch operation

In this instance, it is simply a case of entering the selection criteria for the customers who you wish to be included, whether or not they hold
the source security.

Next, enter both the TRANS.TYPE.DR for the source security and its id in the SECURITY.NO.DB field. Move on and enter both the
TRANS.TYPE.CR for the target security and its id in the SECURITY.NO.CR field.

Once this is done, you may validate, with AUTO.SELECT set, to see the results without committing the transaction. The next screen shot illus-
trates the result of this action.

Portfolio Management - User Guide - Release R15.000 - Page 119 of 208

 ORDER.BY.CUST - Proposed orders

It can be seen that a portfolio matching the selection criteria with a holding in the specified security to sell has been located. The sell amount
has been calculated based on percentage entered on the sell side transaction, the buy amount has been calculated based on the proceeds gen-
erated from the sale side and the percentage entered on the buy side of the transaction. In this case 50% of the holding has been sold 100% of
this amount has been used to purchase the buy security.

Portfolio Management - User Guide - Release R15.000 - Page 120 of 208

Order by Customer,Cash

The cash order enables you to specify a percentage of securities to sell in order to raise cash for a single portfolio (SEC.ACC.MASTER).

A cash order is entered as follows :

ORDER.BY.CUST,CASH - Example transaction

In this instance, the request is to sell 25% of each security holding. It is important to note that the request is interpreted as you wish to sell
25% of the holding in each security.

Should any holdings be located, then upon validating, T24 returns the result as illustrated in the next extract.

Portfolio Management - User Guide - Release R15.000 - Page 121 of 208

 ORDER.BY.CUST,CASH - Result of 25% sale request

In the above extract, it can be seen that the suggested order amounts are located into the NOMINAL fields, each representing 25% of the ori-
ginal holding in each security.

Portfolio Management - User Guide - Release R15.000 - Page 122 of 208

Order by Customer,Sell

The sale function, as implied by the version name, allows the specifying of a number of a security to be sold. Depending upon the selection cri-
teria, T24 will locate any candidate holders of the security and produce sale requests on their behalf. The amount allocated to each holder
depends upon the amount they currently hold.

The following extract shows how a typical request can be made for which the account officer, 101, requires 2,250 shares for whatever reason.

ORDER.BY.CUST,SELL - Example sale request

In the above extract, it can be seen that the entry of the number of shares to be sold and the id of these shares is sufficient. As described
earlier, once the basic requirements have been set, validating the transaction will display the suggested orders by keeping the transaction on
view.

Portfolio Management - User Guide - Release R15.000 - Page 123 of 208

 ORDER.BY.CUST,SELL - Suggested orders

In this case, despite a request to sell, 2,250, T24 has actually suggested 3 orders of 402 + 803 + 1045 totalling the required 2,250 to be dis-
posed of.

The above examples are very, very simple. It is possible to set-up complex selection criteria in the ORDER.BY.CUST versions using the multi-
value field sets that enable the search to include one or more fields from the portfolios (SEC.ACC.MASTER).

Note: Since some order requests may well result in the location of many candidate portfolios, the details of which could straddle a large
number of displayable screens, the total of the allocation is shown at the top of the transaction upon validation of a request.

Portfolio Management - User Guide - Release R15.000 - Page 124 of 208

Service Based Orders

Dealer Book and memo portfolios: Service based

Dealer book portfolios and memo accounts will not be selected as part of the initial generation nor will it be possible to add details for a dealer
book portfolio or a memo account.

Rounding – Service based

Rounding Rules

When an order nominal has been specified and the total initial allocations for the customers do not match the order nominal then the difference
will be added or subtracted to customers using the following rules, if the total customer nominal exceeds the order nominal then the difference
will be subtracted from the largest customer nominal using the security trading units or rounding factor (if specified), if the total order nominal
exceeds the total customer nominal’s then the difference will be added to the smallest customer nominal using the security trading units or
rounding factor (if specified). After each addition or subtraction the largest and smallest customer nominal’s will be re-assessed before the next
addition or subtraction.

This method of rounding is different from the current apportionment method and so will be determined by the field ROUNDING.TYPE in the
ORDER.BY.CUST record. There is a selection option of High / Low or proportion.

These options are only available when the service agent is run:

Proportion = Current functionality

The high / low are used as follows:

Under filled order

An ORDER. BY.CUST placed to fill an order of 50,500, but on the first selection the order can only be filled for 49,000 so we have an under
filled order. The option of low will apply; meaning the customer with the lowest nominal will be allocated a further nominal amount. The pro-
cess will re cycle and allocate again based on this criteria until the order nominal of 50,500 has been filled.

Over filled order

The same order is placed for 50,500, but the first selection the order can only be filled for 52,000 so we have an over filled order. The selec-
tion of high will mean that customer with the highest nominal amount will have the nominal reduced and recycled until the nominal order
amount of 50,500 is achieved.

Portfolio Management - User Guide - Release R15.000 - Page 125 of 208

Parameter Set up

SC.STD.SEC.TRADE
To enable the generation of orders via the service agent the parameter file SC.STD.SEC.TRADE must be set up as the following example:

Example of a SC.STD.SEC.TRADE

The field TRADE.CREATION controls the SEC.TRADE creation from SC.EXE.SEC.ORDERS.

Example: If Trade Creation is 'BY.PORTFOLIO' then SEC.TRADE's will be created for each Portfolio.

Validation Rules

l Valid options are 'BY.CUST', 'BY.DEPO', 'BY.BROKER', 'BY.PORTFOLIO'.

l Optional Input.
l 'BY.CUST' and 'BY.PORTFOLIO' are not supported for service-based orders.

Portfolio Management - User Guide - Release R15.000 - Page 126 of 208

Process work flow for service based orders

Simple flow for ORDER.BY.CUST – SEC.TRADE

ORDER.BY.CUST

Enter OBC input,

Ensure field AUTO.SELECT is set to SERVICE

Service agent AM.SC.MOVEMENT will auto start

Results OBC in INAU plus SC.OBC.CUST.DETAIL inlive.

Example of a service based ORDER.BY.CUST

Portfolio Management - User Guide - Release R15.000 - Page 127 of 208

 List of the SC.OBC.CUST.DETAIL generated from the ORDER.BY.CUST

SC.OBC.CUST.DETAIL example

Portfolio Management - User Guide - Release R15.000 - Page 128 of 208

ORDER.BY.CUST / SEC.OPEN.ORDER

Authorise ORDER.BY.CUST agent AM.SC.MOVEMENT will auto start.

Results SEC.OPEN.ORDER generates in IHLD, live SC.OBC.CUST.DETAIL will be moved to history

Create SC.SOO.CUST.DETAIL in IHLD

Example of a SEC.OPEN.ORDER generated from the ORDER.BY.CUST

Portfolio Management - User Guide - Release R15.000 - Page 129 of 208

 List of the SC.SOO.CUST.DETAIL generated

Portfolio Management - User Guide - Release R15.000 - Page 130 of 208

 SC.SOO.CUST.DETAIL example

SEC.OPEN.ORDER

Input basic details on SEC.OPEN.ORDER

Once input details agent SEC.OPEN.ORDER.SERVICE will auto start

Results allows authorisation of SEC.OPEN.ORDER plus SC.SOO. CUST. DETAIL go to INAU

Portfolio Management - User Guide - Release R15.000 - Page 131 of 208

 SEC.OPEN.ORDER example

Portfolio Management - User Guide - Release R15.000 - Page 132 of 208

 SC.SOO.CUST.DETAIL example

Once authorised service agent SEC.OPEN.ORDER.SERVICE auto starts.

Enter broker details, price, etc, input status to TRADED

Portfolio Management - User Guide - Release R15.000 - Page 133 of 208

 SEC.OPEN.ORDER updated with TRADED

Auto start of service agent SEC.OPEN.ORDER.SERVICE

Allows authorisation of SEC.OPEN.ORDER plus SC.SOO. CUST. DETAIL go to live

SC.SOO.CUST.DETAIL in live

Portfolio Management - User Guide - Release R15.000 - Page 134 of 208

Generates IHLD SEC.TRADE  plus SC.SEC.TRADE.CUST.DETAIL in IHLD

SEC.TRADE generated in IHLD

Portfolio Management - User Guide - Release R15.000 - Page 135 of 208

 SC.SEC.TRADE.CUST.DETAIL example

Portfolio Management - User Guide - Release R15.000 - Page 136 of 208

 SC.SEC.TRADE.CUST.DETAIL example

SEC.TRADE

Update SEC.TRADE with settlementdetails contract will now go to INAU

Service agent SEC.TRADE.SERVICE will auto start.

SEC.TRADE is now in INAU and SC.SEC.TRADE.CUST.DETAIL are in INAU

Portfolio Management - User Guide - Release R15.000 - Page 137 of 208

Portfolio Management - User Guide - Release R15.000 - Page 138 of 208
 SEC.TRADE in INAU

SC.SEC.TRADE.CUST.DETAIL in INAU

Portfolio Management - User Guide - Release R15.000 - Page 139 of 208

Update the SC.SEC.TRADE.CUST.DETAIL with settlement detailsauthorise the SEC.TRADE and agent SEC.TRADE SERVICE will start.

SEC.TRADE and SEC.TRADE.CUST.DETAIL are now live and the SC.SETTLEMENT records will have been produced.

SC.SETTLEMENT record FHLD

SC.SETTLEMENT

Settle broker details (SEC.TRADE)

Service agent SC.SETTLEMENT.SERVICE will auto start and record will go to FNAU

SC.SETTLEMENT record FNAU

Settle / authorise  customer details if settlement is required, authorise broker settlement.

Portfolio Management - User Guide - Release R15.000 - Page 140 of 208

SC.VALUATION.EXTRACT

This file may be used to export portfolio valuation information in a flat file format (i.e. without multi-values). This may be useful to enable the
compilation of various external reporting tools such as Crystal Reports.

It is built from the information in the SC . POS.ASSET file, but it produces a record in SC.VALUATION.EXTRACT foreach security holding,
account or contract that is linked to a portfolio.

To use this functionality the BATCH job SC.VAL.EXTRACT must be set to run. This process can be run in a single company environment or a
multi-company environment where the same products are installed in all the companies that use securities.

BATCH - SC.VALUATION.EXTRACT

Provided, the job has been requested as above, then the COB end of day will produce a required flat file (i.e., without multi-value fields). The
records are very similar to the SC.POS.ASSET that is produced by the standard valuations program.

Portfolio Management - User Guide - Release R15.000 - Page 141 of 208

Margin Calculation

Standard Calculation
If there is no value in the MARGIN.VALUE field in the SC.PARAMETER then standard margin calculation will be used.

Margin Calculation for Securities Assets

The margin value of a security holding is calculated using the MARGIN.CONTROL field on the SECURITY.MASTER record multiplied by the
nominal holding. If a MARGIN.CONTROL has not been entered on the SECURITY.MASTER then the margin value is calculated using the
SEC.MARGIN.RATE on the relevant SUB.ASSET.TYPE record. If there is no input in either of these fields then the margin value of the holding
is assumed to be zero.

It is also possible to set different Margin Rates for the same Security, for different Companies, in a multi-company environment. This is done
using the tabel SC.SECURITY.MARGIN.

SC.SECURITY.MARGIN

The ID is the SECURITY MASTER ID* COMPANY. If a Margin record does not exist for a specific company, then the margin from SM is
applied. Duplicate company code is not allowed (that is only one margin rate can be defined per company).

Margin Calculation for Non Securities Assets and Liabilities

If an ASSET.BY.CATEG record exists for the category of the asset or liability then the MARGIN.RATE field on this record is used for the mar-
gin calculation. If there is no ASSET.BY.CATEG record, then the SEC.MARGIN.RATE on the relevant SUB.ASSET.TYPE record is used. If
there is no input in this field, then the MARGIN.RATE field on the associated ASSET.TYPE record is used. If no margin rate has been input in
any of these records, then the margin value of the asset or liability is assumed to be zero.

Summary
MARGIN.RATE on SC.PARAMETER = Null

Portfolio Management - User Guide - Release R15.000 - Page 142 of 208

 Securities Non Securities Assets Non Securities Liabilities

1 SC.CUSTOMER.MARGIN - Please see Table ASSET.BY.CATEG - Based on field ASSET.BY.CATEG - Based on field
below for defaulting order MARGIN.RATE MARGIN.RATE

2 SC.SECURITY.MARGIN SUB.ASSET.TYPE - Based on field SUB.ASSET.TYPE - Based on field

SEC.MARGIN.RATE SEC.MARGIN.RATE

3 SECURITY.MASTER - Based on field ASSET.TYPE - Based on field ASSET.TYPE - Based on field

MARGIN.CONTROL MARGIN.RATE MARGIN.RATE

4 SUB.ASSET.TYPE - Based on field Else Margin Rate = 0 Else Margin Rate = 0

SEC.MARGIN.RATE

5 ASSET.TYPE - Based on field MARGIN.RATE

6 Else Margin Rate = 0

Table 2  Standard Calculation Margin Rates Summary

Alternative Calculation - Different Loss Margin Rates

The following margin value calculation will be used if the MARGIN.VALUE field in the SC.PARAMETER is set to BOTH.

Loss Margin can also be defined in the SECURITY.MASTER and DX.CONTRACT.MASTER

Margin Calculation for Securities Assets

The standard method is used with the additional criteria that if there is no margin rate derived from the SECURITY.MASTER or
SUB.ASSET.TYPE, then the MARGIN.RATE field on the associated ASSET.TYPE record is used. The holding may have a margin value of zero,
only if this field is left blank by the user.

Margin Calculation for Non Securities Assets and Liabilities

Non-securities assets follows the standard method for margin calculation. The same application records are used to check the Liabilities and to
derive the margin rate but uses a different set of fields. The LOSS.MARGIN.RATE field on the ASSET.BY.CATEG is used for this purpose. If
there is no ASSET.BY.CATEG record, then the LOSS.MARGIN.RATE field in the SUB.ASSET.TYPE is used. Again, if this is not present, then
the LOSS.MARGIN.RATE field in the ASSET.TYPE is used. Further, if it also not populated then a zero rate is used.

Summary
MARGIN.RATE on SC.PARAMETER = BOTH

Securities Non Securities Assets Non Securities Liabilities

1 SC.CUSTOMER.MARGIN - Please see Table ASSET.BY.CATEG - Based on field ASSET.BY.CATEG - Based on field
below for defaulting order MARGIN.RATE LOSS.MARGIN.RATE

2 SC.SECURITY.MARGIN SUB.ASSET.TYPE - Based on field SUB.ASSET.TYPE - Based on field

SEC.MARGIN.RATE LOSS.MARGIN.RATE

3 SECURITY.MASTER - Based on field ASSET.TYPE - Based on field ASSET.TYPE - Based on field

MARGIN.CONTROL MARGIN.RATE LOSS.MARGIN.RATE

4 SUB.ASSET.TYPE - Based on field Else Margin Rate = 0 Else Margin Rate = 0

SEC.MARGIN.RATE

5 ASSET.TYPE - Based on field MARGIN.RATE

6 Else Margin Rate = 0

Portfolio Management - User Guide - Release R15.000 - Page 143 of 208

 Table 3  Alternative Calculation - Different Loss Margin Rates Summary

Alternative Calculation - Assets Only

The following margin value calculation is used, if the MARGIN.VALUE field in theSC.PARAMETER is set to ASSET.

Margin Calculation for Securities Assets

The standard method is used with the additional criteria that if there is no margin rate derived from the SECURITY.MASTER or
SUB.ASSET.TYPE, then the MARGIN.RATE field on the associated ASSET.TYPE record will be used. Only if this is also not input will the
holding be assumed to have a margin value of zero.

Margin Calculation for Non Securities Assets and Liabilities

Non-securities assets follows the standard method for margin calculation. All liabilities has a margin value of zero.

Summary
MARGIN.RATE on SC.PARAMETER= ASSET

Securities Non Securities Assets Non Securities Liab-

ilities

1 SC.CUSTOMER.MARGIN - Please see Table below for ASSET.BY.CATEG - Based on field Margin Rate = 0
defaulting order MARGIN.RATE

2 SC.SECURITY.MARGIN SUB.ASSET.TYPE - Based on field

SEC.MARGIN.RATE

3 SECURITY.MASTER - Based on field MARGIN.CONTROL ASSET.TYPE - Based on field MARGIN.RATE

4 SUB.ASSET.TYPE - Based on field SEC.MARGIN.RATE Else Margin Rate = 0

5 ASSET.TYPE - Based on field MARGIN.RATE

6 Else Margin Rate = 0

Table 4  Alternative Calculation - Assets Only

Margin Calculation of Derivative Positions

Apart from the above, for Derivative positions, a different approach is used for Margin Calculation.

While calculating the Margin Value of a Portfolio, the value of Derivative positions can be totally ignored. However, if there is a Negative Expos-
ure on account of Derivative positions, the same can be treated as a Liability by including the exposure in the SHORT.POS.MARGIN field in
SEC.ACC.MASTER.

DX.PARAMETER

Portfolio Management - User Guide - Release R15.000 - Page 144 of 208

 1. MARGIN.CALC.RTN - To define routine to be used for Margin rate calculations.
2. NETTING.REQD - If set to YES fields SAME.STRIKE, MATURITY.DAYS and EXPOSURE.CALC can be input.
3. SAME.STRIKE -If is set to YES, the contracts which has the same strike are netted together. Else the system will not consider the
Strike Price while netting.
4. MATURITY.DAYS - Days mentioned is considered as netting parameter and all transactions within that No. of days is grouped
together for netting.
5. EXPOSURE.CALC -Allowed values are ‘MAX.NEGATIVE’ or "TOTAL.NEGATIVE" to specify, if Maximum Negative or Total Neg-
ative exposure needs to be considered.

Calculations

In order to calculate the Negative Exposure on account of derivative positions, following calculations are done

1. Positions are grouped together if they have the same

l Underlying
l Strike - This will depend on the Parameter setting in field SAME.STRIKE
l Maturity range - The No of days to consider depends on value in MATURITY.DAYS field in DX.PARAMETER
(N). System finds the earliest maturing transaction among the group (A). Then transactions which Mature within 'N'
days from 'A' alone is grouped together. Any transactions maturing beyond 'N' days are ignored for the calculations
2. In each Group, if there are any Covered Calls, these transactions are ignored to the extent that they are covered.
3. In each Group, similar Positive positions can be netted against similar Negative positions for example; A buy call can be netted against
a sell call. If the Net value is positive, it shall be ignored. If however, the Net value is Negative, then it is added as an Exposure.
4. The final Negative exposure depends on the parameter value in field EXPOSURE.CALC. If this is set to "TOTAL.NEGATIVE" then the
sum total of all Negative exposures calculated in Step 3 is taken and updated to the SHORT.POS.MGN.AMT field in
SEC.ACC.MASTER

If the field is set as 'MAX.NEGATIVE', then the Maximum of all the Negative exposures alone is updated to the
SHORT.POS.MGN.AMT field in SEC.ACC.MASTER

Portfolio Management - User Guide - Release R15.000 - Page 145 of 208

 The SHORT.POS.MGN.AMT field plays an important role in determining the Liabilities of the Portfolio and is used in cal-
culating the Security Margin Ratio of a Portfolio. Any addition to this field on account of Negative DX Exposure results in
reducing the overall collateral value of the Portfolio.

Note: For this functionality to work the field ADJ.SHORT.POS in OV.PARAMETER should be set to "NO".

Refer the section Short Positions and Other Liabilities, for details on Short Positions.

Currency Volatility Margins

The maximum amount that can be borrowed against the portfolio is called the Security Value of the portfolio and is determined by applying
Loan to Value Ratio (LVR) assigned to each security/group of securities/assets/liabilities in the portfolio. The Security Value is also known as
the Margin Value and the LVR is also known by the term Margin Rate.

For example, if a client holds a security with market value of USD 5000 and a margin rate of 80%, the security value of the portfolio will be
USD 4000 (5000 * 80%).

Margin rates can be customer specific (portfolio/customer level), instrument specific or asset type specific (Sub asset type, asset type).

At present, it will not be possible to specify margin rates depending on the currency of the asset to factor in current volatility. The current
enhancement is to introduce currency volatility margins.

If there is a requirement to specify currency wise margins (for example, a lower margin rate for a JPY account when compared to an USD
account), the same can be set in SUB.ASSET.TYPE or ASSET.TYPE or ASSET.BY.CATEG. It allows specification of different margins for the
same asset class based on the currency of the asset. The currency-wise margins can be used to automatically adjust the lending value depending
on the currency of the asset (for example, lower lending value for currencies with high volatility).

Portfolio Management - User Guide - Release R15.000 - Page 146 of 208

 (Currency Wise Margins)

As against a margin rate of 100% for financial accounts, the margin value of GBP accounts are calculated taking into account margin rate of
90% (CCY.SEC.MGN.RATE).

Similar currency-wise margins can be set for other asset types as well. Let us assume the margin rate specified for asset type ‘EQUITY’ is 75%.
However, for USD stocks, the margin rate specified is 80% and for JPY stocks, the margin rate specified is 70%. An illustration of the impact
of currency-wise margins on portfolio valuation is given below:

Instrument Market Value Margin Rate Margin (Security) Value

USD Stock 10000 (USD) 80% 8000 (USD)

JPY Stock 100000 (JPY) 70% 70000 (JPY)

EUR Stock 10000 (EUR) 75%@ 7500 (EUR)

@ Since no margin is specified for EUR, the default rate will be used.

Individual Customer Margins

SC.CUSTOMER.MARGIN specifies at Portfolio and Customer levels the margin rate used for computing the margin value of a security holding.
The values specified in this file would be the first level of checking for calculation of margin value for the various assets/liabilities held by the
portfolio. If margin is defined for a specified security, sub asset type, asset type or for all securities (by specifying ALL in ASSET.CODE), this
would be used in the order mentioned above for computation of margin and would take precedence over the margin specified at the security,

Portfolio Management - User Guide - Release R15.000 - Page 147 of 208

sub-asset type or asset type level. Depending upon whether a valuation must include/exclude liabilities (based on MARGIN.VALUE in
SC.PARAMETER), either the field LOSS.MARGIN.RATEor MARGIN.RATEis used to calculate the margin value.

The priorities used when obtaining the margin percentage will be as follows:

Instruments File Definition Priority

Security Instruments SC.CUSTOMER.MARGIN table – Portfolio level – Security Master 1

SC.CUSTOMER.MARGIN table – Portfolio level – Sub Asset Type 2

SC.CUSTOMER.MARGIN table – Portfolio level – Asset Type 3

SC.CUSTOMER.MARGIN table – Portfolio level – ALL 4

SC.CUSTOMER.MARGIN table - Customer Number – Security Master 5

SC.CUSTOMER.MARGIN table - Customer Number -Sub Asset Type 6

SC.CUSTOMER.MARGIN table - Customer Number – Asset Type 7

SC.CUSTOMER.MARGIN table - Customer Number - ALL 8

Security Master 9

Sub Asset Type 10

Asset Type 11

Money Market, FX etc. (i.e. SC.CUSTOMER.MARGIN table – Portfolio level – Sub Asset Type 1
not Securities or Fidu-
ciaries)

SC.CUSTOMER.MARGIN table – Portfolio level – Asset Type 2

SC.CUSTOMER.MARGIN table – Portfolio level – ALL 3

SC.CUSTOMER.MARGIN table – Customer Number – Sub Asset Type 4

SC.CUSTOMER.MARGIN table – Customer Number – Asset Type 5

SC.CUSTOMER.MARGIN table – Customer Number – ALL 6

Security Master 7

Sub Asset Type 8

Asset Type 9

Fiduciaries Contract level 1

SC.CUSTOMER.MARGIN table – Customer Number – Sub Asset type 2

SC.CUSTOMER.MARGIN table – Customer Number – Asset type 3

SC.CUSTOMER.MARGIN table – Customer Number – ALL 4

FID parameter level 5

Sub Asset Type 6

Asset type 7

Portfolio Management - User Guide - Release R15.000 - Page 148 of 208

 Note: It is possible to specify within individual portfolios whether or not margining is to be performed. Within the portfolio
(SEC.ACC.MASTER), the field MARGIN.ALLOWED can be set to a value of NONE, in which case no margin calculations will be done
at all. If left blank, then the rules discussed above will be applied.

As explained earlier, valuations and their margined equivalents are stored on the SC.POS.ASSET file. If these assets are to be used as col-
laterals, these values are updated into the COLLATERAL application. Depending upon the setting in COLLATERAL.TYPE either
ESTIMATED or MARGIN values are picked up by the collateral system.

Further margins can be applied to the execution value – using the COLLATERAL.TYPE application.

The collateral type level margins can be defined for a particular customer at the CUSTOMER.COLLATERAL.TYPE application.

For more precise instructions, kindly refer to your T24 User Guide for the COLLATERAL application.

Portfolio Management - User Guide - Release R15.000 - Page 149 of 208

Real Time Valuation and Margin Lending

T24 Securities module contains a comprehensive Portfolio and Investment Management Application, thus enabling account and/or fund man-
agers to provide a full range of services to private clients. A customer portfolio is a portfolio belonging to the customer of the bank that may be
managed by the Bank on customer’s behalf. Once a customer has been entered into T24, one or more portfolios can be defined for that par-
ticular customer.

Once a portfolio has been defined in T24, through use of SEC ACC MASTER application, the value of the portfolio can be updated in dif-
ferent ways:

1. Through an ACCOUNT linked to the portfolio.

2. Through Securities module.
3. Through Non-Securities transactions linked to the portfolio.

T24 automatically revalues all the portfolios in the system every night during the Close of Business (COB) run. The valuation process covers
every asset and liability linked to the portfolio (this includes non-securities related items that are linked to the portfolio). The valuation can
also be performed online for specific portfolio through use of application OL VAL REPS or by invoking standard valuation enquiries (ENQ SC
VAL COST, ENQ SC VAL MARGIN.)

The real-time valuation deals with the mechanism for automatic intra-day valuation of portfolio based on triggers. The triggers are nothing but
events that will have an impact on the valuation of a portfolio. In other words, any transaction or a static change that affects the portfolio value
is a trigger for the valuation process. Based on these triggers, valuation will be performed online for select portfolios.

Buying power summarizes the liquidity of the portfolio. It offers a portfolio wide view of the amount available to invest and in that sense, more
comprehensive than the cash flow checks which is just based on the cash available to invest.

A customer who purchases securities may either pay for the securities in full or borrow part of the amount from the bank. The portion of the
consideration that the customer pays is the customer’s equity. The buying power and eligibility will be calculated on the basis of facility granted
to the customer or the initial margin requirements applicable. While borrowing, as above, has the potential to increase the returns, the losses
can also potentially increase. Falls in the market value of the portfolio can make the portfolio value less than the loan amount borrowed. This
results in what is generally known as the Margin Call.

The margin lending section of this user guide will cover in detail the various methods of computing buying power and tracking the margins. 

ONLINE VALUATION

VALUATION COMPONENTS
The existing valuation process can be divided into three major segments based on the application/nature of transaction that is being processed:

Updating a Portfolio from an ACCOUNT

A Customer portfolio can be linked to accounts on the system. It is necessary when opening a SEC ACC MASTER to define precisely which
accounts belong to the portfolio. When calculating the value of a portfolio, the balance of those accounts will be included in the valuation. 

Updating a Portfolio from the Securities Module

Any securities transaction must include one or more portfolios. The securities transactions could be trade, transfer or corporate action. In case
a securities movement is involved, the SECURITY POSITION will be updated with the details of the movement and the positions will be
included while calculating the value of a portfolio. 

Updating a Portfolio from Other Modules

Other non-SC applications can update a portfolio, subject to their having been linked to the portfolio. In case the other assets and liabilities are
linked to a portfolio, the portfolio valuation process will include these while revaluing the portfolio.

The valuation process builds a file named SC POS ASSET and takes into account the position changes (security holdings, account balance
movements, contract balance changes) and also changes to exchange rates and security prices. The SC POS ASSET holds a snapshot of the
value of the portfolio at the time the valuation was last re-built. Portfolios, by default, are valued in the Reference Currency as specified in the
portfolio. However, it is possible to specify a Valuation Currency that is different from the Reference Currency.

Portfolio Management - User Guide - Release R15.000 - Page 150 of 208

Note: Where Portfolios are shared across companies and trading takes place in a Centralised HUB Company that is different from the Port-
folio's own company, then

l For Securities and Derivatives transactions, Transaction can be input only in company specified in PORT.COMP.ID field of
SEC.ACC.MASTER i.e the HUB Company. Valuation process will also read only from the PORT.COMP.ID.
l For other transactions (non Securities/derivatives), Transactions can be input only in the company specified in OWN.COMP.ID field of
SEC.ACC.MASTER. The Valuation process will also read only from the OWN.COMP.ID.

An example of a portfolio valuation Enquiry screen is shown below. As is typical of the portfolio valuation enquiries, the ENQUIRY is being
broken down by SUB ASSET TYPE with sub totals being displayed for each.

The valuation process, as described above, suffers from a few shortcomings. As the valuation happens automatically only as part of COB, it
doesn’t cater to the requirement for “real” or “near real” time valuation.

There will be several intra-day events like security price movements, security position and account balance movements that could have an
impact on the portfolio valuation. In a volatile market situation, the valuation swings could be huge and unless there is a mechanism to update
valuation automatically, the valuation based on which the decisions are made by the Bank could be drastically different from the valuation at
the time the decision is made.

The valuation carried out, as part of COB or when triggered through an online valuation enquiry, revalues the entire portfolio even if there is a
change only to a specific component of a portfolio. Consider a portfolio that has holdings in fifty Securities and has ten accounts linked. As part
of the valuation process, the entire portfolio will be revalued even though only change that has happened is a price change in one of the secur-
ities in which the portfolio has a holding. This could have an impact on the performance, especially in the case of large portfolios with multiple
positions and accounts linked to it. 

AUTOMATIC INTRA-DAY VALUATION

The shortcomings, detailed above, can be overcome by a mechanism for automatic intra-day revaluation of portfolios. The first step in the near
real-time valuation process will be identifying the triggers for valuation. The triggers are nothing but events that will have an impact on the valu-
ation of a portfolio. In other words, any transaction or a static change that affects the portfolio value is a trigger for the valuation process. The
valuation process should be capable of tracking such events and revalue the portfolio(s) in run time.

T24 Real-time valuation engine caters to this requirement through OV.PARAMETER. If ONLINE.VAL is set to YES, the events that have an
impact on the valuation are captured and the valuation process is initiated automatically for the concerned portfolio(s).

Portfolio Management - User Guide - Release R15.000 - Page 151 of 208

Triggers for Valuation
The overview of the possible events triggers and their effects is shown below:   

Trigger/ Effect Security Security Trans- Cash Trans- Other Trans- DX Haircut
price action action actions Price

Cash Account X X X

Security Value/Margin
Value
X X X

Contract Value X

Pending security Orders

DX Value X

As can be seen above, some of these triggers have an effect only on one element (for example, haircut change affects only the margin value of
that particular security or asset type) whereas others have an impact on multiple elements (a securities purchase will impact both the securities
value and cash account balance). Some of these triggers are transaction based (securities transaction, funds transfer, etc.) and some are static
in nature (haircut change, price change, etc.). There are also events that affect only a single portfolio (securities transaction, funds transfer, etc.)
whereas there are others that could affect multiple portfolios (a price change of a security that is held by many portfolios).

The automatic valuation engine is capable of handling the various types of events as detailed below:

1. Triggers based on static change – Haircut.

2. Transaction triggers – Securities purchase, transfer, Deposit, Funds Transfer, etc.
3. Global triggers – Price change, currency rate change, etc.
4. Triggers that impact more than one element – Securities purchase (for example).

The following table lists out the events, their origin points and their effects: 

Event Single/Multiple Element(s) Origin

Portfolios

1 Securities Purchase/Sale Single Cash/Securities value/- SEC TRADE

margin value

2 Securities Transfer Single Cash/Securities value/- SECURITY TRANSFER

margin value

3 Position Transfer – Multiple Securities Value/- POSITION TRANSFER

across portfolios margin value

4 CA – Cash event Single Cash ENTITLEMENT

5 CA – Stock event Single Securities Value/- ENTITLEMENT

margin value

Portfolio Management - User Guide - Release R15.000 - Page 152 of 208

 6 CA – Combination of Single Cash/Securities value/- ENTITLEMENT
stock and cash margin value

7 Securities Price change Multiple Securities value/margin SECURITY MASTER

value

8 Cash transaction Single/Multiple Cash Valuation FUNDS TRANSFER/TELLER

9 Deposits (new, rollover) Single Cash/contract value MONEY MARKET,   LOANS.AND.DEPOSITS,

ARRANGEMENT.ARCHITECTURE.

10 Loans (new, repayment) Single Cash/contract Value LOANS.AND.DEPOSITS,

ARRANGEMENT.ARCHITECTURE.

11 FX contract Single Cash/FX value FOREIGN.EXCHANGE

12 Customer Mar- Single Margin value SC CUSTOMER MARGIN

gin/facility

This is only an indicative list and not an exhaustive one. All transactions that impact the portfolio value (excluding exchange rate movements
and margin rate changes at instrument or asset type level) will trigger online valuation to ensure the portfolio’s value is near real-time.

The timing of the trigger will be influenced by certain other parameter settings, mainly INCLUDE NAU TXNS. If, for example, this is set to
YES, the trigger will happen as and when the transaction is input. However, if this is set to NO, trigger will happen only when the transactions
are authorized. Besides, any material amendment to transactions (nominal change, etc.) and reversals/deletions will also act as triggers for the
valuation process.

EXC EVENTS field in OV PARAMETER contains details of the events that have to be excluded from the list of triggers. If your organization
does not require real-time valuation to be triggered for certain events, these events can be input in this field. This will ensure that the valuation
is not triggered when these events are encountered. For more details on the values that can be input in this field, please refer to the detailed
Help text of this field.

Additionally, tolerance can be set for price movements. This is to ensure that the valuation is not triggered for minor price changes. Only if the
price change is in excess of the tolerance set, the valuation will be triggered. The tolerance can be set either in terms of Amount (PRC TOL
TYPE with input as “AMOUNT”) or Percentage (PRC TOL TYPE with input as “PERCENTAGE”).If the tolerance is set in terms of Amount,
the valuation will be triggered only if the price change is in excess of the amount in PRC TOL field. If the tolerance is expressed as a percentage,
then the PRC TOL field will hold the percentage and any price change in excess of the percentage specified will trigger valuation.

Portfolio Identifier
It is very important to identify the portfolios that require real-time. The banks might want this facility only for portfolios that are actively
traded and where these intra-day movements will have a considerable impact on the decision making process. If a bank, say, has 100,000 port-
folios of which only 10,000 are actively traded, it will be a huge drag on system performance to perform intra-day valuation for all the port-
folios for an event like price change in a single security.

The portfolios that require real-time valuation is identified either through the OV PARAMETER field PORTFOLIO or the ONLINE VAL field in
SEC ACC MASTER. If PORTFOLIO field in OV PARAMETER is set to ALL, Online valuation will be activated for all the portfolios. If not, the
online valuation for specific portfolios can be activated by setting ONLINE.VAL field in SEC ACC MASTER to YES. It must be noted that
ONLINE VAL in SEC ACC MASTER can be set to YES only if ONLINE VAL is set to YES in OV.PARAMETER.

It will, however, be possible to move portfolios in and out of this category at any stage. If a dormant portfolio becomes active all of a sudden
and there is need to automatically track valuation for this portfolio intra-day, then this feature can be activated for that portfolio. Similarly, this
can also be switched-off at any time for a portfolio that moves from being active to dormant. 

Component level valuation

As stated earlier, the valuation process can be divided into three major segments:

1. Cash Accounts;
2. Security Positions; and
3. Other Module assets/liabilities linked to the portfolio

Portfolio Management - User Guide - Release R15.000 - Page 153 of 208

 As detailed in the shortcomings section above, any valuation carried out as part of COB or triggered from an online valuation enquiry, ends up
revaluing the entire portfolio even though only few of the elements (that make up the portfolio) have changed since the time valuation was last
run. From a performance point of view, it is imperative that the valuation is run only for a particular element (an account or a security or a
deposit) that has undergone a change instead of for all assets and liabilities linked to a portfolio.

It must, however, be mentioned that there are a few instances where more than one element will be impacted resulting in a requirement to
revalue more than one element. For example, a securities purchase will not only impact the Securities Position but will also reduce the account
balance. Two Segments (Accounts and Securities position) will need to be revalued as a result of this transaction.

On the other hand, events like securities price change will impact only one element (a particular security position) and hence, only that element
will require revaluation.

A diagrammatic representation of the real-time valuation process is given below:

The real-time valuation engine will identify the element or elements that has/have undergone a change as a result of a particular transaction and
revalue only that particular component.

A work file will be updated in case a triggering event is encountered for a portfolio that is set for real-time valuation.

The key of the work file for the various segments will be as under:

1. Cash account movements

Key format - <Product Code>*<Account No>
2. Securities Transactions 
l Change in the portfolio holdings
Key format - SC*<Portfolio ID>.<Security No>.<Depository>
l Change in price
Key format - SC*<Security No>
3. Other Module Transactions
<Product Code>*<Transaction reference>

Once the work file is updated, running the ONLINE.VAL.FINAL service will revalue the portfolio affected by the transaction. The valuation
engine will pick the key and perform the revaluation of the component impacted based on the key. The valuation details will be updated in
SEC.ACC.MASTER and SC.POS.ASSET

Portfolio Management - User Guide - Release R15.000 - Page 154 of 208

Portfolio Management - User Guide - Release R15.000 - Page 155 of 208
Buying Power

The concept of buying power summarises the liquidity of the portfolio. It offers a portfolio wide view of the amount available to invest and in
that sense, more comprehensive than, say, the cash flow checks that are currently carried out as part of the order validation process.

The aim of the Buying power calculation as described in this document is to ensure that the additional risk of an order is covered by sufficient
Buying power. To achieve this, the execution of the order is simulated and the effects on the Buying power are computed. Only if the Buying
power is greater than the order amount, the order will be accepted and processed further. This approval process applies to all new orders as
well as to the amendment of pending orders. Pending orders are orders that have been approved already, but are for some reason not yet traded
(e.g. limit orders).

The customer’s cash accounts (including term money), the margin value of the customer’s securities and other assets creates the buying
power.   Pending securities orders and other obligations reduces the buying power.

Setting the BUYING POWER field in OV PARAMETER will ensure that the buying power checks are carried out as part of the order valuation
process.

Before an order is processed, the buying power calculation engine will determine whether there is sufficient buying power to meet the cost of
execution. This is done by simulating the execution amount and comparing it with the buying power calculated. If the Order amount is less
than the Buying power, the system will raise an override to that effect.

Portfolio Management - User Guide - Release R15.000 - Page 156 of 208

The overall principle of buying power check is governed by risk aversion. Therefore, only the pending purchase orders are included in the buying
power calculation and not the potential positive cash flows on account of sell orders.

The following events trigger the buying power calculations:

1. New Orders – Purchase.

2. Amendment of pending orders – Purchase (only for nominal or price change). 

On the other hand, these events will not trigger the buying power checks:

1. Sell Order.
2. Cancellation of pending orders.

Buying power is the potential amount that a client can invest, including cash balances, credit lines (if any) and lending value of securities (hair-
cut). For a given portfolio, the buying power will be calculated as under:

Buying Power = Cash balances + lending value of securities + margin value of other assets – pending orders  – estim-
ation value of other liabilities

By lending value of securities, we mean the margin value of securities arrived at after applying the margin rates. The other assets are the other
module transactions/positions linked to the portfolio and other liabilities are the other module liabilities (loans, for example) of the portfolio.

The buying power will always be calculated in the reference currency of the portfolio. The buying power, so calculated, will be compared against
the order amount (to determine whether sufficient buying power exists.

Let us look at a sample buying power calculation to understand the concept better:

Portfolio A had the following assets

Cash balance = 354,500 USD

Lending value of Securities = 695,000 USD
Deposits = 200,000 USD

There was also a prior pending order for an amount of USD 5,600.

The buying power of Portfolio A considering the above will be USD 1243900 (354500 + 695000 + 200000 – 5600).

An adjustment factor can be applied to the purchasing power so calculated to arrive at the final amount that needs to be compared against the
order amount. This adjustment factor will be at the portfolio level (PP ADJ FACTOR) and will be expressed as a percentage.

For example, if the purchasing power calculated is USD 600,000 and at portfolio level, the overall adjustment factor is set as 90%, the buying
power will be adjusted to USD 540,000. If no customer level adjustment is set, then the buying power will be retained as USD 600,000.

It must be noted that the PP ADJ FACTOR can only be set if BUYING POWER checks are enabled. Besides, the adjustment factor cannot be
set if MARGIN LENDING is set to YES in OV PARAMETER.

In this case, if the order amount is less than the buying power, the order will be processed straight away, else, override for buying power short-
fall will be raised. Override will also be raised if the calculated buying power is negative.

Portfolio Management - User Guide - Release R15.000 - Page 157 of 208

In the above example, we looked at the calculation of buying power where no customer facilities/margins are involved. In the subsequent sec-
tions, we’ll be looking at customer facilities, initial margins and maintenance margins

Portfolio Management - User Guide - Release R15.000 - Page 158 of 208

Margin Lending

Before getting into the calculations of margin lending, let us look at the concept of borrowing against the portfolio.

The maximum amount that can be borrowed against the portfolio is called the Total Loan Value (TLV) of the portfolio and is determined by
applying Loan to Value Ratio (LVR) assigned to each security/group of securities/assets/liabilities in the portfolio. The TLV is also known as
the Margin Value and the LVR is also known by the term Margin Rate.

More details on instrument margins, margins on non-securities assets and liabilities and customer level margins can be obtained from the
PORTFOLIO MANAGEMENT User Guide.

If a portfolio holds a security (Margin rate of 80%) whose market value is USD 5000, the maximum amount that can be borrowed against the
portfolio is USD 4000 (5000 * 80%).

Let us now consider another portfolio that has a position in more than one security:

Market Value Margin Rate Loan or Margin Value

Stock A 10000 70% 7000

Stock B 15000 80% 12000

Bond A 10000 100% 10000

Total 35000 29000

Even though the total market value of the portfolio is USD 35000, the maximum amount the bank will lend against the portfolio is only USD
29000 on account of the LVRs applied to each holding.

If the customer decides to purchase more securities in the above example, the maximum amount that he can purchase will be based on the Mar-
gin rate or LVR of the new security that he intends to purchase.

For example, with a margin value of USD 29000, the maximum amount of security with a LVR of 75% that can be purchased (without the cus-
tomer contributing any cash) is USD 116000, as calculated below:

 Buying Power =Margin Value/(1-LVR) = 29000/ (1-75%) = USD 116000

This amount is significantly higher than the amount you can borrow with the same Loan value as the new security that is purchased increases
the value of the portfolio. In the above example, USD 116000 is the maximum amount that the bank will lend for the stock purchase, or in
other words, the maximum that the customer can purchase without contributing cash by borrowing against his investments.

The portfolio position, after the purchase, will be as under: 

Market Value Margin Rate Loan or Margin Value

Stock A 10000 70% 7000

Stock B 15000 80% 12000

Bond A 10000 100% 10000

Stock C (purchase) 116000 75% 87000

Total 151000 116000

Loan 116000

It must be noted that the loan eligibility or buying power will be calculated on the net margin value of the portfolio (after adjusting for
loans/other liabilities and pending orders). Let us now look at another example of a portfolio with other liabilities and pending orders.

Market Value Margin Rate Loan or Margin Value

Stock A 10000 70% 7000

Portfolio Management - User Guide - Release R15.000 - Page 159 of 208

 Stock B 15000 80% 12000

Bond A 10000 100% 10000

FX/010/120/00005 (3000) **

Stock C (5000) (5000) @@

Total 21000

** Estimation @@ Short Position

There is also an earlier pending order for purchase of 500 shares of Stock D (price – USD 10 and Margin rate of 75%).

The margin value of the portfolio will be adjusted to take into account the expected inflows from the pending order execution (500*10*75%)
and also the order amount outflow (USD 5000).

Adjusted Loan Value = 21000 + 3750 – 5000 = USD 19750

The Buying power of the portfolio (with base amount of USD 19750) for a security with 75% LVR will be USD 79000 (=19750/ (1-75%)).

This, in essence, is the concept of margin lending which is a form of gearing. Setting the MARGIN LENDING field in OV PARAMETER to YES
enables the buying power and loan eligibility calculations as shown above. There is also a field for MARGIN LENDING in SEC ACC MASTER
to identify the margin lending portfolios. The MARGIN LENDING in SEC ACC MASTER can be set only if MARGIN LENDING is set in OV
PARAMETER.

As seen above, there are two distinct uses for the above calculations:

1. To determine how much can borrowed against a portfolio; and

2. To determine additional securities that can be purchased without cash using the existing portfolio.

A customer who purchases securities may either pay for the securities in full or borrow part of the amount from the bank. The portion of the
consideration that the customer pays is the customer’s equity.

While borrowing, as above, has the potential to increase the returns, the losses can also potentially increase. Falls in the market value of the
portfolio can make the portfolio value less than the loan amount borrowed. This will result in bank raising a demand on the investor for depos-
iting additional cash/securities or selling off securities/repaying loan for bringing the portfolio back on track. This results in what is generally
known as the Margin Call.

A margin lending portfolio (with loans availed) is shown below:

Portfolio Management - User Guide - Release R15.000 - Page 160 of 208

Now assume that the portfolio value decreases on account of fall in the market value of securities.

As against the loan amount of USD 696,000 availed, the TLV of the portfolio is now only USD 674,407.50 resulting in a margin call situation.
The customer has to now deposit additional cash or bring in new securities to meet the margin obligation within the time stipulated for clear-
ing the margin call.

Portfolio Management - User Guide - Release R15.000 - Page 161 of 208

A margin call tracker for the above portfolio is shown below:

If the margin call situation is not addressed within the stipulated time, the bank will be constrained to “force sell” some of the customer’s hold-
ings.

In some cases, customers are provided a buffer to enable them to manage the portfolios into a suitable position.

This buffer could either be a percentage of the market value or the margin value of the portfolio. In the above example, let us say, there is a 10%
buffer on the margin value (USD 67,440.75). If this is considered, the combined value (margin + Buffer) will be above the loan value (USD
741,848.25 as against loan value of USD 696,000). Therefore, no margin call will be triggered in this case.

Portfolio Management - User Guide - Release R15.000 - Page 162 of 208

In order to lower the chance of a margin call, caps are imposed on the maximum amount that can be borrowed against a portfolio. If the gearing
level is lower, the margin call obligation will arise only if the prices fall substantially. In order to create a cushion against margin calls, cus-
tomers can choose to gear their portfolio at a lower level. In such cases, they will receive a margin call only if the portfolio value falls sub-
stantially. The gearing levels are controlled by the GEARING field in SEC ACC MASTER. The buying power, in case Gearing is set, will be
calculated as under:

Buying Power =Margin Value*Gearing/(1-(LVR*Gearing))

Where, Gearing is the GEARING set in SEC ACC MASTER(expressed as a percentage) and LVR is the LVR of the new security being purchased.

The ensuing sections will deal with the concepts of customer facility and initial and maintenance margins.

Replace this topic with the Main Page for this product.

Portfolio Management - User Guide - Release R15.000 - Page 163 of 208

Customer Facility

In the previous section, we looked at Margin lending and the situations that could result in a margin call. In this section, we’ll extend this fur-
ther and look at Customer facilities and its impact of buying power calculations.

If a newly opened securities portfolio has no security holdings but only an account (USD) with a balance of USD 500,000 in it, the Buying
power of the portfolio will be USD 500,000. However, this will undergo a change if a customer enjoys a facility with the bank.

In the above example, let us say, the client enjoys a facility of 50% with the bank. The Buying power, with USD 500,000 cash, will be USD
1,000,000 (500000/50%). This means that the customer will be allowed to buy securities worth USD 1,000,000 with a cash of USD
500,000. The loan component, therefore, will be USD 500,000. As the facility granted to the customer is 50%, the Loan to Equity ratio will
be 1:1.

The facility will be at portfolio level and can be set only if MARGIN LENDING is set as YES in SEC ACC MASTER. Besides, the facility should
also be set at OV PARAMETER level before it is set at individual portfolio level. The facility at OV PARAMETER level will act as the cap and
the facility at the portfolio level cannot exceed this.

The calculations begin to get complex when other positions get added to the portfolio. Let us consider an example where there are some secur-
ities held by the portfolio besides the cash balances in the account.

Example:

Market Value Margin Rate Loan or Margin Value

Stock A 31250 80% 25000

Cash 50000 100% 50000

Let us assume that the customer enjoys a 40% facility with the bank. This means that the ratio of bank’s contribution to customer’s con-
tribution will be 1:1.5 (40% from bank, 60% from customer).

The buying power in this case will be determined as under:

Buying Power = ((Cash/(1-facility)) + ((Stock * Facility/(1-facility)))

= ((50000/ (1-40%)) + (25000*40 %/( 1-40%))) = USD 83333.33 + USD 16666.67 = USD 100,000

As the customer has a cash balance of USD 50,000, the loan component will be USD 50,000 (to meet the purchase consideration of USD
100,000).

Portfolio Management - User Guide - Release R15.000 - Page 164 of 208

In this case, it is assumed that there are no other liabilities and the LVR of new security being purchased is 100%.

Assume the price of both the securities now increases by, say, 20%. The portfolio, post the price increase, will be as below:

If there are any existing loans, the first check will be to ensure that the current portfolio value is sufficient to cover the existing loans/other liab-
ilities based on the facility granted to the customer. If not, this will result in a margin call. If this check is cleared, then the buying power needs
to be computed as in the previous example. In this case, the additional buying power will be:

((Loan/(1-Facility) + (Stock* Facility/(1-Facility)))  = ((-50000/60%) + (150000 *40%/60%))

=USD 16,666.67

Portfolio Management - User Guide - Release R15.000 - Page 165 of 208

In the above example, let us assume that the new stock being purchased has a margin rate of only 75% instead of 100% assumed in the pre-
vious example. The buying power will now change as the LVR of new security is less than the previously given LVR. The buying power, con-
sidering the new LVR, will be:

((Loan/(1-(Facility*New Stock LVR)) + (Stock* Facility/(1-(Facility*New stock LVR)))  =

= ((-50000 / (1- (40%*75%)) + (150000 *40 %/( 1 – (40%*75%))) = -71428.57 + 85714.29 =USD 14285.71

Portfolio Management - User Guide - Release R15.000 - Page 166 of 208

In the above examples, only the securities holdings and account balances have been considered. However, it is possible that the portfolio holds
other assets besides the above. The formula for computation of buying power, however, will remain the same even if other assets and liabilities
are included in the portfolio.

In the previous example, assuming that there was a prior pending order for purchase of 1000 shares of Stock C (price - USD 5 and Margin rate
- 75%), the buying power calculated will be adjusted as below:

= PP – (order amount/(1-facility*LVR)) + (order amount * MR@ * facility/(1-facility*LVR))

where, PP is the buying power calculated, MR is the Margin rate on the security of the earlier order and LVR is the margin rate of the security
in the current order

Adjusted Buying power =14285.71 – (5000/(1-40%*75%))+(5000*75%*40%/(1-40%*75%))

If there are fluctuations in the market prices of securities against which a facility has been granted, there is a possibility of the total loan or mar-
gin value of the portfolio going below the loan/facility availed by the customer. This would result in a “margin call”, wherein, the customer will
be forced to bring in additional cash or securities into the portfolio or sell off some of the holdings to make good the deficit.

Portfolio Management - User Guide - Release R15.000 - Page 167 of 208

Portfolio Management - User Guide - Release R15.000 - Page 168 of 208
Short Positions and Other Liabilities

ADJ SHORT POS field in OV PARAMETER governs the handling of short positions and other liabilities (components with negative estim-
ation).

If ADJ.SHORT.POS is set to YES, the securities short position and other liabilities (excluding loans) and components with negative estimation
will be reduced from the margin value of the assets held by the portfolio. The resultant amount (net margin value) will be compared against the
loan amount to determine whether there is a margin call or not. 

If this field is set to NO, then the short position and other liabilities (excluding loans) and components with negative estimation will be added
to the loan amount and this will be compared against the eligible margin value of the assets held by the portfolio.

The following example will help you in understanding this aspect better.

Since ADJ SHORT POS is set as YES, the short position has been reduced from the Margin value. The loan amount will then be compared
against this adjusted margin value to determine whether there is a margin call or not. If it had been set to NO, the short position value (USD
5625) would have been added to the Loan amount.

ADJ SHORT POS will have an impact on the calculations, as above, only if FACILITY or INITIAL MARGIN is set in OV PARAMETER. 

Portfolio Management - User Guide - Release R15.000 - Page 169 of 208

Portfolio Management - User Guide - Release R15.000 - Page 170 of 208
Top-up and Sell-Out Margins

The margin value or the Total Loan Value of a portfolio is dependent on the LVRs or Margin rates specified for the instrument or the asset
group.

Besides the standard LVRs discussed in the earlier sections, it will also be possible to define a Top-up LVR and Sell-out LVR. If these are
defined, the margin value of the portfolio will also be calculated using the Top-Up LV% and Sell-out LV%. The top up and sell out margins can
be specified at all levels where the standard LVRs can be set: MARGIN CONTROL, SUB ASSET TYPE, ASSET TYPE and SC CUSTOMER
MARGIN.

Another example of top-up and sell-out margins but this time at Sub-asset type level.

These are nothing but additional checks governing the type of action to be taken in case of a margin call. The Top Up and Sell out Margins, if
specified, will be higher than the standard margin rates and this provides the customer with a buffer to manage the portfolio into a suitable pos-
ition.

For example, if the margin Value of the portfolio (applying the standard LVR) goes below the loan availed on any given day, there will be no
action taken in case top up and sell out margins have also been specified.

However, on any day, if the Top-Up level is breached (margin value goes below the loan amount with TOP-UP LV %), a top-up margin call will
be made. The customer will be asked to pay in more cash or reduce the cash or transfer in additional eligible securities within a stipulated time-
frame.

Similarly, if Sell-out level is breached, it is a more serious situation demanding immediate action. A sell-out margin call will be made and the
bank may even initiate take action to sell some of the securities in order to cover the deficit.

It must be noted that the buying power calculations will only be based on standard LVRs. The Top-up and sell-out LVRs will only be used to
determine the action required in respect of margin calls.

Since this is also another form of buffer, BUFFER in OV PARAMETER will not be set if these margins have been specified and vice versa

Portfolio Management - User Guide - Release R15.000 - Page 171 of 208

Portfolio Management - User Guide - Release R15.000 - Page 172 of 208
Diversified Margins

Margin value (or Security Value) denotes the maximum amount that can be borrowed against the Portfolio.

Diversification is a feature that rewards customers who diversify their portfolios. Diversification can be based on any number of criteria (num-
ber of stocks held in the portfolio, holding in a particular stock or holding in a particular group of stocks). The diversified feature allows cus-
tomers to access to a greater number of securities which they can invest in and receive an LVR (or Margin Rate) for, and higher LVRs on most
securities. The benefit to the customer is that this increases their security value (and in turn their funds available to invest) and choose
between using this as a cushion between them and a margin call or increase the amount they invest.

Let us consider a portfolio that has holdings in different securities

Even though the total market value of the portfolio is USD 151000, the maximum amount the bank will lend against the portfolio is only USD
116000 on account of the LVRs applied to each holding.

In the previous example, if the client is eligible for diversified margins, the diversified margin value of the portfolio will be as under:

As against the standard margin value of USD 116000, the client will now be eligible for a borrowing of USD 130100 based on the diver-
sification margins applied. If the client now decides to purchase more securities, he will have more to invest. Besides, because of the higher mar-
gin rates, he will also have more cushion when compared to standard portfolios as regards margin call is concerned. The higher LVRs increase
how far the client’s portfolio would need to fall before he receives a margin call.

The diversified margins can be specified in SC.CUSTOMER.MARGIN, MARGIN.CONTROL, SUB.ASSET.TYPE, ASSET.TYPE and
ASSET.BY.CATEG. by populating the field, ADJ.MARGIN, to specify the diversified margin rate. The diversified margin rate, if specified, will
always be more than or equal to standard margin rates.

There will be certain stocks with diversified LVR but no standard LVR, meaning they will be eligible for margin lending (or borrowing) only if
they are part of a diversified portfolio. These stocks are called ‘Restricted’ stocks and will be eligible for no margins in the normal course. The
restricted stocks are identified based on the settings in the RESTRICTED field in SECURITY.MASTER. If this field is set to ‘YES’, then the
stock is considered a restricted stock.

Diversification, as a feature, has to be ‘activated’. By simply complying with the diversification criteria, portfolio will not be eligible for diver-
sified margins. If a portfolio is not eligible for diversified margins, the security value of the portfolio will be determined by applying the standard

Portfolio Management - User Guide - Release R15.000 - Page 173 of 208

margin rates even though the portfolio complies with all the requirements of a diversified portfolio. A portfolio is considered eligible for Diver-
sification if the field DIVERSIFICATION is set to Y in SEC ACC MASTER.

A portfolio can be identified as ‘Diversified’ based on its compliance with:

l Number count rule

l Holdings rule

Number Count Rule

If the number of securities held in the portfolio is equal to or more than the number of securities required for meeting the diversification cri-
teria, then all the holdings (for which diversified margin has been specified) will be eligible for diversified margins while determining the security
or margin value of the portfolio. The number of stocks required for considering the portfolio as diversified will be specified in STOCK.HELD
field of OV.PARAMETER.

The number of securities could mean:

l All the holdings of the portfolio (stocks, bonds, managed funds);

l All the eligible securities excluding the restricted securities; or
l All eligible securities including those in the restricted list.

The field STOCK.COUNT.BASIS in OV.PARAMETER controls the securities that will be considered for determining the compliance with the
number of stocks rule.

Holdings Rule
The diversification can also be determined based on the holding levels of a particular stock in a portfolio. For example, the higher diversified
LVRs can be applied to all the stocks in the portfolio if no stock exceeds 25% of the total value of the diversified portfolio. If any stock exceeds
25%, then three options are available:

l Treat the entire portfolio as a standard portfolio and apply standard LVRs on all the holdings;
l Treat the entire holding in the stock as standard and apply standard LVR on that particular holding;
l Treat the excess holding (in excess of the percentage specified) as standard and apply standard LVR on the excess and diversified LVR
on the rest. In this case, there will be a requirement to apply two LVRs on the same holding (currently not supported) and report them
independently

The holding cap is set in the HOLDING.PERCENT field of OV.PARAMETER. In the HOLDING.ACTION field (PORTFOLIO, POSITION and
EXCESS are the allowed values), the options available, in case the holding exceeds the cap, are specified.

If both these rules are specified, the system will check the number of stocks held first. Once this is complied with, the system will check the
holding caps and apply the diversified margin only when both these conditions are met.

Issuer Diversification and effect on Portfolio Valuation

Note: If Issuer Diversification is set, other Diversifications explained above will not work

Margin value of Portfolios that are over exposed to a Single or few Issuers, are suitably reduced to offset any potential credit risk.

An issuer can be set for every Security. The issuer need not necessarily be a “Customer” in T24.

Rules are applied to check, if a Portfolio is sufficiently diversified. If exposure to a single Issuer or few issuers is very high, then the Margin
value is suitably reduced to manage the potential risk if any.

SC.ISSUER

Issuers can be created using SC.ISSUER application for Issuers who are not opened as "Customers" in T24

Portfolio Management - User Guide - Release R15.000 - Page 174 of 208

 SC Issuer record

Linking Issuers to SECURITY.MASTER

SECURITY.MASTER

SHARES record

An Issuer can be set for every Security. The field OV.ISSUER accepts values C-XXXX; where XXXX is a valid CUSTOMER record or I-
XXXX; where XXXX is a valid SC.ISSUER record.

Portfolio Management - User Guide - Release R15.000 - Page 175 of 208

 Note: Issuer Diversification checks applies only based on the Issuer set in this field. Issuer set in field ISSUER is not used for this pur-
pose.

ISSUER.EXCEPT: If the security is to be excluded from Issuer Diversification check, then this field has to be manually specified.

OV.PARAMETER

OV.PARAMETER record

ISSUER.DIVERFN - To check if issuer diversification must be performed based on Margin Value check, Net equity check (or) both.

ISSUER.PERCENTAGE - Maximum allowed percentage for issuers (above which diversification is applied).

APPROVED.ISSUER - List of approved Issuers.

EXCEPT.SUB.ASSET - List of excepted sub asset types.

NO.OF.ISSUER - Margin value check is performed, if the number of issuer for a portfolio exceeds the setup here.

ISSUER.DIVERFN.RTN – Local routine for performing issuer diversification must be specified.

Diversification Checks
Three types of Margin Value calculations are possible based on Issuer Diversification, depending on the values in
DIVERSIFICATION.TYPE field in OV.PARAMETER

1. Margin: If set to MARGIN, then the Margin Value of a portfolio excluding cash positions is calculated. Then the percentage specified
in parameter is applied on it to calculate the maximum value allowed per issuer (Value A).

All instruments per issuer (single group) and instruments without issuer (unique issuer per instrument) is grouped and Margin Value
per issuer is calculated (Value B).

Both the values is compared and if Value A > B, Value A is considered as the Margin Value.

If A<B, then the Margin Value of individual instruments is adjusted using the formula "Individual instrument value * Maximum allowed
per issuer/Total issuer amount". The total Margin Value is then updated in SEC.ACC.MASTER

Note: All the instruments with excepted field set to 'Yes', is not included for the above calculation. All instruments with or
without issuer is included for diversification calculation.

Portfolio Management - User Guide - Release R15.000 - Page 176 of 208

2. Net Equity Check : If set as EQUITY, net equity value of a portfolio excluding liabilities and exposures is calculated and percentage
specified in parameter is applied on it to calculate the amount that is maximum value allowed per issuer (Value A).

Market Value per issuer is calculated by adding market values of all the instruments pertaining to the same issuer (Value B).

If Market Value (B) < Net Equity Value (A), then the market value is considered as Margin Value. If B > A, then the Margin Value for
each instrument is calculated using the formula "Margin value * Net equity/Total market value of issuer".

Note: Exceptions stated above will be applicable for Net Equity Check also.

3. Both: If BOTH option is set, then lesser Margin Values between Margin and Net Equity Check is the final Margin Value.

Portfolio Management - User Guide - Release R15.000 - Page 177 of 208

Segregation of Income

Certain portfolios can keep the income and capital segregated. The interest accrued through a purchase or sale on bond positions and changes
are designated to a separate income account.

For those portfolios that have elected to segregate income, the accrued interest and charges are posted to a separate income account and only
the gross consideration is posted to the capital account.

Functionality Process Flow

On the SEC.ACC.MASTER application, four new fields have been introduced in order to post the accrued interest and/or charges to the income
account, instead of the capital account.

The newly added fields are as follows:

1. SEGREG.INCOME - If the check box is selected, the accrued interest (bought or sold) is segregated and posted to income account
2. SEGREG.CHARGE - If the check box is selected, the charges and the income are segregated and posted to Income account.

Note:

l Among the above two fields, at least one must be selected or both can be selected.
l If both the fields are selected, then both the Accrued Interest and Charges are posted to the Income Account.
However, these two postings are considered as two separate accounting entries. The two entries have different trans-
action codes and need to be set in the parameter file.
3. INC.ACCOUNT.NO – The account number to which the income and charges are posted, in case segregation is required. If
SEGREG.INCOME or SEGREG.CHARGEis selected, then at least one income account have to be specified in this field.

Note:

l The Income Account can be an account which is not part of the Portfolio's accounts i.e an account which is not
attached in ACCOUNT.NOS field in SEC.ACC.MASTER. If this is required, then the field EXCL.INC.VALUATION in
SC.PARAMETER needs to be set as YES.
l Capital account attached to a Portfolio can be set as the Income Account of another Portfolio
l However, an Income account linked to one portfolio cannot be linked as Income account in another portfolio.
l While running Valuations for a Portfolio, if the Income account does not belong to that portfolio, it will be excluded
from the Valuation.
4. INC.ACCOUNT.CCY – Field associated with INC.ACCOUNT.NO above specifies the currency of the income account.
INC.ACCOUNT.NO and INC.ACCOUNT.CCY are associated multi-value fields in order to facilitate specification of default
income accounts by currency. The income account specified here cannot be the same as capital account linked to the portfolio (or any
other portfolio). An income account used in one portfolio cannot be used in another portfolio

Portfolio Management - User Guide - Release R15.000 - Page 178 of 208

Portfolio Management - User Guide - Release R15.000 - Page 179 of 208
Security Margin Ratio

Security Margin Ratio can be used as a credit monitoring tool for portfolios which are pledged as collateral for credit facilities availed. This ratio
is compared with top-up and sell-out ratios defined at global or portfolio level and helps the bank to check if their exposure is sufficiently
covered.

Sec Margin Ratio is calculated for Individual Portfolios and for a Group of Portfolios based on Second market value, margin value and liab-
ilities.

Second Market Value is the Market value of all the Assets. However, assets with Zero Margin value is not included.

Liabilities is the total of all the Negative positions including Loans, overdrawn accounts etc.

Lombard Value is the Margin Value of the Portfolio after all Haircuts. This is the total of the values in the MARGIN.VALUE field in
SC.POS.ASSET or SC.GROUP.POS.ASSET

Security Margin Ratio is calculated as (Second Market Value - Liabilities) / (Second Market Value – LombardValue).

Where a Customer has more than one Portfolio or where the Portfolio of another Customer is pledged to cover the liabilities of a Master Port-
folio, the Portfolios can be grouped together for Margin Call follow-up.

Using Portfolio Grouping, margin value of child portfolio is linked and used by master portfolio for any credit facility provided to the Master
Portfolio.

The linking is done using the application SC.VALUATION.GROUP

SC.VALUATION.GROUP - The ID of this record is the Master Portfolio.

Grouping Portfolios for Valuation

l CHILD.PORTFOLIO – Holds child portfolios

l LINK.TYPE – Values can be FIXED, VARIABLE, NETTING.

For Fixed link type, the fixed amount is taken as margin value irrespective of the portfolio’s value.

Portfolio Management - User Guide - Release R15.000 - Page 180 of 208

 Only pledge amount can be defined.

For Variable link type, either the pledge amount or percentage can be defined. If pledge percentage is
defined then the percentage is applied on the margin value. If pledge amount is defined then either
the portfolio's margin value or pledge amount whichever is lower is considered as margin value.

For Netting Link type, the system considers the transactions of the Child and the Master Portfolio
that can be netted and arrive at the Margin Value for the Master Portfolio. And for Derivatives, addi-
tional setup are done in DX.PARAMETER.

l PLEDGE.PCT – This percentage is applied on MARGIN.VALUE field of SEC.ACC.MASTER.

l PLEDGE.AMT – Pledge amount in reference currency of child portfolio that is considered if it is less than the
MARGIN.VALUE in SEC.ACC.MASTER.
l GLOBAL.LIMIT -Holds the global limit
l STATUS – Needs to be set as INACTIVE to exclude Group for Valuation
l RUN.VALUATION – To be set as YES for online valuation of master portfolio.
l CHILD.VALUATION – Either ALL or list of portfolios that can be specified for which child valuation has to be per-
formed.
l LAST.VALUATION.RUN – Date and time of online valuation run.

l MASTER.PORTFOLIO - Lists the master portfolios to which this group portfolio record is pledged as the child
portfolio.

Further, the Global level Top Up and Sell Out margin rates can be set in OV.PARAMETER. These are only for information pur-
pose and can be compared with the Security Margin Ratio to decide on Margin Calls.

OV.PARAMETER

Online Valuation Parameter

Portfolio Management - User Guide - Release R15.000 - Page 181 of 208

 l TOP.UP.MGN.RATE – Holds margin rate for top-up
l SELL.OUT.MGN.RATE – Holds margin rate for sell out.
l PRICING.DAYS – Holds cut of day of calculating pricing date. Any position where the last price is available beyond these days, is
excluded from the Second Market Value
l GLOBAL.LIMIT – Specifies the global limit (that is; in the format 10000.xxx)

SC.POS.ASSET

These fields holds SECOND.MRKT.VALUE, INIT.MGN.VALUE, TOP.UP.MARGIN, SELL.OUT.MARGIN, MV.MARGIN.AMT and

EQ.MARGIN.AMT and their respective values.

SC.POS.ASSET

Here INIT.MGN.VALUE holds the Original Margin Value calculated normally.

Portfolio Management - User Guide - Release R15.000 - Page 182 of 208

The MARGIN.VALUE field holds the Margin Value after applying hair cuts based on Issuer Diversification.

SEC.ACC.MASTER

l MASTER.PORTFOLIO – Holds parent portfolio reference.

l SECOND.MRKT.VALUE – Holds second market value.
l INIT.MGN.VALUE – Holds initial margin value (that is; the margin value prior to adjustment for diversification).
l SEC.MARGIN.RATIO – Holds computed sec margin ratio.
l GRP.ESTIMATION – Holds total group estimation.
l GRP.SEC.MKT.VALUE – Holds second market value for group.
l GRP.MARGIN.VALUE – Holds margin value of group.
l GRP.INIT.MGN.VALUE – Holds initial margin value of group.
l GRP.LIABILITY – Holds liability of group.
l GRP.SEC.MARGIN.RATIO – Holds sec margin ratio for group.
l TOP.UP.MGN.RATE – Holds margin rate of top-up.
l SELL.OUT.MGN.RATE – Holds margin rate of sell out.
l GLOBAL.LIMIT – Specifies the global limit.

SC.GROUP.POS.ASSET

SC.GROUP.POS.ASSET

This file gets updated for Portfolio Groups and fields are similar to SC.POS.ASSET

INDEX field – Is updated only if application is SC. Value is SECURITY.NO*DEPOSITORY.

Valuation Update

For a single Portfolio, Margin value, Second Margin value, Security Margin ratio etc would be updated by the usual Valuation process that is; by
running SC.VAL.COST etc.

Portfolio Management - User Guide - Release R15.000 - Page 183 of 208

For a Group of Portfolios, Margin value, Second Margin value, Liabilities, Security Margin ratio etc would be updated during COB. To update
these online, the services SC.GROUP.VALUATION and SC.GROUP.VALUATION.MARGIN needs to be run. These services updates the
SC.GROUP.POS.ASSET files and the SEC.ACC.MASTER of the Master Portfolio.

User can define negative loss margin rates to apply mark-up rate on liabilities in SC.CUSTOMER.MARGIN, SUB.ASSET.TYPE or
ASSET.TYPE.

The final values are viewed by running the enquiries, to view Portfolio Lombard Value and Group Lombard Value.

Valuation Update screens

Portfolio Management - User Guide - Release R15.000 - Page 184 of 208

Delivery Overview

Delivery address for specific Portfolio

Delivery address is maintained for specific portfolio.

In DE.PRODUCT application, new records are created, for specific portfolio, i.e. DE.PRODUCT specific to SEC.ACC.MASTER records.

Delivery address is linked to specific portfolios , by mapping DE.PRODUCT with the Advice Index field of the respective
SEC.ACC.MASTER(Portfolio)

SEC.ACC.MASTER

Portfolio Management - User Guide - Release R15.000 - Page 185 of 208

 DE.PRODUCT_SCP1

For more information on Delivery Message refer Product table (DE.PRODUCT)

Portfolio Management - User Guide - Release R15.000 - Page 186 of 208

Enquiries and Reports Overview

Portfolio Valuation
T24 automatically revalues all portfolios on the system every night during the Close of Business (COB) run. The revaluation programs build a
file named SC.POS.ASSET. This file is updated with details of every current asset and liability linked to the portfolio (this includes non-secur-
ity related items that are linked to the securities application through ASSET.TYPE as discussed earlier in your User Guide. The COB also
updates this file with details of changed currency rates and security prices. The SC.POS.ASSET file can also be rebuilt online by the application
OL.VAL.REPS and any ENQUIRY that contains the program E.OL.VAL as its BUILD.ROUTINE.

The SC.POS.ASSET file is used to hold a ‘snapshot’ of the value of a portfolio at the time it was last re-built by either online or COB revalu-
ation using the latest prices and currency rates. The key to this file is Portfolio Number (SEC.ACC.MASTER), SUB.ASSET.TYPE and
ASSET.TYPE separated by full stops. However the SC.POS.ASSET file is a live file and therefore cannot be input to or amended by users.
Instead, any user needing details of the value of a portfolio should either run one of the many Portfolio Valuation Enquiries listed below or the
application, OL.VAL.REPS, which is used to produce hardcopy online valuation reports.

Portfolios are valued in the reference currency as specified during the setting- up stage of a portfolio. This is contained in the
REFERENCE.CURRENCY field of the SEC.ACC.MASTER record that defines the portfolio. All portfolio profit and loss is calculated using val-
ues in this currency. However, it is possible to specify a valuation currency that may differ from the REFERENCE.CURRENCY specified cur-
rency. Amending the currency specified in the VALUATION.CURRENCY field of the SEC.ACC.MASTER and invoking the enquiry once again
will produce the enquiry in the specified currency.  By default, the contents of this field will be the same as the REFERENCE.CURRENCY field
but the difference is this field may be changed as and when required, whereas the REFERENCE.CURRENCY field contents may not be changed
once the SEC.ACC.MASTER has been set-up and authorised. It is important to note that changing the VALUATION.CURRENCY shows the
effect of the valuation in that currency, whether by printer or enquiry versions but will not have any impact upon the SC.POS.ASSET file
described earlier.

Portfolio Management - User Guide - Release R15.000 - Page 187 of 208

Portfolio Valuation Enquiries

When running on-line Valuations in the Securities module using the Enquiry SC.VAL.COST use is made of the SC.PARAMETER flag
“INCLUDE.NAU.TXNS”.

The resultant output to the SC.POS.ASSET file is used by other Enquiries such as SC.VAL.MARKET, SC.VAL.MARGIN, etc.

The field, INCLUDE.NAU.TXNS has the following options:

YES — Unauthorised transactions will be included in the valuation

NO — Unauthorised transactions will not be included in the valuation

AUTH — Unauthorised transactions will not be included in the valuation. Changes to authorised transactions will be excluded and the valu-
ation will show the previously authorised values. This will apply to unauthorised amendments and unauthorised reversals. This will also affect
any Cost fields relevant to the Valuation in progress.

SC.PARAMETER showing the INCLUDE.NAU.TXNS field set to “AUTH”.

This setting is applied to the applications SEC.TRADE and SECURITY.TRANSFER only.

Under the setting of NO, for example, if a Forward Dated SEC.TRADE is input and authorised, and followed by an on-line valuation then the
reported valuation is fine.

Portfolio Management - User Guide - Release R15.000 - Page 188 of 208

However, if the same Trade is then amended and left unauthorised the Trade is not taken into account at all in a subsequent Valuation. The
Cash Account remains unaffected by this.

The valuation process parameter value is set to “NO” or “AUTH” then the process will be followed to “remove” the values of the unauthorised
transaction from the valuation. However if the setting is “AUTH” the previous live transaction will be used to reconstruct the details required
by the program  to rebuild the position prior to amendment and these values will be used to update the valuation.

It should be noted that there will be a performance drag when using this setting as the previously authorised transaction must be found and
details reconstructed from it.

A number of standard Portfolio Valuation ENQUIRY records are supplied with T24 , details of some of these are shown in the table below:

Enquiry Name Trade/Value Dated Description

SC.ASSET.VAL.CASH Value Enquiry showing estimation and estimated gross income for portfolio.
Can be used to show end of month historical positions.
SC.ASSET.VAL.COST Value Enquiry showing position, description of position, estimation, cost and
market prices.
SC.ASSET.VAL.MARKET Value Enquiry showing position, description of position, estimation and mar-
ket price.
SC.ASSET.VAL.MARGIN Value Enquiry showing position, description of position, estimation and mar-
gin value of portfolio.
SC.VAL.CASH Trade Enquiry showing estimation and estimated income for portfolio. Can be
used to show end of month historical positions.
SC.VAL.COST Trade Enquiry showing position, description of position, estimation, cost and
market prices.
SC.VAL.MARGIN Trade Enquiry showing position, description of position, estimation and mar-
gin value of portfolio.
SC.VAL.MARKET Trade Enquiry showing position, description of position, estimation and mar-
ket price.

Table 1 – PORTFOLIO VALUATION ENQUIRIES

An example of a portfolio valuation ENQUIRY screen is shown below. The example in question is SC.VAL.COST for the portfolio shown 950-1
whose SEC.ACC.MASTERrecord is shown in the screenshot above. As is typical of the Portfolio Valuation Enquiries, theENQUIRY is broken
down by SUB.ASSET.TYPEwith sub totals being displayed for each.

ENQUIRY - SC.VAL.COST FX Contracts

Portfolio Management - User Guide - Release R15.000 - Page 189 of 208

As can be seen from the ENQUIRY, any FOREX contracts linked to a portfolio on T24 are split into two (bought side and sold side) and the
two sides displayed separately. Also the value to the portfolio of the relevant side of the contract will only include the profit and loss due to dif-
ferences in the exchange rate between the contract and the current system exchange rates (or system forward rates if the contract is forward).

There is no value against the GBP side of the contract as the reference currency of the portfolio is GBP and so there will always be an exchange
rate of 1 between the reference currency of the portfolio and the currency on this side of the contract. Against the USD side of the contract a
loss is shown, as the contract is to buy USD at a rate of 1.885 whereas the current forward rate for GBP-USD is 1.873. Again the exchange rate
against the portfolio reference currency is used. It is the difference between contracted and current forward rates that provides the resultant
valuation amount.

The valuation enquiries will also include, where relevant to a particular transaction, the amount of accrued interest to date, as can be seen in
the next extract.

ENQUIRY - SC.VAL.COST Accrued Interest

Accrued interest is shown against the LD.LOANS.AND.DEPOSITStransactions that are linked to the portfolio. MM.MONEY.MARKET and
other transactions against which accruals have been made will also be included in the ENQUIRY.

In the case of interest bearing bond positions, the T24 enquiries will illustrate the amount of interest due as of the enquired date but, of
course, does not accrue customer interest.

The next screen shows the summary details:

ENQUIRY - SC.VAL.COST Summary detai

Portfolio Management - User Guide - Release R15.000 - Page 190 of 208

Additional Valuation Information

Suppression of Unsettled Trades from Valuations

Your T24 will, when performing valuations, include instantly any receipts or withdrawals into a customer’s SECURITY.POSITION whether or
not the underlying source transaction has been settled or not.

If your particular environment demands that unsettled trades be excluded from customer valuations and, by default, the SECURITY.POSITION
and in particular the field CLOSING.BAL.NO.NOM on the same file, then the following section of your User Guide will provide you with instruc-
tions as to how to set this up.

First, your SECURITY.PARAMETER file contains two fields, SECT.PEND and SC.TRANS.NAME.

The former field, SECT.PEND, should be set to “YES” should the requirement be to exclude unsettled trades from customer valuations. The lat-
ter field, SC.TRANS.NAME, is used to identify the transaction types (from the SC.TRANS.NAME file) you wish to be excluded from any valu-
ations if the source transaction is unsettled. The specifying of transaction types provides you with the opportunity to include and exclude
certain types of unsettled transactions should there be some kind of requirement to do so.

As suggested by the file name, SC.TRANS.NAME, records are only names which, in turn, are linked to SC.TRANS.TYPE records where the
rules are stored as to whether a SC.TRANS.NAME is a receipt or a delivery of security. It is possible, therefore, to set-up multiple
SC.TRANS.NAME records that link to one SC.TRANS.TYPE, thereby enabling the differentiation by name for different purposes such as, in
this case, whether or not to include in customer revaluations.

The next extract shows how the SC.PARAMETER file may look for the two fields, SECT.PEND and SC.TRANS.NAME.

SC.PARAMETER - Setting-up inhibiting unsettled trades from valuations

As can be seen, the SC.TRANS.NAME field is multi-value and therefore you may specify more than the one shown above.

The example SC.TRANS.NAME above is allied to the SC.TRANS.TYPE “FNP” as is confirmed by the next extract.

Portfolio Management - User Guide - Release R15.000 - Page 191 of 208

 SC.TRANS.TYPE - Example record

To illustrate the process more fully, we shall input a SECURITY.TRANSFER using the SECURITY.DR.CODE shown in the above extract which
has been recorded on the SC.PARAMETER.

SECURITY.TRANSFER - Inhibiting unsettled trades from valuations

The TRANSACTION.TYPE field confirms the SC.TRANS.NAME used to record the security receipt on behalf of the customer 950 for delivery
into portfolio (SEC.ACC.MASTER ) 950-1.

The fact that the SC.TRANS.NAME has been defined on the SC.PARAMETER in the field combination, SEC.PEND and SC.TRANS.NAME will
force the usage of SC.SETTLEMENT . Unless you are inputting through a version that sets the SEC.HOLD.SETTLE field in
SECURITY.TRANSFER  to “YES”.

Portfolio Management - User Guide - Release R15.000 - Page 192 of 208

 SECURITY.TRANSFER - Without SC.SETTLEMENT request

As illustrated above, T24 will error in such a case. To affect input, therefore, it will be necessary to set the SEC.HOLD.SETTLE field to “YES”.

SC.SETTLEMENT - Confirming customer-side unsettled

As can be seen in the above extract, the field CU.NOM.OUTSTANDING confirms the customer transfer of 1,295 shares remains unsettled. The
field, TRANS.CODE, also confirms the SC.TRANS.NAME used (FNI in this case) on the source SECURITY.TRANSFER.

The effect of utilising this process of inhibiting unsettled trades can be seen in several obvious locations. For example, within the main pos-
itions file, SECURITY.POSITION for the SECURITY and CUSTOMER.

Portfolio Management - User Guide - Release R15.000 - Page 193 of 208

 SECURITY.POSITION - Customer position in unsettled security

The position above, for security 003621-000 in portfolio 930-1 shows a CLOSING.BAL.NO.NOM of zero despite the fact that the securities
have been added through an authorised SECURITY.TRANSFER.

The position has actually been updated in the field FREE.NOM.PEND as seen in the next extract.

SECURITY.POSITION - Unsettled transaction nominals/amounts

As discussed earlier, the object here is to prevent unsettled transactions from appearing in the customer valuations. This can be checked now
by running a valuation for the portfolio 930-1.

Portfolio Management - User Guide - Release R15.000 - Page 194 of 208

 ENQ : SC.VAL.MARKET - Customer valuation (first page)

The above, first extract, shows the customer portfolio contents. All that can be seen on view is the current account connected with the port-
folio (SEC.ACC.MASTER) illustrating the current balance.

The next extract shows the valuations summary for the same portfolio.

ENQ : SC.VAL.MARKET - Summary screen

As can be seen, there is no reference to the unsettled security that had been transferred into the account. However, once settled, the security
will be included in the revaluation.

Now, we will settle the transfer to see the effect of this.

First locate the relevant SC.SETTLEMENT record appertaining to the SECURITY.TRANSFER.

SC.SETTLEMENT - Customer security receipt to settle

The above extract shows the first portion of the SC.SETTLEMENT. Now complete the customer settlement details – as shown in the next
extract.

Portfolio Management - User Guide - Release R15.000 - Page 195 of 208

 SC.SETTLEMENT - Customer settlement

Enter the settlement amount and the value date, input and authorise the transaction – we will use the system date in this case simply for illus-
trative purposes.

Now, that done, we can run the valuation enquiry once again to check whether the security settled appears on view.

ENQUIRY : SC.VAL.MARKET - After settling the security transfer in

We can now see the effect of confirming the receipt of the unsettled security – 003621-000 in the customer portfolio above.

Portfolio Management - User Guide - Release R15.000 - Page 196 of 208

On a more technical note, the valuations enquiries utilise the file SC.POS.ASSET file which is only updated upon settlement of those trans-
actions matching the specified SECT.PEND / SC.TRANS.NAME field settings in the SC.PARAMETER file as described earlier in this section of
your User Guide.

It is worth remembering therefore that unsettled transactions that are to be withheld from valuations because the transaction type has been
specified on the SC.PARAMETER are recorded in total on the underlying SECURITY.POSITION in the field FREE.NOM.PEND. This is illus-
trated in the extract in this section.

SECURITY.POSITION - Unsettled security nominal / amount

NOTE: Valuations available within your T24 system may refer to on-line enquiries such as SC.VAL.MARKET as well as valuation reports,
both on- line and as built during the COB (end- of- day) phase. All valuations will allow for unsettled transactions provided the
SC.TRANS.NAME is specified SECT.PEND / SC.TRANS.NAME field settings in the SC.PARAMETER file.

It is worth mentioning that if, for any reason, the securities were settled in error and therefore the relevant SC.SETTLEMENT is subsequently
updated to reverse the earlier settlement, your T24  system will recognise this and any further valuations will again exclude the nominal /
amount of the security.

We can see the effect of this in the next series of extracts.

First step is to “unsettle” the SC.SETTLEMENT used in the above example.

SC.SETTLEMENT - Shows the customer fully settled

Now reverse the settlement amount –

Portfolio Management - User Guide - Release R15.000 - Page 197 of 208

 SC.SETTLEMENT - "Unsettle" the earlier settled amount

Authorise the above record and perform a further revaluation enquiry upon the customer portfolio.

ENQ : SC.VAL.MARKET - After performing unsettlement

As can be seen above, the security details are once again omitted from the portfolio holdings. Note that this occurs whether the underlying
SC.SETTLEMENT is authorised or not. Simply entering the unsettlement amount will have an immediate impact upon any subsequent valu-
ation. This is because the SECURITY.POSITION field FREE.NOM.PEND is updated immediately the change is made to SC.SETTLEMENT.

Portfolio Management - User Guide - Release R15.000 - Page 198 of 208

 SECURITY.POSITION - After performing "Unsettlement"

Finally, it is also worth mentioning that since partial settlements are permitted within the SC.SETTLEMENT application, any amount settled
will immediately become eligible for reporting within a valuation. The same applies should a partial-unsettlement take place.

This is evidenced by reference to the following extract –

SC.SETTLEMENT - Partial unsettlement

In the above example, 1,295 stock was settled followed by an unsettlement of 740 stock.

SECURITY.POSITION - Extract 1 - Settled position in security

And the unsettled amount of stock is recorded in the FRE.NOM.PEND field.

Portfolio Management - User Guide - Release R15.000 - Page 199 of 208

 SECURITY.POSITION - Effect of the "unsettled" security

The original settlement amounted to 1,295 stock less 740 unsettlement leaving a settled position of 555.

Now, once again, an on-line valuation for the portfolio.

ENQ : SC.VAL.MARKET - Effect of unsettlement

As can be seen, the valuation only includes the amount of security actually settled.

Portfolio Management - User Guide - Release R15.000 - Page 200 of 208

Portfolio Valuation Reports

In addition to screen enquiries, a number of specially tailored portfolio valuation reports have been written to run within T24. The portfolio
valuation report that is used by an individual system is specified in the VALUATION.SUBR field of SC.PARAMETER. These reports are pro-
duced by jbc programs and if a user wants one tailored for their system they can be written by their local Temenos Regional Development
Department. The default report is called SC.ASSET.VAL.REPS but other examples such as SC.ASSET.VAL.REPORTS.SIM or
SC.ASSET.VAL.REPORTS.CAMBIO can be used.

OL.VAL.REPS - On-line valuation report

The above extract shows how to request a valuation report during the on-line phase. First, it is necessary to create (input) a request keyed on
the ACCOUNT.OFFICER field of the PORTFOLIO (SEC.ACC.MASTER) record for which the valuation is required.

Always indicate “Y” in the ONLINE.VAL field to ensure that all the relevant files are as up-to-date as possible. Further, you should specify,
numerically, the current month (such as 11 above to indicate November). You may also request historic valuation data – see next section.

It can be seen that the request is on behalf of portfolio “888-1” and the valuation is for the current. Once the request has been input, it is then
necessary to  “V”erify the same record to build the report.

Portfolio Management - User Guide - Release R15.000 - Page 201 of 208

 OL.VAL.REP - Verify to build the report

On line valuations are created by using the application OL.VAL.REPS, this is initiated by running the TSA.SERVICE. This will auto start and
stop providing the TSM is running.

Example of the TSA.SERVICE

Once the service agent has completed, the relevant SEC.ACC.MASTER will reflect the current valuation.

As described above, the valuations reports can be produced online by the application OL.VAL.REPS or automatically by the system during the
COB (CLOSE OF BUSINESS) stage at the frequency defined on the CUSTOMER.SECURITY record for the CUSTOMER of the portfolio con-
cerned (see screen capture of CUSTOMER.SECURITY described earlier). The automatically produced reports can be produced as part of the
securities price feed, when they will be produced on the morning after the frequency date - i.e. with the previous day’s closing prices) or by the
Close of Business.

There are two frequencies onCUSTOMER.SECURITY, Internal and External. This is to allow the Bank to specify separate frequencies for a
report for the Account Officer (Internal) and for the Customer (External). For example the Account Officer may wish to review the portfolio
weekly while the Customer will only receive monthly valuations.

Both report frequencies have an associated report field EXTERNAL.REPS and INTERNAL.REPS and both are multi-value type fields enabling
you to specify more than one format valuation report. These valuation formats are available within the SC.REPORT.TYPE application and allow
different versions of the same report to be specified. Similarly OL.VAL.REPS requires a report type to be specified. The tailored Valuation
Reports program to produce specially tailored layouts can use these fields. For example the Client and the Account Officer may want to see dif-
ferent information in the report.

The valuation reports can be quite large, depending upon the number of components a customer holds within his portfolio. The following
extract is therefore only a small portion of a valuation :

Portfolio Management - User Guide - Release R15.000 - Page 202 of 208

 VALUATION REPORT - Example 1

This extract (example 1) shows the first page of the printable valuation report and shows only the customer’s cash account and forward Forex 
transaction outstanding.

The extract following (example 2) shows the portfolio breakdown summary.

VALUATIONS REPORT - Example 2

Portfolio Management - User Guide - Release R15.000 - Page 203 of 208

Historical Portfolio Valuation Reports

As well as producing current portfolio valuation reports, T24 also retains information regarding the end of month position for all the customer
portfolios for the last twelve months. These historical valuations can be printed byOL.VAL.REPS or viewed through the screen enquiries such
as SC.HIST.VAL.COST. The information behind these historical valuations is stored at the end of the month concerned and other than being
updated with the end of month closing prices on the first Security Price update of the new month, left unchanged so that they are a true valu-
ation as at the end of month.

On inputting the OL.VAL.REPS, the field REPORT.MONTH is used to indicate precisely which month you require to be run. For example, the
current month is September and you want April, then you should enter “4” in the REPORT.MONTH field. If you enter, say, “10” then T24
assumes October of the previous year.

Portfolio Management - User Guide - Release R15.000 - Page 204 of 208

Drill-down enquiries to control portfolio Inflows Outflows

There are 3 enquiries. The first and second enquiries launch respectively the second and the third enquiries by drill down.

First enquiry: SC.VARIATION.PERFORMANCE

Overview
The first enquiry permits to show the portfolios of which performance matches a selected level criterion for a particular date.

Displayed information
The displayed information is: the selection criteria and the following details for each portfolio matching the criteria:

SC.VARIATION PERFORMANCE Enquiry: Selection Criteria

SC.VARIATION PERFORMANCE Enquiry: Columns

Second enquiry: SC.VARIATION.PERF.PORTFOLIO

Overview
The second enquiry enables to show performance screenshots for a selected portfolio between 2 selected dates.

The selection criteria are: Portfolio ID, performance level, Start date and End Date.

Displayed information
The displayed information is: the selection criteria, the portfolio reference currency and the following details for each Performance day matching
the criteria:

Selection Criteria
Portfolio Id
Performance Level
End Date

SC.VARIATION.PERF.PORTFOLIO Enquiry: Selection Criteria

Columns
Portfolio ID Performance date Contributions Withdrawals End Value Performance

SC.VARIATION.PERF.PORTFOLIO Enquiry: Columns

Complementary information
Reference currency

SC.VARIATION.PERF.PORTFOLIO Enquiry: Complementary Information

Portfolio Management - User Guide - Release R15.000 - Page 205 of 208

Third enquiry: SC.PERFORMANCE.DETAIL

Overview
The third enquiry enables to show all the transactions of a portfolio for a selected date.

The selection criteria are: Portfolio ID and performance date.

The enquiry will show the security side information only if the performance date given in the enquiry is less than or equal to last working day .
The enquiry will not show any data if the transactions are requested for today's date.

The enquiry will fetch data only for Dates where there are either Cash or Security Flows. If no Inflow or Outflow (as defined in
TRANS.FUND.FLOW) has occurred on the given date, no records will be displayed.

It permits to analyse whether a transaction is rightly/wrongly recorded or not recorded in SC.PERF.DETAIL by showing the Presence/Absence
of the type of transaction in TRANS.FUND.FLOW.

TRANS.FUND.FLOW is the file, which contains transaction type Input and Output, for Securities and Cash that must be integrated for per-
formance Net Cash Flow calculation.

SC.PERF.DETAIL is the performance file.

Displayed information
The displayed information is: the selection criteria, the portfolio reference currency and the following details for each Performance day matching
the criteria:

Selection Criteria
Portfolio ID
Perf.Date

SC.PERFORMANCE.DETAIL Enquiry: Columns

Columns
Transaction ID In/Out Flag Cash: In/Out Cash: No In/Out Sec: In/Out Sec: No In/Out

SC.PERFORMANCE.DETAIL Enquiry: Columns

Comments on table content:

Comments on table content

Portfolio Management - User Guide - Release R15.000 - Page 206 of 208

Enquiry portfolio performance between two dates
SC.DAILY.PERF

Overview
This enquiry enables the calculation and display of performance for one portfolio between two dates.

Performance screenshots are displayed monthly, quarterly and yearly, according to the chosen period, and calculated under the daily valu-
ation method.

Displayed information
The displayed information is: the selection criteria, the portfolio reference currency and the following details from the selected portfolio:

Selection Criteria
Portfolio ID
Start Date
End Date

Figure 1 SC.DAILY.PERF Enquiry: Selection Criteria

Columns
Period Contributions Withdrawals Net Flow Value Monthly Quarterly Yearly

SC.DAILY.PERF Enquiry – Columns

Complementary information
Reference currency
Return since the selected Start.date

SC.DAILY.PERF Enquiry – Complementary information

Comments on table content:

Comments on table content

Portfolio Management - User Guide - Release R15.000 - Page 207 of 208

Installation

For Installation information for this product, please refer to the main Product Installation guide

Portfolio Management - User Guide - Release R15.000 - Page 208 of 208