Portfolio Management

TEMENOS T24
Portfolio Management
User Guide
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Table of Contents
Overview.................................................................................................................................................. 5
Setup ....................................................................................................................................................... 5
Portfolio Set-Up.................................................................................................................................... 5
CUSTOMER.SECURITY.................................................................................................................. 6
SEC.ACC.MASTER ......................................................................................................................... 6
PORTFOLIO.CONSTRAINT ................................................................................................................ 8
Setting-up constraint records ........................................................................................................... 8
Special Constraints ........................................................................................................................ 10
Closed Portfolios ............................................................................................................................ 11
Architecture / Design ............................................................................................................................. 12
Asset Definition .................................................................................................................................. 12
ASSET.TYPE ................................................................................................................................. 12
SUB.ASSET.TYPE ......................................................................................................................... 14
Updating A Portfolio ........................................................................................................................... 15
Updating a Portfolio from an Account ............................................................................................ 16
Updating a Portfolio from the Securities Module ............................................................................ 18
Updating a Portfolio from Other Modules ....................................................................................... 18
Portfolio Valuation .............................................................................................................................. 20
Portfolio Valuation Enquiries .......................................................................................................... 20
Additional Valuation Information ........................................................................................................ 24
Suppression of Unsettled Trades from Valuations ......................................................................... 24
Portfolio Valuation Reports ............................................................................................................ 34
Historical Portfolio Valuation Reports............................................................................................. 38
Margin Calculation ............................................................................................................................. 38
Standard Calculation ...................................................................................................................... 38
Margin Calculation for Securities Assets........................................................................................ 38
Margin Calculation for Non Securities Assets and Liabilities ......................................................... 38
Summary ........................................................................................................................................ 39
Alternative Calculation - Different Loss Margin Rates ................................................................... 39
Summary ........................................................................................................................................ 40
Alternative Calculation - Assets Only ............................................................................................. 40
Summary ........................................................................................................................................ 41
TEMENOS T24 User Guide Page 2 of 145

Individual Customer Margins .......................................................................................................... 41

Deal / Transaction Processing .............................................................................................................. 44
Portfolio Performance ........................................................................................................................ 44
Contributions and Withdrawals ...................................................................................................... 44
Portfolio Profit and Loss ................................................................................................................. 48
Portfolio Performance Calculation Methods ...................................................................................... 49
The Modified Dietz Method ............................................................................................................ 49
Daily Valuation method .................................................................................................................. 50
Co-existence of both methods from T24 release G11.2 ................................................................ 51
Specific Release Notes .................................................................................................................. 51
Remove Performance Routines ..................................................................................................... 51
Maintain Daily Performance files and their content........................................................................ 52
SC.PERF.DETAIL and SC.CASH.FLOW.TRANS ......................................................................... 52
SC.CASH.FLOW.HIST ................................................................................................................... 53
Performance variation between the last two working days................................................................ 53
Overview ........................................................................................................................................ 53
Displayed information ..................................................................................................................... 53
Drill-down enquiries to control portfolio Inflows/Outflows............................................................... 54
First enquiry: SC.VARIATION.PERFORMANCE .............................................................................. 54
Overview ........................................................................................................................................ 54
Second enquiry: SC.VARIATION.PERF.PORTFOLIO ...................................................................... 55
Overview ........................................................................................................................................ 55
Third enquiry: SC.PERFORMANCE.DETAIL .................................................................................... 55
Overview ........................................................................................................................................ 55
Enquiry portfolio performance between two dates: SC.DAILY.PERF ............................................... 57
Overview ........................................................................................................................................ 57
Management Fees ............................................................................................................................. 58
Default Charging Structure ............................................................................................................. 59
Detailed Charging Structure ........................................................................................................... 60
Calculation of Management Fees ...................................................................................................... 62
Posting Of Management Fees ....................................................................................................... 65
Portfolio Management Fees - Monthly Average Balances & Accruals .......................................... 67
Portfolio Management Fees - Setting-up parameters for Daily Average Balance ......................... 68

