AM BACK VALUE MANAGEMENT

Overview of Input and Processing

Registering Back-Value operations

Below are described successively registering the back-dated operations, which are included in the
back-value system:

 Back-value on price
 Back-value on exchange rate
 Back-value on cash
 Back-value on security
 Back-value on corporate action

Registering back value on price

The application, which enables the user to record back-value on price is SC.PRICE.CHANGE.

This file is updated either from a process derived from the SECURITY.MASTER price update for
non-backdated or backdated price changes, or directly from the SC.PRICE.CHANGE application.
The main rules on which this application has been developed for backdated price are as follows:

Change of price, impacted period

When a price is changed in SC.PRICE.CHANGE, it affects the day for which the price has been
changed and the following days when no price is recorded for those days.

Example 1:
Existing price in SC.PRICE.CHANGE:

Date Price for share Y

2 July 01 50
5 July 01 55
6 July 01 54

Current date is 10th July, assume that the user want to change the price of the 3rd July.

The user creates a new entry in SC.PRICE.CHANGE for that date. When he validates the input
(authorizes it), the system checks the status of the day following this new entry. If no price existed
for the following date, the system will also apply this new price to this following day.
Note that in the case where no other entry exist in SC.PRICE.CHANGE, greater that the changed
price, this changed price will be affected from the changed date till the day prior to current date. On
current date, the price existing is SECURITY.MASTER file be used for updating.

Example 2:
Existing price in SC.PRICE.CHANGE:

Date Price for share Y

2 July 01 50
3 July 01 52

Existing price in SECURITY.MASTER on 10th July: 50

Current date is 10th July, assume that the user want to change the price of the 3rd July.
The user creates a new entry in SC.PRICE.CHANGE for that date. When he validates the input
(authorizes it), the system checks the status of the day following this new entry. If no price existed
for the following date, the system will also apply this new price to this following day.
Changing a price

The user can face two different types of situation for the date he wants to change the price:
1. A previous price already existed in SC.PRICE.CHANGE.
2. No previous price existed for that date in SC.PRICE.CHANGE.

In the first case the user creates a multi-value set of fields to change the price and updates the field
NEW.PRICE.

Important: the field TIME.CHANGE contains only the time and not the date when the price has
changed.

Consequence: when modifying a price in back-value, a time later than the last entered must be
inputted: an error message will appear if this condition is not met.

In the second case the user creates a new record in SC.PRICE.CHANGE for the new date.

The record ID in this application is composed in the following way:

000121-000.20000320, where 000121-000 is the security number, and 20000320 is the date on
which the price applies.

History of changed price

A record of all backdated price changes is kept in the SC.PRICE.CHANGE history file.

New multi-value set of fields:

A previous rate already existed in SC.PRICE.CHANGE: so a multi-value set is created to input the
new backdated price (3.2)
 Figure 1 - SC.PRICE.CHANGE New multi-value set

Note the TIME.CHANGE: we can see on this view that the TIME.CHANGE on the new multi-value set
is 16:03. This new price will be used for revaluation purposes.

New record:

No previous price existed for that date in SC.PRICE.CHANGE: a new record is created to input the
new backdated price.
 Figure 2 - SC.PRICE.CHANGE New record

Registering back value on exchange-rate

The application, which enables the user to record back-value on rate is AM.CCY.RATE.
This file is dedicated for backdated change of currency rate.
Daily updating of currency rate is done using CURRENCY application.
The main rules on which AM.CCY.RATE has been developed are as follows:

Change of rate, impacted period

When a rate is changed in AM.CCY.RATE, it affects the day for which the new rate is dated till the
next change of rate event available in the currency application. That is the next record found on the
currency table for the following date.

Specific case:

Note that this next record may exist for a reason different from a change of rate.

For instance if GBP was modified on the 5 Jul 2002 where the Bank date now is 10 Jul 2002 and
the next modification on the exchange rate was on 7 Jul 2002.

The records available on the History could be as below.

5th – 1.8 Cur.No being 40

6th – 1.8 Cur.No being 41 due to the change on another field
7th – 1.9 Cur.No being 42 due to the change on the Rate field
If the BV rate change was done on 5th as 1.75 then the system will do the recalculation for 5th. It
will not do for 6th as because a history record exists for the respective date even if this record exists
for another reason than a change of rate.

Changing a rate

The user can face two different types of situation for the date he wants to change the rate:

1. A previous rate already exists in AM.CCY.RATE.

2. No previous rate existed for that date in AM.CCY.RATE.

In the first case the system creates a new multi-value set of fields, after the user has answered Y to
the T24 message ‘Do you want to create a Multi-Value for the New Rate?’. The user can then input
the new rate in the field NEW.EXCH.RATE.

In the second case the user creates a new record in AM.CCY.RATE for the new date.

The record ID in this application is composed as follows:

CCY.yyyymmjj, where CCY is the currency code, and yyyymmjj is the date on which the rate
applies:

Example:

CHF.20020531 would be the record ID to change CHF rate on 31 May 2002.

Note that in both cases the previous exchange rate will be displayed in field OLD.EXCH.RATE, and
the record status field will appear as un-processed.

History of changed rates

A record of all backdated rate changes is kept in the AM.CCY.RATE history file.

New multi-value set of fields:

A previous rate already existed in AM.CCY.RATE: so a multi-value set is created to input the new
backdated rate.
 Figure 3 - AM.CCY.RATE New multi-value set

New record:

No previous rate existed for that date in AM.CCY.RATE: a new record is created to input the new
backdated rate.
 Figure 4- AM.CCY.RATE New record

Registering back value on cash

The applications, which enable the user to record back-value on cash are FUNDS.TRANSFER and
DATA.CAPTURE.

To be considered as a back-value operation by the recalculation process launched by the EOD, the
inputted VALUE.DATE affected to the account, that is the CREDIT.VALUE.DATE or the
DEBIT.VALUE.DATE must be less than the current T24 WORKING DATE.

Registering back value on securities

The applications, which enable the user to record back-value on securities are SEC.TRADE,
SECURITY.TRANSFER, POSITION.TRANSFER and SC.BOOK.COST.

To be considered as a back-value operation by the recalculation process launched by the EOD, the
inputted TRADE.DATE must be less than the current T24 WORKING DATE.

Registering back value on corporate actions

DIARY and ENTITLEMENT are the T24 applications that manage corporate actions (split,
coupon….).