Portfolio Management Fees - Setting-up parameters for Monthly Accruals .................................. 72

Advisory Fees Accrual Accounting Rules ...................................................................................... 73
Safe Custody / Safe Keeping Fees.................................................................................................... 73
Default Charging Structure ............................................................................................................. 74
Detailed Charging Structure ........................................................................................................... 75
Calculation of Safe Custody Fees ..................................................................................................... 80
Posting of Safe Custody Fees ........................................................................................................ 84
Safekeeping Fees - Monthly Average Balances & Accruals .......................................................... 86
Safekeeping Fees - Setting-up for Daily Average Balance ............................................................ 86
Safekeeping Fees - Setting-up parameters for monthly accruals .................................................. 90
Safekeeping Fees Accrual Accounting Rules ................................................................................ 93
Safekeeping and Management Fees – Previous Month closing balance based ........................... 94
Fee Review within the charge cycle ............................................................................................... 95
Fee calculation on portfolio closure................................................................................................ 95
Safekeeping and Management Fees – Daily Accrual .................................................................... 96
Safe custody fees – Account balances for fee calculation ............................................................. 99
Safekeeping and Management Fees – Performing Daily Accruals ............................................... 99
Portfolio Modelling ........................................................................................................................... 102
Defining a Portfolio Model - POLICY.PARAMETER .................................................................... 102
Maturity Bands within a Portfolio Model ....................................................................................... 103
Linking A Portfolio to a Portfolio Model - INVESTMENT.PROGRAM .......................................... 103
Securities Order Processing ............................................................................................................ 104
Overview ...................................................................................................................................... 104
Portfolio Modelling ........................................................................................................................... 105
Single Portfolio Comparison - SC.PORT.COMPARE .................................................................. 105
Single Portfolio Order Generation - SC.PORT.ORDER............................................................... 106
Group Portfolio Comparison - SC.GROUP.COMPARE ............................................................... 108
Group Portfolio Order Generation - SC.SECURITY.ORDER ...................................................... 112
Order by Customer .......................................................................................................................... 115
ORDER.BY.CUST,PURCHASE ................................................................................................... 119
ORDER.BY.CUST,SWITCH ........................................................................................................ 121
ORDER.BY.CUST,CASH ............................................................................................................. 124
ORDER.BY.CUST,SELL .............................................................................................................. 126
SERVICE BASED ORDERS ........................................................................................................ 129
Rounding – Service based ........................................................................................................... 129
SC.STD.SEC.TRADE................................................................................................................... 129
SC.VALUATION.EXTRACT ............................................................................................................. 145

Overview
T24 supports three types of portfolio:
• Banks Own Position Portfolios.

• Customer Portfolios.
• 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.
Setup
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 important fields available to “fine tune” T24 to work for you.
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 management 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 belonging 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.

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 screenshot there are five ACCOUNT records 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.
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.
PORTFOLIO.CONSTRAINT
This facility allows the control of exposure to a particular issuer within a customer’s portfolio and
additionally permits the inclusion or exclusion 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:
• The maximum percentage of the value of the portfolio
• 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 – checking will still be
performed to ensure that any addition of security to a portfolio does not cause the total holding to
exceed the equivalent specified 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 customer 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 constraints 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.CONSTRAINT example

In the above instance, checking will be carried out on all security purchases performed on behalf of
portfolio 888-1 to ensure:
• That any securities issued by customer 3610 do not exceed 50% of the total portfolio value.
• 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 situation 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.
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 inputter 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 like SC.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 capital 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.PARAMETER is set to NO, then the system would ignore
closed portfolios while updating the performance related files and fields mentioned in the above
paragraph. The updates to SC.VALUATION.EXTRACT would be stopped from the day after the
closure; the updates to performance fields in SEC.ACC.MASTER would 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.PERFORM file (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).
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 functionality to be triggered.
Architecture / Design
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 management 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
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 variable 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
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 specific 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.
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 Securities 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 a 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

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 components, 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 perform 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 result update a portfolio with the value of that transaction. In
addition to this, forward value security transactions are included in the portfolio valuation.
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 disposing 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.PARAMETER record keyed on the ID of the company in which
the portfolio is included. If it has then when the system calculates the valuation 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.
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 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-security 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 revaluation 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 values in this currency. However, it is
possible to specify a valuation currency that may differ from the REFERENCE.CURRENCY specified
currency. 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 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 valuation 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.
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 market price.
SC.ASSET.VAL.MARGIN Value Enquiry showing position, description of

position, estimation and margin 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 margin value of
portfolio.
SC.VAL.MARKET Trade Enquiry showing position, description of

position, estimation and market 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.MASTER record is shown in the
screenshot above. As is typical of the Portfolio Valuation Enquiries, the ENQUIRY is broken down by
SUB.ASSET.TYPE with sub totals being displayed for each.