The user creates first a DIARY to record a corporate action for a group of portfolios.

Types defining corporate actions are recorded in a table called DIARY.TYPE.

The DIARY generates an ENTITLEMENT for each portfolio impacted.

ENTITLEMENT can also be recorded manually for one portfolio, avoiding the DIARY stage.
To record a back-valued corporate action the user will use these applications: DIARY and
ENTITLEMENT.

To be considered as a back-value operation by the recalculation process launched by the EOD, the
inputted VALUE.DATE must be less than the current T24 WORKING DATE.

Note:

When creating a backdated transaction on a portfolio for a security, to a date preceding an existing
DIARY on this same security, the user may have to use the ENTITLEMENT application to update
the position in the portfolio that was not included in the original DIARY transaction.

Recalculation process

Below are described successively the recalculation process generalities and then recalculation
characteristics of each impacted area:

 Recalculate portfolio valuation:

o . Recalculate portfolio valuation after price change

o . Recalculate portfolio valuation after change of exchange rate
o . Recalculate portfolio valuation after back-valued cash transaction
o . Recalculate portfolio valuation after back-valued security transaction
o . Recalculate portfolio valuation after back-valued corporate-action transaction
o . Recalculate portfolio valuation after recalculation of account interests following
backdated operations
 Recalculate fees after portfolio valuation recalculation
 Recalculate portfolio performance
 Recalculate composite performance

Recalculation process generalities

Recalculation process parameters

Back-value recalculation process must be activated and parameterised from the AM.PARAMETER
application (implementation phase), which provides the following capabilities:
Activate Back-Value functionality

The field BACKVALUE.UPD value must be set to Y (Yes) to enable the activation of the back-value
recalculation.

Adjust Back-Value sub-process launching

Once Back-value system has been activated, launching of each Back-Value sub-process can be
parameterised as an EOD sub-process or as an On-Line sub-process or can be deactivated (OFF).

This is available for each of the following sub-processes:

 Back-Value sub-process on Price, using field BV.SECURITY.PRICE
 Back-Value sub-process on Exchange-Rate, using field BV.EXCHANGE.RATE
 Back-Value sub-process on Security transactions, using field BV.SECURITY.TRANS
 Back-Value sub-process on Cash transactions, using field BV.CASH.TRANS
 Back-Value sub-process on Corporate Actions, using field BV.CA.TRANS

Note that BV.TRANSACTION fields, BV.SECURITY.TRANS, BV.CASH.TRANS, BV.CA.TRANS are

dependant: all those 3 fields must have the same value: EOD, ONLINE or OFF.

Define Back-Value periods

The back-value parameterisation system requires to define 2 limitation dates from which back-value
recalculation process will take place: BV.SELECT.DATE and BV.REVAL.DATE.

The first date determines the date from which backdated operations will be selectable by the back-
value system.

The second date, which must be greater than or equal to the first date, determines the date from
which the recalculation updating should start.

Moreover, using the On-Line recalculation process provides the user with the ability to apply the
Back-Value recalculation for a selected date only: LAUNCH.DATE. This date must be greater than or
equal to BV.SELECT.DATE.

Consequently:
The system will not process if the Back-Value date of the operation is less than the
BV.SELECT.DATE date.
If the Back-Value date of the operation falls between the BV.SELECT.DATE and BV.REVAL.DATE,
then the recalculation will be processed from that Back-Value date and updating of the respective
tables will be from the BV.REVAL.DATE.
The system will process up to one day minus the date when the back-value operation has been
recorded into the system, excepted:
If LAUNCH.DATE was specified. In that case the system will process for that date alone.
The process events/type refers to the Price Change or Exchange Rate Change
For Price Change the system will process till the next price change found in the
SC.PRICE.CHANGE application.

For change of Exchange Rate the system will process till the next exchange rate found in the
CURRENCY table.
See also chapter ‘Back-Value system parameterisation and maintenance’ for details and view of
AM.PARAMETER.

The Principles for the recalculation process

EOD Common process

Each back-value operation recorded during day D, will be submitted to a first Back-Value common
process during the EOD following day D.

This common process orientates each back-value operation according to Back-Value

parameterisation settled in AM.PARAMETER: the operation will be either included in current EOD
recalculation, or recorded for availability for On-Line recalculation, or not processed
(BV.OperationName field = OFF).

The diagram below illustrates this common process regarding Back-Value cash updating sub-
system:

Fund.Transfer Securty transaction

Data.Capture (Cash side)

Statement.Entry

Check Back-value
authorised transactions :
FT, DC, SC and for
Trade.date < Globus
current date

Bv .Trans

Triggered either
automatically for BV
EOD parameterisation, Sc.Veh.
or on user demand for YYYYMM
BV OnLine
parameterisation
 Figure 5 - Back-Value cash updating sub-system

EOD Recalculation process

Operations, which are parameterised for EOD will be processed during the EOD of the day they
have been recorded, just following the above Common process, within the back-value period
defined in AM.PARAMETER

The next table indicates the default ordering of the batch jobs contained EOD BACKVALUE batch,
in the case where all sub-processes were parameterised for EOD:

Order Function Reports (*)

1 SC.VEH.YYYYMM updating and
2 EOD Common process
3 Price change by security Ordered by securities
4 Securities then cash transactions by portfolio Ordered by impacted
portfolios
5 Advisory fees (posted then calculated fees) by portfolios Ordered by impacted
portfolios
6 Safekeeping fees (posted then calculated fees) by Ordered by impacted
portfolios portfolios
7 Performance recalculation Ordered by impacted
portfolios

(*) : A report is generated for each of these back-value jobs. It lists back-value operations that have
been inputted during the day and that will generate recalculation during EOD back-value batch.

Processed records are cleared from Back-Value working file, BV.TRANSACTION during the SOD
process.

In the case where the back-value recalculation parameter BACKVALUE.UPD has been set to No in
BV.TRANSACTION is cleared also AM.PARAMETER).

ON-Line recalculation process

Operations, which are parameterised for ON-LINE remain available in BV.TRANSACTION file.

Their use for recalculation is defined and triggered using a dedicated application:
ONLINE.BACKVALUE.LAUNCH.

This application provides with the ability to select directly portfolios through portfolios numbers or
based on a selection of SECURITY.ACCOUNT.MASTER fields and criteria.