ENQUIRY - SC.VAL.COST FX Contracts
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 differences 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.DEPOSITS transactions 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 details
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 instructions 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 latter field, SC.TRANS.NAME, is used to identify the transaction
types (from the SC.TRANS.NAME file) you wish to be excluded from any valuations 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.
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”.
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 positions file, SECURITY.POSITION for the SECURITY and
CUSTOMER.
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.
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 portfolio (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.

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 illustrative 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.

On a more technical note, the valuations enquiries utilise the file SC.POS.ASSET file which is only
updated upon settlement of those transactions 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 illustrated 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 –
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 valuation. This is because
the SECURITY.POSITION field FREE.NOM.PEND is updated immediately the change is made to
SC.SETTLEMENT.

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.

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 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 produced 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.
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 concerned (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 on CUSTOMER.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 different 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 :

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

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 by OL.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 valuation 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.
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.
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 will be used for the margin calculation. If there is no ASSET.BY.CATEG record
then the SEC.MARGIN.RATE on the relevant SUB.ASSET.TYPE record will be used. If there is no
input in this field, then the MARGIN.RATE field on the associated ASSET.TYPE record will be used. If
no margin rate has been input in any of these records then the margin value of the asset or liability will
be assumed to be zero.

Summary
MARGIN.RATE on SC.PARAMETER = Null

Securities Non Securities Assets Non Securities Liabilities
1 MARGIN.CONTROL on MARGIN.RATE on MARGIN.RATE on
SECURITY.MASTER ASSET.BY.CATEG ASSET.BY.CATEG
2 SEC.MARGIN.RATE on SEC.MARGIN.RATE on SEC.MARGIN.RATE on
SUB.ASSET.TYPE SUB.ASSET.TYPE SUB.ASSET.TYPE
3 Margin rate = 0 MARGIN.RATE on MARGIN.RATE on
ASSET.TYPE ASSET.TYPE
4 Margin rate = 0 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.

The standard method will be 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.

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

Summary
MARGIN.RATE on SC.PARAMETER = BOTH

Securities Non Securities Assets Non Securities Liabilities
1 MARGIN.CONTROL on MARGIN.RATE on LOSS.MARGIN.RATE on
SECURITY.MASTER ASSET.BY.CATEG ASSET.BY.CATEG
2 SEC.MARGIN.RATE on SEC.MARGIN.RATE on LOSS.MARGIN.RATE on
SUB.ASSET.TYPE SUB.ASSET.TYPE SUB.ASSET.TYPE
3 MARGIN.RATE on MARGIN.RATE on LOSS.MARGIN.RATE on
ASSET.TYPE ASSET.TYPE ASSET.TYPE
4 Margin rate = 0 Margin rate = 0 Margin rate = 0
Table 3 Alternative Calculation - Different Loss Margin Rates Summary
Alternative Calculation - Assets Only
The following margin value calculation will be used if the MARGIN.VALUE field in the
SC.PARAMETER is set to ASSET.

The standard method will be 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.

Non-securities assets will follow the standard method for margin calculation. All liabilities will have a
margin value of zero.

Summary
MARGIN.RATE on SC.PARAMETER = ASSET
SECURITIES NON SECURITIES ASSETS NON SECURITIES LIABILITIES
1 MARGIN.CONTROL on MARGIN.RATE on Margin rate = 0

SECURITY.MASTER ASSET.BY.CATEG
2 SEC.MARGIN.RATE on SEC.MARGIN.RATE on
SUB.ASSET.TYPE SUB.ASSET.TYPE
3 MARGIN.RATE on MARGIN.RATE on
ASSET.TYPE ASSET.TYPE
4 Margin rate = 0 Margin rate = 0
Table 4 Alternative Calculation - Assets Only
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, sub asset type or asset type
level. Depending upon whether a valuation should include/exclude liabilities (based on
MARGIN.VALUE in SC.PARAMETER), either the field LOSS.MARGIN.RATE or MARGIN.RATE will
be 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 1

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

Type
SC.CUSTOMER.MARGIN table – Portfolio level – Asset Type 3
SC.CUSTOMER.MARGIN table – Portfolio level – ALL 4
SC.CUSTOMER.MARGIN table - Customer Number – 5

Security Master
SC.CUSTOMER.MARGIN table - Customer Number -Sub 6

Asset Type

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

Type
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 1
not Securities or Type
Fiduciaries)
SC.CUSTOMER.MARGIN table – Portfolio level – Asset Type 2
SC.CUSTOMER.MARGIN table – Portfolio level – ALL 3
SC.CUSTOMER.MARGIN table – Customer Number – Sub 4

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

Type
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 2

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

type
SC.CUSTOMER.MARGIN table – Customer Number – ALL 4
FID parameter level 5
Sub Asset Type 6
Asset type 7
NOTE that 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 collaterals, 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.

Deal / Transaction Processing

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 application. As well as the value of the portfolio it
also holds details of Contributions and Withdrawals 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 contributions 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
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.FLOW record 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 custody account by a third party. This receipt was
delivered “free of payment” and therefore there is no physical cost associated with the transaction.
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.
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.
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 concerned 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.
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 specially tailored Portfolio
Valuation Reports to show portfolio performance but can also be used by enquiries such as
SC.VAL.COST as shown previously in the totals page for the Enquiry.

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.
R = MVE − MVB − F
MVB + FW
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 formula for Wi is
CD − Di
Wi =
CD
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.
RDAILY = (S1 × S 2 × Sn ) − 1
Where S1, S2 through Sn are the sub-period indexes for sub-periods 1,2 through n.
Note that 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:
Ri = S1 − 1
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:
MVEi
R=
MVBi
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.

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
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.
Performance variation between the last two working days

Overview
This is a report launched in batch mode: COB.
• 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 criteria:

Performance Variation Report: Selection Criteria
Performance Variation Report: Columns
Performance Variation Report: Complementary Information
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.
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.
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 Performance date Contributions Withdrawa End Performance
ID ls Value
SC.VARIATION.PERF.PORTFOLIO Enquiry: Columns
Complementary information
Reference currency
SC.VARIATION.PERF.PORTFOLIO Enquiry: Complementary Information
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.
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 performance Net Cash Flow calculation.
SC.PERF.DETAIL is the performance file.
details for each Performance day matching the criteria:
Selection Criteria
Portfolio ID
Perf.Date
SC.PERFORMANCE.DETAIL Enquiry: Columns
Columns
Transactio In/Out Flag Cash: In/Out Cash: No Sec: In/Out Sec: No
n ID In/Out In/Out
SC.PERFORMANCE.DETAIL Enquiry: Columns

Comments on table content:
Comments on table content
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 valuation method.
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
Management Fees
The T24 portfolio management system contains functionality that allows a user to set-up a fee
charging structure to automatically charge management 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 Securities 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 CUSTOMER 888, 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 record that 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 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).

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 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 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 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.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
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 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 process 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.
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.