All un-processed On-Line Back-Value operations matching this selection of portfolios will be
processed within the back-value period defined in AM.PARAMETER (BV.SELECT.DATE and
BV.REVAL.DATE).

Moreover, a specific date field, LAUNCH.DATE, available in ONLINE.BACKVALUE.LAUNCH

authorizes to select and apply the Back-Value recalculation for that specific date only.
This date cannot be greater than or equal to today. It should be greater than Select date on the
AM.PARAMETER. The launch date should be a working day.

Figure 6 - ONLINE.BACKVALUE.LAUNCH Application

 Figure 7 - ONLINE.BACKVALUE.LAUNCH Application example

Note: the field STATUS can take the following values: “Blank” or “PROCESSED”. They indicate
respectively whether the record has not been processed or has been processed in Back-Value
recalculation process.

Am.Parameter Bv Operation Bv Online Recalculation

Bv.Trade/Value. Bv Input Bv Online Recalculation Updating Updating

Bv Operation Bv.Select.Date Bv.Reval.Date Date Date Current Date Launch.Date Start Date Start Date End Date
Bv Transaction 1-Jan-2002 1-Feb-2002 15-Feb-2002 5-May-2002 31-May-2002 Blank 15-Feb-2002 15-Feb-2002 4-May-2002
Bv Transaction 1-Jan-2002 1-Feb-2002 15-Jan-2002 5-May-2002 31-May-2002 Blank 15-Jan-2002 1-Feb-2002 4-May-2002
Bv Transaction 1-Jan-2002 1-Feb-2002 15-Dec-2001 5-May-2002 31-May-2002 Blank None None None
Bv Transaction 1-Jan-2002 1-Feb-2002 15-Jan-2002 5-May-2002 31-May-2002 10-Apr-2002 15-Jan-2002 10-Apr-2002 10-Apr-2002
Back-Value Transaction, example of recalculation periods using OnLine Back-Value
Recalculate portfolio valuation

Recalculate portfolio valuation after price change

Recalculation process:

The system selects every backdated price change that has occurred during the day and applies these
changes to the SC.VEH.YYYYMM set of monthly files.

Only the following security fields are updated by backdated price change.

Field no Field Name

6 SC.VEH.MARKET.PRICE

7 SC.VEH.ESTIMATION

11 SC.VEH.ESTIMTED.INCOME

44 SC.VEH.VALUE.REF.CCY

50 SC.VEH.ACCR.INT.REF.CCY

63 SC.VEH.MKT.PRICE.DTE

83 SC.VEH.BACKVALUE.DATE

The valuation is changed for the date the price has changed and the following days only where no
price is recorded.

Example of recalculation of SC.VEH.YYYYMM after change of price

Changes have been made on the 18th July 2000 price.

Historical valuation for that date is recorded in SC.VEH.200005 file.

We see in that example the impact of change of market price and change of estimation.

Before price change

portfolio date Security n° Short.Name Ccy No NominaL Cost price Market price estimation
12001-1 18.05.00 000121-000 MICROSOFT SHARES USD 1000 60.100 10 10000

After price change

portfolio date Security n° Short.Name Ccy No NominaL Cost price Market price estimation
12001-1 18.05.00 000121-000 MICROSOFT SHARES USD 1000 60.100 50 50000

Recalculate portfolio valuation after change of exchange-rate

Recalculation process:

The system selects every backdated rate change that has occurred during the day and applies these
changes to the SC.VEH.YYYYMM set of monthly files.

The following fields are updated by backdated exchange-rate change.

Field no Field Name
6 SC.VEH.MARKET.PRICE

7 SC.VEH.ESTIMATION

11 SC.VEH.ESTIMTED.INCOME

44 SC.VEH.VALUE.REF.CCY

50 SC.VEH.ACCR.INT.REF.CCY

63 SC.VEH.MKT.PRICE.DTE

83 SC.VEH.BACKVALUE.DATE

The valuation is changed for the date the rate has changed and the following days only where no
change of rate or currency history change is recorded.

Recalculate portfolio valuation after back-valued cash transaction

Recalculation process:

The system selects every backdated cash transactions that have occurred during the day and applies
these changes to the SC.VEH.YYYYMM set of monthly files on the impacted portfolios.

Only the following cash fields are updated by backdated cash transactions.

Field no Field Name

4 SC.VEH.NO.NOMINAL
7 SC.VEH.ESTIMATION
9 SC.VEH.ACCRUED.INT
83 SC.VEH.BACKVALUE.DATE

The case where a back-value transaction is inputted on an account which was not linked to the
portfolio will not create a valuation entry: the recalculation of the portfolio valuation after a back-
value cash transaction is applied only to existing entries in the SC.VEH.YYYYMM file. If no cash
position is shown no update is made.

Note that cash side of Security transactions ( SEC.TRADE and corporate actions including cash) is
included in Back-Value cash recalculation process

Recalculate portfolio valuation after back-valued security transaction

Recalculation process:

The system selects every backdated security transactions that have occurred during the day and
applies these changes to the SC.VEH.YYYYMM set of monthly files on the impacted portfolios.

Only the following security fields are updated by backdated security transactions.
Field no Field Name
1 SC.VEH.SECURITY.NO

2 SC.VEH.SHORT.NAME

3 SC.VEH.SECURITY.CCY

4 SC.VEH.NO.NOMINAL

5 SC.VEH.COST.PRICE

4 SC.VEH.MARKET.PRICE

7 SC.VEH.ESTIMATION

9 SC.VEH.ACCRUED.INT

11 SC.VEH.ESTIMATED.INCOME

21 SC.VEH.GR.COST.PRICE

36 SC.VEH.APPLICATION

44 SC.VEH.VALUE.REF.CCY

45 SC.VEH.EX.RATE.PR.REF

46 SC.VEH. EX.RATE.PR.SEC

47 SC.VEH. EX.RATE.SEC.REF

50 SC.VEH.ACCR.INT.REF.CCY

70 SC.VEH.BOOK.PRICE

73 SC.VEH.GR.BOOK.COST

79 SC.VEH.DAYS.ACCRUED.INT

83 SC.VEH.BACKVALUE.DATE

Recalculate portfolio valuation after back-valued corporate action transaction

Recalculation process:

The system selects every backdated corporate action transaction that has occurred during the day
and applies these changes to the SC.VEH.YYYYMM set of monthly files on the impacted
portfolios.