SAFECUSTODY.VALUES - Example record
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 controlled 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.
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 Management Fees calculation fields on the SEC.ACC.MASTER
record that defines the portfolio. These are shown below:
SEC.ACC.MASTER - Define Management Fees
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 information 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 customer 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 Management
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 that some of the fields can be amended such as the ACCOUNT.NO, VALUE.DATE and
LOCAL.FEES.LCY fields.

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 calculated
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 T24 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 that 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 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.
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 T24 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.
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.
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.ACTIVITY and SC.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'.
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
= 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 category code, in the range of 11000 to 19999, as shown in the
ACCRUAL.CATEG field in the following screenshot.
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 tell T24 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.

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:
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
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 Custody 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. Management 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 Securities 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.CONDITION record. 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 CUSTOMER 900 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:

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 Management 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 portfolio a percentage of this fee.
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. Where various levels of settings are used the
system will select a charge parameter in the following order of priority:
MATCHING CLASSIFICATION ID FORMAT EXAMPLE

ORDER
1 Security Number ’.’ nnnnnn-nnn ’.’ Depository 123456-000.100001
Depository
2 Security Number nnnnnn-nnn 123456-000
3 SUB.ASSET.TYPE ‘.’ “S-“n to “S-“nnnn ‘.’ S-300.100001
Depository Depository
4 SUB.ASSET.TYPE “S-“n to “S-“nnnn S-300
5 ASSET.TYPE ‘.’ Depository “A-“n to “A-“nnn ‘.’ Depository A-20.100001
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 question of linking it to the charge structure as shown
below:
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:

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
3 User defined local reference ‘.’ “L-“n (n – a valid value in L-1.100001
Depository user defined local
reference) ‘.’ Depository

4 User defined local reference “L-“n (n – a valid value in L-1

user defined local
reference)
5 SUB.ASSET.TYPE ‘.’ Depository “S-“n to “S-“nnnn ‘.’ S-300.100001
Depository
7 ASSET.TYPE ‘.’ Depository “A-“n to “A-“nnn ‘.’ A-20.100001
Depository
9 Default ‘.’ Depository “ALL” ‘.’ Depository ALL.100001
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 Example
2 User defined local reference “L-“n (n – a valid value in L-1
user defined local
reference)
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 a SECOND.FEE.CODE in 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
with CALC.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 process 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.
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.

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
PERIOD.END C
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"
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 T24 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 Custody
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 Custody Fees calculation fields on the SEC.ACC.MASTER
record that defines the portfolio. The date of the next Safe Custody fees run for a portfolio 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.
During the Close of Business the system will check the system date against the date in the
SAFECUSTODY.FREQ field for any customer portfolio where the PORTFOLIO.FEES date is
AUTOMATIC and if the date is less than the next working day, automatically calculate the Safe
Custody 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 that 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.
Once all the SAFEKEEP.HOLDING records have been reviewed the set-up of the
SAFECUSTODY.VALUES application for the company concerned 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 T24 Close

of Business. Alternatively they can be posted online by running the application

SC.SAFE.FEES.POST.
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.POST flag is set to “NO” then the Safe Custody Fees can be posted for an individual
portfolio or for all 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 phase of the
T24 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.
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)
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.

SC.SAFEKEEP.ACTIVITY - Example activity

Positional details are stored monthly. The id of the record above indicates the following:
888-1 Portfolio number

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.

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 category 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.

SAFECUSTODY.VALUES - Setting-up accruals
You now need to advise T24 that you wish accruals to be made by setting the PERFORM.ACCRUAL
field to “MONTHLY”.
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.

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

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 for CHARGE.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
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 portfolios 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 Portfolio opened in Portfolio opened in March (third

in January (first February (second month) month)
month)
Opening Opening on 20th Opening on 20th February: Opening on 20th March:
of a January:
Q1 will have 0 fee for There will be no fee in Q1 and 12 days
portfolio
Q1 will have 0 fee January + 0 fee for of Q1 will be added to Q2 (April days).
for January + February + (PVBase at
‘* - assuming Day basis as Actual and
(PVBase at January February end * rate for 40
for a non-leap year
end * rate for 40 days)
days) + (PVBase at
‘* - assuming Day basis as
February end * rate
Actual and for a non-leap
for 31 days)
year
‘* - assuming Day
basis 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 closed in Portfolio closed in Portfolio closed in March (third

January (first February (second month) month) – after show fee date
month)
Closure Closing on 20th Closing on 20th February: Closure on 10th March
of a January:
Q1 will have (PVBase at Fees will be (PVBase at December end
portfolio
Q1 will have December end * rate * Jan * rate * Jan days) + (PVBase at January
(PVBase at days) + (PVBase at January end * rate * Feb days) + (PVBase at
December end * end * rate for 20 days) February end * rate for 10 days).
rate for 20 days).
The calculations will
stop on that date Since on show fee date, the whole
period fee would have been calculated
and updated in SAFEKEEP.HOLDING
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 calculations 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 categories 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:
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 categories for which the reversals and rebooking would be
required need to be configured in ACCR. REV. PARAM.

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 categories.
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
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 portfolio by using an ACCOUNT to hold the metal account
balance and if safe keeping charges are to be levied for these holdings, then this functionality 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:

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.

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.
Where the DETAIL method has been defined in SCPM.GROUP.CONDITION
/SCSK.GROUP.CONDITION the supporting detail for the fee calculation can be viewed in the
application SC.DAILY.ACCRUAL.DETAIL.

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 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.PROGRAM that enables a SEC.ACC.MASTER
record to be linked to an INVESTMENT.PROGRAM record. INVESTMENT.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

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 portfolios will use
this model in comparisons of actual holdings against the pre-defined investment model.
Securities Order Processing

Overview
SC.PORT.COMPARE SC.GROUP.COMPARE
ORDER.BY.CUST SC.PORT.ORDER SC.SECURITY.ORDER
SEC.OPEN.ORDER
SC.EXE.SEC.ORDERS
SEC.TRADE
Securities Order Processing Overview

Portfolio Modelling
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 associated 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.

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 securities.
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.

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 :
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.
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 Officer can 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.

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.

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 securities/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 comparison. 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.
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 securities 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 security 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 :
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).

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.
Order by Customer
The ORDER.BY.CUST application is a powerful front-end securities order generation process. Using
user defined selection criteria the application 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 additional 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". Similarly, it is possible to define both
INVESTMENT.PROGRAM and MANAGED.ACCOUNT.
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 calculate 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 conjunction 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
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 calculations.
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 calculations 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.
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 settlement 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 having 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 commission 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 including commission and charges that can be purchased. For a SELL
transaction the cash amount will be adjustment over based on the nearest nominal 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 commission 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.
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
populated 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.
ORDER.BY.CUST,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.
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.
ORDER.BY.CUST,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 proceeds 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 of
SECURITY.MASTER records. Similarly, the target securities for which the resultant buy order needs
to be generated should be input in SECURITY.NO.CR which again 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 in SC.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 overridden. 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.
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 specify if the sale consideration should include/exclude any
open orders that may exist in the system for the selected portfolios by entering appropriate 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 illustrates the result of this action.

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 generated 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.
ORDER.BY.CUST,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.

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 original holding in each security.
ORDER.BY.CUST,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 criteria, 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.

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 disposed 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 :

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 process 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 selection 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.
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
Valid options are 'BY.CUST', 'BY.DEPO', 'BY.BROKER', 'BY.PORTFOLIO'.
Optional Input.
'BY.CUST' and 'BY.PORTFOLIO' are not supported for service-based orders.
The process work flow for service based orders is as follows:

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 in live.

Example of a service based ORDER.BY.CUST

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

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

List of the SC.SOO.CUST.DETAIL generated

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