Only the following security fields are updated by backdated corporate action transactions.

Field no Field Name

1 SC.VEH.SECURITY.NO
2 SC.VEH.SHORT.NAME
3 SC.VEH.SECURITY.CCY
4 SC.VEH.NO.NOMINAL
5 SC.VEH.COST.PRICE
4 SC.VEH.MARKET.PRICE
7 SC.VEH.ESTIMATION
9 SC.VEH.ACCRUED.INT
11 SC.VEH.ESTIMATED.INCOME
21 SC.VEH.GR.COST.PRICE
36 SC.VEH.APPLICATION
44 SC.VEH.VALUE.REF.CCY
45 SC.VEH.EX.RATE.PR.REF
46 SC.VEH. EX.RATE.PR.SEC
47 SC.VEH. EX.RATE.SEC.REF
50 SC.VEH.ACCR.INT.REF.CCY
70 SC.VEH.BOOK.PRICE
73 SC.VEH.GR.BOOK.COST
79 SC.VEH.DAYS.ACCRUED.INT
83 SC.VEH.BACKVALUE.DATE

Recalculate portfolio valuation after recalculation of account interests following backdated

operations

Recalculation process:

T24 automatically recalculates account interests during the EOD process after backdated operations
that affected cash account (see T24 User Guide: Accounts, Interest & Charges chapter).

This process updates 8 different T24 core system files.

The back-value system get information from these files to apply the necessary changes to the
SC.VEH.YYYYMM set of monthly files on the impacted portfolios: accrued interests and possible
balance changes.

Only the following cash fields are updated by backdated account interest recalculation.

Field no Field Name

4 SC.VEH.NO.NOMINAL
7 SC.VEH.ESTIMATION
9 SC.VEH.ACCRUED.INT
83 SC.VEH.BACKVALUE.DATE

Recalculate fees after portfolio valuation recalculation

Two kinds of portfolio fees exist in T24: Advisory fees and Safe custody fees.

During the fee management process, fees take two different statuses: calculated and posted.

Calculated fees haven’t been debited from clients account. Posted fees have already been debited
from clients account and imply a more complex back-value process.
 TheG12.0.00
BVB3 back-value recalculation process
REPORT HOLDis made up of
CONTROL 2 stages:
FILE VERIFYthe first stage is common to both,
where as the second stage treats calculated and posted fees differently.
SPOOL.ENTRY....... 123284439302
------------------------------------------------------------------------------
BV.ADV.FEES.UPDATE BVB3 G12.0.00 04 MAY 01 Page 1
Area Retail Banking No 1 Printed at 01 OCT 2001 12:19:53
To Steve Josephs BLDG2-1

ADVISORY CHARGES RECALCULATION REPORT FOR CALCUALTED FEES

=================================================================
PERIOD START PERIOD END PREVIOUS FEES NEW FEES DIFFERENCE
--------------------------------------------------------------------------------

PORTFOLIO : 12001-1 BV1 PORTFOLIO 1

01 JAN 2001 31 MAR 2001 148.62 151.12 2.50

Common recalculation process:

The system selects every backdated transaction that has occurred during the day and re-calculates
the estimation based on the nominal and price and then it updates SC.ASSET.BAL and
SAFECUSTODY.EXTRACT. These files hold the monthly balances for each portfolio.

Recalculation of the calculated fees process

For calculated fees: SC.ADVISORY.CHG and SAFEKEEP.HOLDING are updated. After that the
standard process will post the fees.

Two reports are printed during this EOD process: one for the advisory fees and one for the safe
custody fees. Each report displays the following information for each of the portfolios impacted by
the calculated fees recalculation:
 . Portfolio ID
 . Period
 . Previous fees
 . New fees
 . Difference
BVB3 G12.0.00 REPORT HOLD CONTROL FILE VERIFY

SPOOL.ENTRY....... 123284439301
------------------------------------------------------------------------------
Recalculation of the posted fees process
BV.ADV.FEES.UPDATE BVB3 G12.0.00 04 MAY 01 Page 1
Area Retail Banking No 1 Printed at 01 OCT 2001 12:19:53
For posted fees: the SC.ADVISORY.CHG.POSTED and SAFEKEEP.HOLDING.POSTED are
To Steve Josephs BLDG2-1
updated. These re-calculated records are written to the above files with “IHLD” status.
ADVISORY CHARGES RECALCULATION REPORT FOR POSTED FEES
Two reports are printed during this EOD process: one for the advisory fees and one for the safe
=================================================================
PERIOD START
custody fees. PERIOD END PREVIOUS FEES NEW FEES DIFFERENCE
--------------------------------------------------------------------------------
Each report displays the following information for each of the portfolios impacted by the posted
fees recalculation:
PORTFOLIO : 12001-1 BV1 PORTFOLIO 1
01 JAN 2001 31 MAR 2001  Portfolio ID542.20 538.05 -4.15
 Period
 Previous fees
 New fees
 Difference

On the basis of this report, the user decides for each portfolio and each type of fee whether the
changes should be applied.

To apply the changes, the user has to authorize the records in the above-mentioned application.
Once the record is authorized, the difference between the Previous Posted Fees and the New Re-
Calculated Fees is posted using the system working. date.

The unauthorized records, which remain unchanged by a manual input (SYS.GENERATED=YES), are
cleared during the next EOD batch processing.

The unauthorized records, which are changed by a manual input ( SYS.GENERATED=NO) remain in
the file. They are kept until they are authorised or until a new back-value event generates a new
unauthorized record of recalculated posted fees for the same period. In that last case the system
refers to the last posted fees amount to calculate the difference with the new fees (and not to the
amount existing in the previous unauthorized record).
Example:

The first record is unauthorised and remains in the file (SC.ADVISORY.CHG.POSTED or

SAFEKEEP.HOLDING.POSTED according to fee type) because SYS.GENERATED=NO.

Record ID Record Sys-generated Previous New Difference

Status posted recalculated
Portfolio A.Period n Unauthorised NO 1000 1500 500
Portfolio A.Period n Unauthorized YES 1000 1800 800

The first record is over-written as soon as a new back-value event on this same portfolio and same
fee calculation period (same record ID) generates a new unauthorized record of recalculated
posted fees.

The system recalculates the difference referring to the last posted fees of the period: 1000.