SEC.OPEN.ORDER example

SC.SOO.CUST.DETAIL example
Once authorised service agent SEC.OPEN.ORDER.SERVICE auto starts.

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

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

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

SC.SEC.TRADE.CUST.DETAIL example

SC.SEC.TRADE.CUST.DETAIL example
SEC.TRADE
Update SEC.TRADE with settlement details 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


SEC.TRADE in INAU
SC.SEC.TRADE.CUST.DETAIL in INAU

Update the SC.SEC.TRADE.CUST.DETAIL with settlement details authorise 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.

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 for each 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

Uploaded by

Copyright:

Available Formats

Portfolio Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Portfolio Management

Uploaded by

Copyright:

Available Formats

TEMENOS T24

Information in this document is subject to change without notice.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide Page 2 of 145

Individual Customer Margins .......................................................................................................... 41

TEMENOS T24 User Guide Page 3 of 145

Portfolio Management Fees - Setting-up parameters for Monthly Accruals .................................. 72

TEMENOS T24 User Guide Page 4 of 145

• Banks Own Position Portfolios.

TEMENOS T24 User Guide Page 5 of 145

TEMENOS T24 User Guide Page 6 of 145

TEMENOS T24 User Guide Page 7 of 145

Setting-up constraint records

TEMENOS T24 User Guide Page 8 of 145

TEMENOS T24 User Guide Page 9 of 145

PORTFOLIO.CONSTRAINT - Example OVERRIDE

TEMENOS T24 User Guide Page 10 of 145

PORTFOLIO.CONSTRAINT - Override in action

PORTFOLIO.CONSTRAINT - Error Message in action

TEMENOS T24 User Guide Page 11 of 145

SC.PARAMETER – Closed Portfolio

TEMENOS T24 User Guide Page 12 of 145

The REPORT.SUB.TOTAL field is linked to the SC.VAL.REP.SUB.TOTAL application and allows

ASSET.TYPE for SC application - Shares

TEMENOS T24 User Guide Page 13 of 145

SUB.ASSET.TYPE - Non-SC application

TEMENOS T24 User Guide Page 14 of 145

TEMENOS T24 User Guide Page 15 of 145

Updating a Portfolio from an Account

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

TEMENOS T24 User Guide Page 16 of 145

FUNDS.TRANSFER - Funds to be invested

SEC.ACC.MASTER valuation after cash inflow

TEMENOS T24 User Guide Page 17 of 145

Updating a Portfolio from the Securities Module

Updating a Portfolio from Other Modules

LD Deposit linked to portfolio

TEMENOS T24 User Guide Page 18 of 145

VALUATION showing customer deposit

TEMENOS T24 User Guide Page 19 of 145

VALUATION - Interrogating valuation details

Portfolio Valuation Enquiries

TEMENOS T24 User Guide Page 20 of 145

NO - Unauthorised transactions will not be included in the valuation

SC.PARAMETER showing the

This setting is applied to the applications SEC.TRADE and SECURITY.TRANSFER only.

TEMENOS T24 User Guide Page 21 of 145

Enquiry Name Trade/Value Dated Description

SC.ASSET.VAL.CASH Value Enquiry showing estimation and estimated

SC.ASSET.VAL.COST Value Enquiry showing position, description of

SC.ASSET.VAL.MARKET Value Enquiry showing position, description of

SC.ASSET.VAL.MARGIN Value Enquiry showing position, description of

SC.VAL.CASH Trade Enquiry showing estimation and estimated

SC.VAL.COST Trade Enquiry showing position, description of

SC.VAL.MARGIN Trade Enquiry showing position, description of

SC.VAL.MARKET Trade Enquiry showing position, description of

Table 1 – PORTFOLIO VALUATION ENQUIRIES

TEMENOS T24 User Guide Page 22 of 145

ENQUIRY - SC.VAL.COST FX Contracts

ENQUIRY - SC.VAL.COST Accrued Interest