Figure 8 - SC.ADVISORY.CHG.POSTED

Field definition for posted fees applications:

SC.ADVISORY.CHG.POSTED and SAFEKEEP.HOLDING.POSTED have been designed

respectively from existing application SC.ADVISORY.CHG and SAFEKEEP.HOLDING, the new
fields concerning recalculation of posted fees are described below (they are the same for both
applications):
 Fields Field definitions
CHARGES.LCY New recalculated amount of posted fees of the period in Local
currency
PREV.CHGS.LCY Previous posted amount of posted fees of the period in Local
currency
DIFFERENCE.LCY Difference between new amount and previous amount. in Local
currency.
DIFFERENCE.LCY= CHARGES.LCY - PREV.CHGS.LCY
CHARGES.AC.CCY New recalculated amount of posted fees of the period in Account
currency
PREV.CHG.AC.CCY Previous posted amount of posted fees of the period in Account
currency
DIFFERENCE.AC.CCY Difference between new amount and previous amount. in Account
currency
DIFFERENCE.AC.CCY=CHARGES.AC.CCY-PREV.CHGS.AC.CCY
SYS.GENERATED Equal to YES (default value) when the record has been created by
the system
Equal to NO when the record has been modified by the user

Recalculate portfolio performance

Recalculation process:

T24 automatically recalculates portfolio performance during the EOD process after back-value
portfolio revaluation.
This process updates two different T24 core system files: SC.CASH.FLOW.TRANS and
SC.PERF.DETAIL.

SC.CASH.FLOW.TRANS contains performance Inflows and Outflows details.

SC.PERF.DETAIL contains portfolio performance calculation results.

Back-valued Portfolio performance information status

A status field is managed for each daily performance sub-value set of data in the SC.PERF.DETAIL
file. Monthly SC.PERF.DETAIL record contains then the following daily sub-value fields:

Figure 9 - Sc.Perf.Detail Status field

This new STATUS field will contain one of the following three values:
 Status value Definition Remark
Blank Automatic Record was generated automatically by the system.
R Back-value Record was recalculated by the system by the
back-value process.
P Purged Record should have been recalculated by the
(Sub-Case of R) system by the back-value process but this has not
been done because the corresponding valuation
history data was purged in SC.VEH.YYYYMM
file
M Manual Record was manually inputted or corrected by the
user.
Record was imported from an external file.

The status flow is as follows:

Automatic Recalculated
Back-Value
- Status = Blank: - Status = R:
Automatic Process
Back-Value process or flows correction

Back-Value process or flows correction

Back-Value process or flows correction
Importation process
Manual correction Manual correction

Back-Value
Purged

- Status = P:
Manual correction
Manual

- Status = M:
Manual correction

Figure 10 – Status Flow

A recalculation of performance figures due to a back-value operation is processed and its result
recorded in the following cases:

 If the existing STATUS is Blank (the daily multi-value fields was generated automatically by the
system). The STATUS field value will then be changed to R or P.
 or if the existing STATUS is already equal to R (the daily multi-value fields had already been
modified by a back-value operation or by a correction flow tool that very date). The STATUS
field value will then remain to R or be changed to P.
 or if the existing STATUS is already equal to P (the daily multi-value fields should have already
been modified by a back-value operation or by a correction flow tool that very date). The
STATUS field value will then remain to P.
If the daily multi-value field has a manual status (STATUS=M) then recalculation and modification of
the performance due to a back-value change will be forbidden. No error message will be generated
by this event. The performance recalculation process will only skip that record.

Specific recalculation case: note that when a multi-value STATUS is changed to M, the next multi-
value index fields are recalculated and hence the STATUS field is changed to R.

Consistency with Free Receipts Security Price updating

Accordingly to the rule applied for the valuation of a free receipts flow recorded through
SECURITY.TRANSFER (valuation is calculated with the EOD market price): when a flow is
recorded at a backdated date the flow will be valued using the EOD market price of the trade date.
This will ensure that this flow will have no impact on the performance of the day when it is
recorded.

Reporting

Two types of reporting are available for this Back-Value system:

1. A batch report generated during the EOD. It lists portfolios that have been impacted by backdated
transactions during the day.
2. An enquiry that lists every backdated transaction that have impacted portfolio performance for a
selected period.

Batch report

This EOD batch report lists back-value events of the day that have triggered back-value
performance recalculation.

This list is ordered by portfolio and back-value ascending date. It contains the following
information:

Report Title:
Label or Type of information Content
Title BACK VALUE EVENT SUMMARY REPORT

Report columns:
Column title Content
Portfolio Portfolio number
Process.Date Processing date
BV.Date Trade-Date of the back-value transaction
Txn.Id Transaction ID
Txn.Type Transaction Type
Txn.Trigger Txn
Enquiry

The enquiry BV.PERF.REP lists every backdated transaction that has impacted the performance of
a portfolio for a selected period.

It can be launched directly or called by drill-down from Performance Daily Time series enquiry,
which displays the SC.PERF.DETAIL STATUS field called AM.PERF.PRT.Y.D.1M.

The selection criteria are the following:

Selection criteria Definition Default Value

Portfolio Portfolio number No default value
Start Period Start date of performance 01 of current year-month or
calculation period 01 of Portfolio closed year-
month (1)
End Period End date of performance Current date or
calculation period Portfolio Close date
Transaction type Type of back-value transaction No default value
st
(1) It is the 1 of the month in which the portfolio was closed.

Title bar:
Label or Type of information Content
Title List of Back-Dated transactions
Portfolio Portfolio number
Portfolio opened Portfolio creation date
Portfolio closed Portfolio closed date
Period Selected Start date of period
Selected End date of period

Grid columns:
Column title Content
Performance Date Performance date
Transaction type Type of BV transaction
Transaction ID Transaction ID
Instrument Instrument name
Booking Date Booking date when the BV transaction has been recorded
Trade Date Trade date when the BV transaction applies
Value Date Value date of the BV transaction
Currency Amount or price currency
Amount Amount
New Price New price of the instrument
Performance Flow Amount Performance flow amount generated by this transaction
(preceded by sign – for an Outflow)
Previous Price Previous price of the instrument
New Index SC.PERF.DETAIL recalculated index after BV transaction
Index variation New index minus Previous index divided by previous index
Recalculate composite performance

Unlike Composite performance calculation, which is performed by monthly batch jobs, Back value
recalculation on composites performance is a manual operation and can be executed for any period
in the past (provided composite data exists for respective back value period.).

On launching the recalculation process, composite performance is recalculated taking into account
the exclusion rules and balances as of the back value period.

Recalculation affects maximum period of one month. Consequently this process has to be launched
as many times as required by the number of back-value impacted period.

The composite back-value recalculation process includes three phases:

Collection of back value triggers for recalculation (Daily Batch update)

Triggers for back value activity are collected at transaction level from BV.TRANSACTIONS file.
When a portfolio linked to a composite is impacted by a back value operation the portfolio ID along
with composite and period details are recorded in BV.COMP.TRANS file. Portfolios that are
impacted by back value price change are also collected for recalculation. This file collectively holds
details of all composites and concurrent periods for which back value recalculation is required.

Back Value Exclusion Preparation. (Manual Launch)

Exclusion Preparation (see AM Composite Management User Guide) can be launched for any back
value period. Composite ID and back value period details are required for exclusion preparation.
Process looks into AM.COMPOSITE.ARC table (which contains AM.COMPOSITE archived
information stored at calculation date) to gather details of Exclusion rule as of the back value period
and triggers specific exclusion routines based on back value date balances. Details of portfolios
included/excluded are available in grid format and a user is allowed to change the system-defined
status for any back value period.

Launch of composite Performance recalculation for a back value period. (Manual launch)

This process does the actual recalculation of portfolio and composite performance. Process accepts
Composite ID.BV Period and recalculated all portfolios impacted by Back value based on
information available from BV.COMP.TRANS. Process also updates related files that contain
consolidated performance details based on Monthly and Yearly Period.

This process updates the three composite performance figure files by overwriting existing
information:
 AM.COMPOSITE.HIST:DETAIL
 AM.COMPOSITE.HIST
 AM.COMPOSITE,YEARLY.HIST

Portfolio history valuation file and enquiry

Portfolio valuation recalculation results are maintained using a monthly portfolio history files
system.
Each file of this set of files is named SC.VEH.YYYYMM where YYYY MM represents
respectively the year and month of the portfolio valuation data available in the file.

The chapters below describe the structure of this file and the specific enquiry, that addresses the
SC.VEH.YYYYMM file according to a selected date.

This enquiry is : SC.VAL.HIST.YYYYMM

SC.VEH.YYYYMM file structure

Note that the structure of this file is unique for securities information and cash information: field
definitions depend on the type of position.

ID composition

SC.VEH.YYYYMM ID is composed as follows:

Position Security record Account record

1 Portfolio number Portfolio number
2 Security number Account number
3 Depository
Different from blank only if blank
SEP.DEPOSITORY is set to Yes in
SC.PARAMETER
4 T24 system Date T24 system Date
5 Sub-asset type 1
6 Asset type 1
7 “D” “D”

Security

Field Field name Affected from – Calculation Comments

no
1 SC.VEH.SECURITY.NO SECURITY.NO field on SECURITY.MASTER
record

2 SC.VEH.SHORT.NAME SHORT.NAME field on SECURITY.MASTER

record

3 SC.VEH.SECURITY.CCY SECURITY.CURRENCY field on

SECURITY.MASTER record
 
4 SC.VEH.NO.NOMINAL CLOSING.BAL.NO.NOM field on Contains the number of securities (shares)
SECURITY.POSITION record held by the position or the nominal (bonds).

If the security position is short then the

5 SC.VEH.COST.PRICE
figure will be preceded by a '-' sign.
COST.PRICE = (COST.INVST.SEC.CCY * Contains the calculated cost for a single
PERC.FACTOR) / (NOMINAL * security in the SECURITY.CURRENCY
MULT.FACTOR) (calculated from credit movements).
Where COST.INVST.SEC.CCY is the
value contained in the
COST.INVST.SEC.CCY field on the
SECURITY.POSITION record.
PERC.FACTOR is 100 if the Security price
is expressed in percentage terms (found
 from the PRICE.TYPE record associated
with the security) and 1 otherwise.
MULT.FACTOR is the multiplication
factor for the security (found from the
PRICE.TYPE record associated with the
security).
NOMINAL is the closing nominal balance
found from the SECURITY.POSITION
record field CLOSING.BAL.NO.NOM.

If the position is built from more than one

SECURITY.POSITION records then the
COST.PRICE is pro-rated
(SEP.DEPOSITORY flag on the
SC.PARAMETER record for the company
is setting to NO). Remark : the system can
be set-up to show Security Positions held in
different depositories separately. (This is
done by setting the SEP.DEPOSITORY
flag on the SC.PARAMETER record for
the company to YES.)
6 SC.VEH.MARKET.PRICE LAST.PRICE field on SECURITY.MASTER
record
 
7 SC.VEH.ESTIMATION ACT.PRICE = ( MARKET.PRICE * Contains an estimated valued of the
MULTI.FACTOR) / PERC.FACTOR security position calculated using the
market price in the associated
ESTIMATION = NOMINAL * ACT.PRICE * MARKET.PRICE field. If the security
PERC.FACTOR position is short then the figure will be
preceded by a '-' sign.
For Futures :
ESTIMATION = (ACT.PRICE –
COST.PRICE) * NOMINAL * PERC.FACTOR
9 SC.VEH.ACCRUED.INT If the Security is a bond : This field contains the amount of interest
Calculation in SC.CALC.INT AMT module (income) that has been accrued for the
position but not yet been capitalised.
Represents the amount of accrued interest
on the Bond position.
10 SC.VEH.YIELD If the Security is a share : This field contains a percentage figure
YIELD = PRICE.EARN.RATIO equating to the yield of the position.
If the Security is a share then this field will
If the Security ais bond : be updated from the PRICE.EARN.RATIO
YIELD = YIELD.TO.MAT field on the SECURITY.SUPP record for
or the security. Represents the latest or
YIELD = INTEREST.RATE + ((100 - projected price earnings ratio, i.e. price over
COST.PRICE) * (INTEREST.RATE / 100)) its earnings per share.

If the Security is a bond then this field will

be populated from the YIELD.TO.MAT
field in the SECURITY.SUPP record for
the bond. If the YIELD.TO.MAT figure is
blank then it will calculate a yield using the
Interest Rate from the
SECURITY.MASTER record for the bond
and the cost price for the position.
11 SC.VEH.ESTIMTED.INCO If the Security is a share : If the Security is a share, the estimated
ME ESTIMTED.INCOME = annual income is calculated from the
(PRICE.EARN.RATIO / 100) * ESTIMATION PRICE.EARN.RATIO field on the
SECURITY.SUPP record for the security .
If the Security is a bond :
ESTIMTED.INCOME = (INTEREST.RATE / If the Security is a bond, the estimated
100) * ESTIMATION annual income is calculated from the
Interest Rate of the Security.
21 SC.VEH.GR.COST.PRICE GROSS.COST.PRICE = Contains the gross cost price for a single
(COST.INVST * PERC.FACTOR) / security expressed in the security currency
(NOMINAL * MULT.FACTOR) of the security (which will be the security in
the associated SECURITY.CCY field). It is
calculated using the
GROSS.COST.SEC.CCY field from the
SECURITY.POSITION record represented
by this set of values.

Where COST.INVST is the value contained

in the GROSS.COST.SEC.CCY field on
the SECURITY.POSITION record.
If the position is built from more than one
SECURITY.POSITION record then the
gross cost price is pro-rated.
 22 SC.VEH.GR.YIELD GR.YIELD = This field is only updated if the portfolio
INT.RATE + ((100 - GR.COST.PRICE) * position is for an interest bearing security.
(INT.RATE / 100)) Where INT.RATE is the interest rate taken
from the SECURITY.MASTER record for
the security. GR.COST.PRICE is the gross
cost price of the security position.
36 SC.VEH.APPLICATION 'SC' For a security position, this field contains
'SC'.

44 SC.VEX.VALUE.REF.CCY ESTIMATION * Exchange Rate between Contains an estimated value of the security
security currency and reference currency. position in the reference currency of the
portfolio
45 SC.VEH.EX.RATE.PR.RE Exchange rate between price currency and
F reference currency of the portfolio.

46 SC.VEH.EX.RATE.PR.SE Exchange rate between price currency and

C security currency.

47 SC.VEH.EX.RATE.SEC.R Exchange rate between security currency and

EF reference currency of the portfolio.

50 SC.VEX.ACCR.INT.REF. This field contains the amount of interest

CCY (income) that has been accrued for the
position but not yet been capitalised.
Represents the amount of accrued interest
on the Bond position, in the reference
currency of the portfolio.
59 SC.VEH.DURATION DURATION field on SECURITY.SUPP record Updated automatically with Duration of the
Yield. These figures are updated
automatically when the SC.CALC.YIELD
routine is run during the end of day process.
??
63 SC.VEH.MKT.PRICE.DTE  DATE.LAST.PRICE field on Indicates the date at which last price was
SECURITY.MASTER record effective.

70 SC.VEH.BOOK.PRICE Contains the average book price for a single

security in the security currency.

73 SC.VEH.GR.BOOK.COST (GR.BK.CST.SEC.CCY * PERC.FACTOR) / Contains the gross book price for a single
(NOMINAL * MULT.FACTOR) security expressed in the security currency
of the security.

Where GR.BK.CST.SEC.CCY is the value

contained in the field
GR.BK.COST.SEC.CCY on the
SECURITY.POSITION record.
79 SC.VEH.DAYS.ACCRUED. Difference Date between Valuation Date and Number of days accrued interest - i.e. the
INT ACCRUAL.START.DATE field on number of days from the last coupon
SECURITY.MASTER record. payment date (ACCRUAL.START.DATE
field on SECURITY.MASTER RECORD)
to the valuation date.

80 SC.VEH.CURRENT.YIELD From SECURITY.SUPP Updated automatically with the Current

Yield i.e. the annual interest of a Bond
divided by the market price..

83 SC.VEH.BACKVALUE.DAT Multi-value field

E Date of modification by back-value
operation

Account

Field Field name Affected from – Calculation Comments

no
1 SC.VEH.SECURITY.NO
2 SC.VEH.SHORT.NAME
3 SC.VEH.SECURITY.CCY
Contains the Account ID from the
ACCOUNT file
SHORT.TITLE field on ACCOUNT record
CURRENCY field on ACCOUNT record  
4 SC.VEH.NO.NOMINAL ONLINE.ACTUAL.BAL field
ACCOUNT record
5 SC.VEH.COST.PRICE  
on Contains the ONLINE.ACTUAL.BAL
balance from the Account record plus the
value of any forward entries for this
account generated by the Securities module
for transactions that have updated the
portfolio.
Not applicable for Account

6 SC.VEH.MARKET.PRICE   Not applicable for Account

7 SC.VEH.ESTIMATION ONLINE.ACTUAL.BAL field on Contains the ONLINE.ACTUAL.BAL

ACCOUNT record balance from the Account record plus the
value of any forward entries for this
account generated by the Securities module
for transactions that have updated the
portfolio.
9 SC.VEH.ACCRUED.INT ACCR.CR.AMOUNT + This field contains the amount of interest
ACCR.CR2.AMOUNT + (income) that has been accrued for the
ACCR.DR.AMOUNT + position but not yet been capitalised.
ACCR.DR2.AMOUNT fields on Contains the sum of the
ACCOUNT record ACCR.CR.AMOUNT (Amount of Credit
Interest on this Account which has been
calculated and accrued, -booked to Profit
and Loss-, but has not yet been capitalised
-booked to the Customer's Account-) ,
ACCR.CR2.AMOUNT (Amount of 2nd
type of Credit Interest on this Account
which has been calculated and accrued),
ACCR.DR.AMOUNT (Amount of Debit
Interest on this Account which has been
calculated and accrued) and
ACCR.DR2.AMOUNT fields (Amount of
2nd type of Debit Interest on this Account
which has been calculated and accrued).
10 SC.VEH.YIELD   Not applicable for Account

11 SC.VEH.ESTIMTED.INCOME Not applicable for Account

 
21 SC.VEH.GR.COST.PRICE   Not applicable for Account

22 SC.VEH.GR.YIELD   Not applicable for Account

36 SC.VEH.APPLICATION "AC" For an Account position, this field contains

'AC'

44 SC.VEX.VALUE.REF.CCY   Not applicable for Account

45 SC.VEH.EX.RATE.PR.REF   Not applicable for Account

46 SC.VEH.EX.RATE.PR.SEC   Not applicable for Account

47 SC.VEH.EX.RATE.SEC.REF   Not applicable for Account

50 SC.VEX.ACCR.INT.REF.CCY   Not applicable for Account

59 SC.VEH.DURATION   Not applicable for Account

63 SC.VEH.MKT.PRICE.DTE Not applicable for Account

70 SC.VEH.BOOK.PRICE   Not applicable for Account

73 SC.VEH.GR.BOOK.COST   Not applicable for Account

79 SC.VEH.DAYS.ACCRUED.INT   Not applicable for Account

80 SC.VEH.CURRENT.YIELD   Not applicable for Account

83 SC.VEH.BACKVALUE.DATE Multi-value field

Date of modification by back-value
 operation

Enquiry SC.VAL.HIST.YYYYMM

This enquiry enables the user to display the portfolio historical information contained in a of
SC.VEH.YYYYMM file.

Selection of the SC.VEH.YYYYMM file

This enquiry selects the SC.VEH.YYYYMM file required based on the information input by the
user in the following selection window. This window appears just after the standard enquiry
selection window.

In the following example the enquiry will select SC.VEH.200005 file.

Figure 11 - Enquiry SC.VAL.HIST.YYYYMM selection window

Enquiry view

The enquiry displays the data of the selected SC.VEH.YYYYMM file.

 Figure 12 - Enquiry SC.VAL.HIST.YYYYMM display

Back-Value system parameterisation and maintenance

Back-Value parameters

Back-Value system main parameters are maintained in AM.PARAMETER.

 Figure 13 - Valuation History file and Back-Value parameters

The parameter fields are described in the table below:

Fields Field definitions

HISTORIC Specifies whether the historical data of the
SC.VALUATION.EXTRACT has to be maintained (YES/NO).
If set to YES, the file SC.VEH.YYYYMM (YYYY- Year & MM
- Month No.) will be created and maintained.
Important: Historic = Yes is necessary to for Back-Value
recalculation.
HIST.PERIOD Used to indicate the maintenance period unit: Monthly or Yearly
HIST.DURATION Used to indicate the number of period of maintenance of the
history monthly files. The range is from 1 to 11.
For instance if HIST.PERIOD=Yearly and HIST.DURATION=2 : the
last 24 monthly historical files will be maintained.
SPECIAL.DATES This field is not used currently
BACKVALUE.UPD YES/NO
Yes activate back-value process batch
No Deactivate back-value process batch.
BV.SECURITY.PRICE Input can be either EOD, ONLINE or OFF
It is used to specify whether BV recalculation process on Price
will be an EOD process, an ONLINE process or will be
deactivated (OFF).
Input is allowed only if BACKVALUE.UPD field is set to YES
 BV.EXCHANGE.RATE Input can be either EOD, ONLINE or OFF
It is used to specify whether BV recalculation process on
Exchange rate will be an EOD process, an ONLINE process or
will be deactivated (OFF).
Input is allowed only if BACKVALUE.UPD field is set to YES
BV.SECURITY.TRANS Input can be either EOD, ONLINE or OFF
It is used to specify whether BV recalculation process on Security
transactions will be an EOD process, an ONLINE process or will
be deactivated (OFF).
Input is allowed only if BACKVALUE.UPD field is set to YES
Note that BV.TRANSACTION fields ( BV.SECURITY.TRANS,
BV.CASH.TRANS, BV.CA.TRANS) are dependant: all those 3 fields
must have the same value: EOD, ONLINE or OFF.
BV.CASH.TRANS Input can be either EOD, ONLINE or OFF
It is used to specify whether BV recalculation process on Cash
will be an EOD process, an ONLINE process or will be
deactivated (OFF).
Input is allowed only if BACKVALUE.UPD field is set to YES
Note that BV.TRANSACTION fields ( BV.SECURITY.TRANS,
BV.CASH.TRANS, BV.CA.TRANS) are dependant: all those 3 fields
must have the same value: EOD, ONLINE or OFF
BV.CA.TRANS Input can be either EOD, ONLINE or OFF
It is used to specify whether BV recalculation process on
Corporate Action will be an EOD process, an ONLINE process or
will be deactivated (OFF).
Input is allowed only if BACKVALUE.UPD field is set to YES
Note that BV.TRANSACTION fields ( BV.SECURITY.TRANS,
BV.CASH.TRANS, BV.CA.TRANS) are dependant: all those 3 fields
must have the same value: EOD, ONLINE or OFF
BV.SELECT.DATE Date from which the Back-value process should start.
When that date is being changed, the new date should be greater
than the last entered date and should be less than TODAY.
Input is allowed only if the BACKVALUE.UPD field is set to YES

BV.REVAL.DATE Date from which the updating should start.

The entered date cannot be less than the BV.SELECT.DATE.
Input is allowed only if the BACKVALUE.UPD field is set to YES
SEC.PRICE.MONTH This field defines the number of months for which the storing of
Backdated price change will be available for Online Back-Value
Price change process.
This period is used for purging concat file
SC.BAK.VAL.PRICE.CHANGE.

Specific consistency controls

Bv Transaction Parameters dependency

BV.TRANSACTION fields, BV.SECURITY.TRANS, BV.CASH.TRANS, BV.CA.TRANS are dependant.

All those three fields must have the same value: EOD, ONLINE or OFF.
This control has been implemented in order to maintain consistency for Back-Value on transactions
including both Security and Cash side. In the case of a back-valued SEC.TRADE for instance, both
security and cash side of the transaction must be recorded in back-value, which would have not
happened in cases where parameters would have been like BV.SECURITY.TRANS=EOD and
BV.CASH.TRANS=OFF.

Bv Transaction Parameters changes

Additionally if the switch is from ONLINE to OFF, the existing BV transactions details will be
cleared , whilst authorising AM.PARAMETER record.

An override message ' Clearing All Back Value transactions references [Yes / No]' will appear.
Selecting option No will not alter parameter record or delete BV.TRANSACTIONS records.

If the switch is from OFF from ONLINE (or EOD) then , all the BV process will start to function
only from the current date.

Back-Value maintenance

Purging of SC.VEH.YYYYMM files

SC.VEH.YYYYMM files are cleared by job SC.VEH.DELETE.FILE.EOM within batch process

SC.VALUATION.EXTRACT.HIST.

This is an end of month job, which is executed only on the last working day of the month (eod).
This job clears all the months prior to a range set with the duration field in AM.PARAMETER