T3TSCO - Securities Back Office - R13 1

T3TSCO - Securities Back Office - R13.
1 1
In this course you will know more on the securities module back office
operations. The objectives are introducing the participants to the T24 Securities
back office in SC module. Learning about linkages with core tables including
tax, interest, charges and commissions
Learning to set up parameter and other tables connected with the module.
Learning to input, execute and complete different types of settlement/corporate
action transactions. Learning about risk management, accounting and
messaging, as appropriate to the back office operations of the module and using
reports and enquiries relevant to the back office operations of the
moduleSecurities Back Office module handling trading in the securities market.
T3TSCO - Securities Back Office - R13.1 2

Under Back office operations the main function is settlement of trade, off
market trades, handling Corporate actions like dividend and coupon payments
on the securities held, maintaining valuation of portfolio of its clients and
handling clients deposits with other institutions. Trading in securities include
buying, selling, transfer between two entities and settlement of the trade done.
Corporate actions like dividends and bonus issue for a share, coupon payments
or redemption of bonds and revision on holdings due to mergers of companies
are handled. Valuation of portfolio of its clients is maintained for calculating
fees due from them to the Bank.
In addition, valuation of own book portfolio with accruals / amortisation of
interest/discount in the case of debt instruments. Revaluation of all securities on
a mark to market basis are also done. This revaluation could happen due to
change in the price or due to changes in exchange rates..

Some of the core applications are integrated with Securities module.
We need to have Customer records to refer the investor, own book, issuer,
broker and depository. We need accounts for payment and receipt into
settlement accounts, broker settlement accounts and NOSTRO accounts.
Delivery messages to the customer for debit/credit of his account, broker for
confirmation of trade and depository for completion of settlement of the trade
are all generated.
Accounting in Securities can be parameterised to handle both trade and value
dated accounting, which is controlled through Accounts module.
Limits can be setup for trading in own book portfolio to check for issuer and
counterparty/broker limits. For this purpose, additional setup needs to be done
in the securities specific parameters.
Other static tables include CURRENCY, COUNTRY,
FT.COMMISSION.TYPE, etc.

The category codes for Securties product is set through SC.PARAMETER table.
For specific transactions, it is possible to set through SC.TRANS.TYPE table.
Default code set up in SC.PARAMETER in Model Bank. Securities does not
have product differentiation using the core CATEGORY table.
Since only one category is used ASSET.TYPE and SUB.ASSET.TYPE table is
used for consolidation and reporting purpose.ASSET.TYPE table which is used
to define and categorise an security or product within a recognised group for
reporting and information purposes.
For example all Ordinary share capital type issues traded on the open market
could be called “Shares ".
SUB.ASSET.TYPE table defines the various asset types into sub classification
and is linked to the ASSET.TYPE. For the purpose of reporting, ranges of sub
assets under an asset type has to be suitably defined . Under Asset type shares
Equity and Prefernce shares are defined as Sub asset types.

Interest bearing debt instruments carry either fixed rate of interest or a floating
rate of interest. In the case of such debt instruments, namely bonds, floating
interests rates is linked through PERIODIC.INTERST table. This table is used
for “LIBOR” type rates of this nature. Rates vary depending on the length of
time and different for Bid and Offer purposes. This table is automatically
updated daily or interfaced with an external feed such Reuters, or maintained
manually by the user.
T24 can process floating rate bonds defined in SECURITY.MASTER where the
coupon rate is typically linked to a benchmark rate such as the LIBOR . The rate
of interest, in such bonds, gets reset at specified intervals, to change with the
movements in the benchmarked rate. There can be option of bid/offer/mid rate
for the bond with or without spread. When the interest payments are 12 i.e.
Monthly and we have specified the BID rate to be chosen with a positive spread
of 5, the system will pick the bid rate corresponding to the REST.PERIOD of
01M, and add the spread of 5 to arrive at the effective interest rate.

There can be different types of charges collected in a securities trade. Some of
the charges are customer related charges, brokerage and stock exchange fees.
All these can be setup in FT.COMMISSION.TYPE and then linked to the
appropriate files setup within the securities module.

In the case of settlement of a trade, details of the cash settlement of the
customer will have to be setup in the portfolio. The accounts attached to a
portfolio is used to identify the account over which the accounting entries for
this portfolios transactions are to be passed. The rules for defaulting of account
numbers for a specific transaction could be set up. If a settlement account is not
available for specific transaction, then defaults first account in the trade
currency mentioned. If account in trade currency not available then defaults first
account of the portfolio. If only a GBP account is entered and customer deals in
USD securities, the system will default to the GBP account and use the standard
exchange conversion rates to convert amount from USD to GBP. However if a
GBP account and USD account stored then for a transaction dealing in USD
securities default will be USD account. If more than 1 account specified for a
currency, say 2 GBP accounts, then the first GBP account will be defaulted for a
transaction of GBP securities. At least one account needs to be linked to the
portfolio. Account must belong to the customer of the portfolio and cannot be
linked to another portfolio.
The default settlement instructions for a broker could be set up through
CUSTOMER.SECURITY. The broker settlement account is generally the
Nostro over which the financial entries are to be posted. Payment can, if
required, be effected over a Vostro ACCOUNT also. To affect a default, you will
have to ensure that there is a record existing for the settlement currency on the
NOSTRO.ACCOUNT file specified for use by the SC application.

In order to default the value date of trade for settlement purposes, holiday setup
is required. Generally the bank’s holiday or country of the stock exchange is
used by system to arrive at the value date of trade.
In the case of coupon or redemption payments for a bond, T24 can
automatically process such events using the Bank holiday. Country specific tax
and region specific tax are set up for calculating at the time of trade
Any security transaction involves the following currencies – security currency
and settlement currencies. When transactions involve different currencies, the
appropriate exchange rate is used from the CURRENCY table. If only a GBP
account is available for a customer and if the trade is in USD securities, the
system will default to the GBP account. The standard exchange conversion rates
to convert amount from USD to GBP is used for the transaction.
Currency in the form of reference currency is used for the purpose of valuation
of the portfolio.
Valuation of portfolio is maintained in 3 currencies namely security currency,
reference currency and local currency.

Different interest day basis for calculation of interest is possible depending on
methods followed for calculating number of days and days in a year.
Type A is where each month is considered to have 30 days for the numerator
and the denominator will also be 360.
Under A3 where each month is assumed to have 30 days, and period varies
according to the start and value dates.
Where D1 = ACCRUAL.START.DATE D2 = the value date for the interest.
If D1 = 31st of a month, then it becomes 30th of the same month.
If D2 = 31st of a month and D1 < 30th of a month, then D2 becomes 1st of the
next month.
If D2 = 31st of a month and D1 >= 30th of a month, then D2 becomes 30th of the
same month.
Under Type B exact number of days will be considered in respect of the
numerator while the denominator will be 360. Method D is that each month is
considered to have 30 days for the numerator while the denominator will be 365
in a non-leap year and 366 in a leap year. E method is where the exact number
of days will be considered in respect of the numerator while the denominator
will be 365. F is the method where each month is considered to have 30 days for
the numerator while the denominator will be on a 365 basis.

3 different methods in C explained in the following slides.

For C basis, Interest for 1 Jan 2008 to 30 June 2008 will have denominator as
366 while for 1 July to 31 Dec it will be 365. When Interest Type in Security
Master is set as C1 366/366, the Interest calculation will be done on the Year of
payment of Interest. If Nominal is 100000, and Interest rate is 6.5% .and
Interest Accrual Start Date = 15-Mar-08, Settlement Date = 15-Dec-08,
Number of Interest days = 275 days
Interest = (100000*6.5%*275)/366 = 4883.88
Denominator is considered as 366 since it is a Leap Year.. When the Interest
Payment is done in 2007. The day basis is considered as 365
Interest Accrual Start Date = 15-Mar-07 Settlement Date = 15-Dec-07, Number
of Interest days = 275 days
Interest = (100000*6.5%*310)/365 = 4897.26
The Interest Type C2 in Security Master provides for calculation of Interest
based on Split Divisor method. Interest Accrual Start Date = 15-Mar-07,
Settlement Date = 15-Mar-08 Interest for the period from 15-Mar-07 till 31-
Dec-07 is based on 366 days . Interest = (100000*6.5%*292)/366 = 5185.79
The Interest calculation for the period from 01-Jan-01 till 15-Mar-01 will be
calculated based on 365 day basis.
Interest = (100000*6.5%*73)/365 = 1300

The total interest under this method is therefore 6485.79.

There is no concept of limits for Customer portfolios. Overdraft limit in the
settlement account of customer is applicable.
However, for transactions in respect of Own Book portfolios there can be 2
types of limit. Restricting exposure towards an issuer of a security and delivery
risk for counterparty or broker is possible. Based on the issuer of security, it is
possible to limit the holdings for the dealer book. The issuer to be specified in
the security definition. A Limit setup for the issuer is done and when a
transaction takes place , own book portfolio defined to update issuer limits.
Each issuer for whom the Bank intends to set issuer limits needs to be defined
on CUSTOMER file since customer number is used as key to issuer limit.
The customer/issuer has to be defined in the security definition and finally the
portfolio has to be flagged to validate with the issuer. Limit can be updated with
the nominals or value which is to be defined in SC.PARAMETER.
Counterparty limit is for setting up trading Limits for each Broker. It depends
on the delivery type of the transaction. For counterparty limit, limit records
should be setup for the broker. In SC.DEL.INSTR table suitable records have to
be setup with COUNTERPARTY.LIMITS as YES. Limits checked for such
transactions of Own book portfolio, using the above delivery instructions with
the Counterparty/Broker. Counterparty limits updated with the value of the
trade.

The Parameter tables to be set-up during implementation are SC.PARAMETER,
SC.STD.POS.TRANSF, SC.STD.CLEARING ,SC.STD.BOND LEND ,
SC.TAX.PARAMETER and DIARY.TYPE

In the case of bonds, the coupon/interest payment dates and maturity/redemption dates
of a bond are available in the SECURITY.MASTER. If the bank wishes to use the
Corporate Actions system to process their coupons and redemptions the fields
COUPON.TYPE and REDEMPTION.TYPE will contain the Id of the DIARY.TYPE
that they will use to process coupon payments or Redemption event. Based on the value
in these fields DIARY records for the events are automatically created during COB.
Further, system will cycle the INT.PAYMENT.DATE field on the
SECURITY.MASTER record for the security concerned when a coupon is processed
for the security.
Core routines are available for the following 4 jobs : 2 for Reports for coupon and
redemption due for payment and 2 more to create the DIARY records for processing of
corporate actions. These are specified in the field JOB.NAME which can be multi
valued for each process. Associated with process there are dates between which the
records should be selected for the above jobs and they are mentioned in the fields
START.DATE and END.DATE for respective jobs. Due dates falling between these
dates will be selected from the SECURITY.MASTER records for interest
payment/redemption as the case may be and processed accordingly. The dates in
SECURITY.MASTER will then be recycled for next interest payment.
SECURITY.MASTER has the tax related field namely COUPON.TAX.CODE linked
to it. This tax can be setup to calculate source tax deducted at the depository and local
tax deducted by the Bank from the customer. It is possible to setup whether these tax
amount should be reflected separately while accounting or a net amount credited to
customer alone should be accounted. When set as YES, Customer will be credited with
the gross amount of cash entitlement and with separate debit entries for the source/local
tax amount.
If SPLIT. COMMISSION and SOURCE.TAX.SPLIT set as YES commission and tax

amount would be posted and shown as accounting entry

In a contractual settlement when a securities transaction is authorised, the
accounting and security positions related to that transaction are updated
immediately, i.e. when the contract is completed settlement can be assumed to
happen on the value date. However, failed settlements are provided for in this
method. In the actual settlement scenario the security positions relating to the
transaction are updated in the normal way but there are new fields added which
hold total unsettled purchases and sales and these are updated only on
confirmation from depository when the stock is delivered/received. The
accounting is not updated until the cash had been paid .
When the field, ACTUAL.SETTLEMENT in the parameter is set to YES, then
Bank has the feature enabled for its operations.
Since accounting to the customer/broker is updated only after cash is
paid/received, the amounts are retained in suspense account which need to be
specified in the parameter. There are 3 categories one for the customer amount,
one for the broker amount and the third for other charges and taxes. These
internal accounts have to opened for the local currency. System will thereafter
open internal accounts in other currencies as and when the transactions
involving such currencies are encountered.

When Actual settlement is set to Yes, it is possible to enable the individual
transaction to go through the process of contractual/actual settlement. For actual
settlement after trade completion, process is continued to another application
namely SC.SETTLEMENT. It is to be parameterised how long such settled
records remain in live before moving to history. SETT.MAT.DAYS field input
the number of days after a SC.SETTLEMENT has been completely settled that
it will be written to history.
Since accounting entries to customer are not raised till settlement of the
transaction, it can be set up to raise F entries to these accounts by inputting
SUP.ACT.FWD.ENT as NO. When defined as YES, it will suppress forward
entries being raised for unsettled transactions.
Setup can be made for specific customers to go through contractual settlement
agreement. In forward value dated trades with actual settlement involving such
customers/brokers, system process the settlement records automatically on the
value date during COB and posts only such customers/brokers transaction alone
as automatic settlement. User will have to input settlement for other
customers/brokers. When SOD.ACCTG is set as ALL, then such processing
takes place at the start of the day’s operation. Inputting nothing in this field will
post the settlement accounting entries during Close of Business

SETTLE.METHOD allows input of value "US". The default value is null. This
is possible only for actual settlement. This field allows differentiation of broker
dues from depository dues.
When a settlement is done, it is possible that the cash inflow/outflow is
marginally less or more than the actual settlement amount. In such cases the
system treats the transaction as unsettled till the amount match exactly. To
overcome such scenarios, it can be mentioned in field OVERPOST.SETT.TOL
with YES/NO. When specified as YES, then unsettled values less than the
settlement tolerance, as defined in each CUSTOMER.SECURITY record for the
depository in respective currency, will be posted to the tolerance category
account or P&L account as mentioned in the field SETT.TOL.CATEG.
However, even when YES is indicated and values are within the tolerance
value, it will not be posted if SETT.TOL.CATEG is not set.
SETT.TOL.CATEG Determines whether the settlement tolerance values will be
posted to an internal account or to P&L. Must be in the range 10000 to 19999
for an internal account or 50000 to 59999 for a P&L category. Unless this field
is set no postings will be made to settlement tolerances accounts or categories.
These will work with the tolerance amount specified for each depository in the
respective CUSTOMER.SECURITY record of the depository.

In the case of a customer having portfolio defined, then for valuations of
assets/liabilities held in other modules of T24, it is required to assign portfolio
for those transactions. Rules for defaulting of portfolio number in transactions
related to other module can be set in the field DEFAULT.SUFFIX . When set as
NO, then no defaulting of portfolio happens in transactions involving other
modules. The field can alternatively hold values of respective application or
ALL to indicate whether the defaulting happens only for specific application or
all applications. In this case the portfolio that gets defaulted is the first portfolio
of the customer. In other instances the portfolio has to be manually input in each
transaction which should be reflected in valuation of a portfolio.
When position of holding of securities is maintained, it is possible to tell the
system to hold position depository wise for each portfolio and security, by
inputting SEP.DEPOSITORY as Y.
Validation Rules

DIV.ACCR.TYPE field is used for defaulting the dividend due from an
ENTITLEMENT between EX.DATE/VALUE.DATE in the valuation
SC.POS.ASSET.
MARGIN.VALUE drives enquiry SC.VAL.MARGIN by selecting items for
inclusion . ASSET means that only assets are included. BOTH or NULL means
that both assets & liabilities are included less margin
RECALC.COST field defines whether the cost of position fields in the
SECURITY.POSITION application will be maintained on a trade date or a value
date basis. If the user enters TRADE.DATE in this field then the
"COST.INVST.SEC.CCY", "COST.INVST.REF.CCY" and
"COST.INVST.BSE.CCY" fields will be maintained in trade date order, whereas
if the user enters VALUE.DATE in this field then they will be maintained in
value date order. If nothing is entered in this field the cost of position will be
maintained in trade date order.

SC.STD.POS.TRANSF table contains company level default values which will
be used when processing POSITION.TRANSFER and SECURITY.TRANSFER
transactions.
These defaults will be applicable irrespective of the transaction type. The user
must create one record for each company on the system

You must must create one record for each company on the system through
SC.STD.CLEARING . Rules of the clearing systems are set here.
SC.STD.BOND.LEND table contains company level default values which will
be used when processing bond lending transactions.
These defaults will be applicable irrespective of the transaction type and you
must create one record for each company on the system.
DIARY.TYPE application will allow you user to set up different types of events
that will be included in the corporate actions/benefits processing suite of
programs. For each event you can specify whether an event will simply pay
cash, issue new securities, consist of a combination of both or allow the user to
pick different options for a particular portfolio

A Bank may charge fees for looking after stock held within a portfolio. These
charges are of safe custody or Depository fees
A Bank may charge portfolio management fees. This include providing
investment advice, order processing, corporate actions administration etc. The
fees are calculated based on the total value of assets in the portfolio.
Safekeeping and management fees are periodic fees charged by the Bank to its
customers and not charged to the Bank by external parties like Brokers,
depositories etc.
Setup of parameters,based on Fees based on customer type and on the security
type

The links between the various files making up the Condition Group structure for
Safekeeping fees is shown here.
For the purpose of Safe keeping fees, we have a record in
CONDITION.PRIORITY with the Id as SC.SAFEKEEPING which defines the
priority rules for grouping of customers. SCSK.GEN.CONDITION describes
the groups based on the priorities defined. When a customer is opened, then
based on the above grouping it is placed in a grouping which is a best fit for the
customer.
Generally priority rules are setup using the CUSTOMER AND ACCOUNT
application. In the case of securities module, priority can be defined using
SEC.ACC.MASTER file also. Hence, when such a rule is defined, then on
opening a portfolio for the customer, grouping is revised by T24 for specific
portfolio.
SCSF.CHARGE.PARAMETER is used to define whether nominals or value is
taken for application of charge in respect of different groupings of securities.
SCSK.GROUP.CONDITION uses the grouping of securities in charge
parameter file and defines the actual fees charge percentage for each group of
customers/portfolios.

The links between the various files making up the Condition Group structure for
Safekeeping fees is shown here.
For the purpose of Safe keeping fees, we have a record in
CONDITION.PRIORITY with the Id as SC.MANAGEMENT which defines
the priority rules for grouping of customers. SCPM.GEN.CONDITION
describes the groups based on the priorities defined. When a customer is
opened, then based on the above grouping it is placed in a grouping which is a
best fit for the customer.
Generally priority rules are setup using the CUSTOMER AND ACCOUNT
application. In the case of securities module, priority can be defined using
SEC.ACC.MASTER file also. Hence, when such a rule is defined, then on
opening a portfolio for the customer, grouping is revised by T24 for specific
portfolio.
SCPM.CHARGE.PARAMETER is used to define whether nominals or value is
taken for application of charge in respect of different groupings of securities.
SCPM.GROUP.CONDITION uses the grouping of securities in charge
parameter file and defines the actual fees charge percentage for each group of
customers/portfolios.

The purpose of this table is to specify, for each Application, which data
elements in the CUSTOMER, ACCOUNT and SEC.ACC.MASTER records are
used to determine Condition groups and which General Condition takes Priority
when more than one of the General Condition requirements are met.
It is possible to define different records for different companies by adding an
optional company to the key.
If there is no specific record for the company being processed, then the overall
one without the company code will be used.
SC.MANAGEMENT, SC.TRADING - SC.SAFEKEEPING
These can be followed by an optional Company code the separation will be a
hyphen.
For securities transaction, the record will be SC.SAFEKEEPING and Id can be
either SC.SAFEKEEPING or SC.SAFEKEEPING -GB 0010001
The user must be very careful when creating and authorising a condition priority
for an Application.

A total of 10 fields can be used for defining the grouping which can be regular
fields or local reference fields from the applications CUSTOMER, ACCOUNT
and SEC.ACC.MASTER. A priority for each can be set. Let us consider a
priority setting as under: MANAGED.ACCOUNT : Priority 1 from
SEC.ACC.MASTER and SECTOR : priority 2 from CUSTOMER
Managed accounts– Group 1, Other Individual – Group 2 and Default group –
group 99.
When a CUSTOMER record is opened for individual customer, it checks the
groupings and fits the customer into group 2. Now when a portfolio for the
customer is opened with managed account, it will identify the portfolio to fall
within group 1 and updates CUSTOMER.CHARGE accordingly as managed
account is of higher priority for grouping. If the priority had been reverse i.e.
Sector 1 and managed account as 2, then portfolio will continue to be in Group
2.
Managed accounts of individual – Group 1, Managed accounts of corporate –
Group 2, Other Individual – Group 3, Other Managed account – Group 4 and
Default group – group 99. When a CUSTOMER record is opened for individual
customer, it checks the groupings and fits the customer into group 3. Now when
a portfolio for the customer is opened with managed account, it will identify the
portfolio to fall within group 1 and updates CUSTOMER.CHARGE
accordingly. If another portfolio is opened for the same customer without

managed account then the second portfolio will continue to be in group 3.

It is possible to effect changes to the selection criteria and/or their ranking
anytime later, if the situation so demands. The effective date has to be current or
future date.
GEN.COND.KEEP will hold the key of the SCTR.GEN.CONDITION records
that are to be kept for the new structure. It is expected that only the default
record will be kept , others will need to be changed. This field can only be
entered for CONDITION.PRIORITY records that have a date in the key.
GROUP.COND.KEEP will hold the key of the SCTR.GROUP.CONDITION
records that are to be kept for the new structure.
As these are the actual charges etc these records may not need to be changed
thus it will be possible to enter ALL otherwise the keys for individual records
will need to be entered. ALL is not allowed along with some other
SCTR.GROUP.CONDITION in the multi valued set.

Lay out of SCSK.GEN.CONDITION and SCPM.GEN.CONDITION is
dependent on the settings made in CONDITION.PRIORITY for
SC.SAFEKEEPING and SC.MANAGEMENT respectively.
Once CONDITION.PRIORITY record for SC.SAFEKEEPING and
SC.MANAGEMENT is authorised, the respective tables get selection values
defaulted in ITEM and PRIORITY fields here
They can be multi valued by indicating Y in MULTIVALUE field to include
any desired combination

A record for each customer will be automatically created whenever a new
Customer record is authorised. Default values for the application charge groups
will be inserted. This is done through CONDITION.PRIORITY file and related
Gen Condition file. The following fields are used for recording group number
for the securities charge applications:-
SC.APPLICATION will contain a pick list for SC.TRADING,
SC.MANAGEMENT and SC.SAFEKEEPING . PORTFOLIO field will have
the value ALL initially and the portfolio number as and when
SEC.ACC.MASTER is opened. The SC.DEF.GROUP and SC.ACT.GROUP
fields will initially be defaulted by system with same value. The
ACTUAL.GROUP may then be updated by the user if he wishes to override the
system default value. In the case of Securities when the CUSTOMER.CHARGE
record is first created the "PORTFOLIO" field will be set to "ALL" as at this
stage no portfolios have been created. This sub-value will then be the default for
all portfolios for that customer. The user may specify special conditions by
creating a new sub-value set and entering the portfolio number and its
associated group. Duplicate portfolios within the same application is not
allowed.
DEPOSITORY.GROUP is used to define the depository charge group in respect
of customers who are defined as depository in CUSTOMER.SECURITY. This
holds the customer depository charge group in the form "NNN" or "C-NNN"

which must be a valid group condition. This is used when calculating safekeeping
charges for the depository..

SCSF.CHARGE.PARAMETER and SCPM.CHARGE.PARAMETER are two
charge related parameter tables. The purpose of this table is to define the rules
for deriving the base amount to be used when calculation charges and
commissions. Different rules may be required for different types of security and
therefore these must be grouped into types for commission purposes.
For maximum flexibility the IDs to this file represent different levels of
classification or type:-
Id format Example DEFAULT "ALL" ALL
ASSET.TYPE A-N to A-NNN A-20
SUB.ASSET.TYPE S-N to S-NNNN S-300
SECURITY NUMBER NNNNNN-NNN 123456-000

In T24, the securities can be grouped by asset type, sub-asset type and security
number with or with out a combination with depository. It is possible to group
the securities for charge scale by FEE.GROUP (T24-Local reference field in the
Security Master file). This is also due to Asset Type, Sub Asset Types are going
to be common for all the locations due to common Security Master File.

the securities for charge scale by FEE GROUP (T24-Local reference field in the

the securities for charge scale by FEE GROUP (T24-Local reference field in the

Each record will define a rule which is used to calculate the base amount for use
in the calculation of commission for that security type. Defines the method of
calculation along with a percentage to be applied . The calculations could be
based on the market value of the securities or nominal. This base codes to be
applied to the value calculated for the specific base code. Valid base codes are
NOMINAL The nominal quantity/value of shares held. VALUE The market
value of shares held. The "HIGHEST.LOWEST" field will determine which of
the base code values will be taken. For example if the "HIGHEST" is entered
then all the defined combinations of values and percentages will be taken and
the highest resultant value will then be used for commission calculations.

It is also possible to define the calculation method as AVERAGE or
MONTH.AVERAGE or CLOSING. Average of closing balances of end of
months or Closing balance as at end of quarter or Weighted average balance for
the period . Or Fee based on previous month closing balance.

For CLOSING option system takes the closing balance of the portfolio during
the end of the calculation period and applies the latest rate. If the custody fees
are debited quarterly and the closing balance is zero at the end of the quarter
then no fees applied even though the positions have been maintained during the
calculation period. For AVERAGE system averages the closing balances at the
end of each month during the calculation period and applies the latest rate.
MONTH.AVERAGE system maintains the daily outstanding positions and
calculates the daily average in a separate daily extract file. During End of the
calculation period latest rates applied to this.

SCSK.GROUP.CONDITION and SCPM.GROUP.CONDITION table defines
the specific charge details for each customer group formed. The following
details are recorded on these two files.
CALC.METHOD field could be "TOTAL" or "DETAIL" .
SEC.TYPE is used to define the levels of calculating the charges within each
activity. The type must exist on the Safekeeping charge parameters.
DET.COMM.TYPE and PERCENTAGE fields are used if calculation type is
detail . Detail Percentage Percentages applied to the charge calculated for each
commission type. A valid FT.COMMISSION.TYPE record is linked.
TOT.COMM.CODE and PERCENT fields are used if calculation type is total.
Percentage applied to the total charge calculated using the Total Commission
Code.

CALC.DEP.CHARGES field is used for applicability of depository charges.
Currency wise minimum and maximum charges and the default currency for
calculation can be used.
Override messages is generated if different accounts not belonging to the

portfolio is input in SAFEKEEP.HOLDING and SC.ADVISORY.CHG
MIN.MAX.CCY field specifies the currency in which the associated minimum

and maximum amount fields are defined. When the Safekeeping charges are
calculated, less any discount amount, a minimum and maximum value can be
specified. This value can be specified in any currency.
MAX.AMOUNT field Specifies the maximum safekeeping charge amount in
the associated MIN.MAX.CCY. MIN.AMOUNT field specifies the minimum
safekeeping charge amount in the associated MIN.MAX.CCY.
DEF.MIN.MAX.CCY field specifies the currency code that will contain the
default minimum / maximum values for safekeeping charges.If the system
cannot find a definition in the currency in which the charges are calculated, the
definitions for this currency will be taken and will be converted at mid-rate to
the charge account currency. For example, if the minimum amount specified is
USD 200 and the fee is payable every quarter, the minimum charge per fee
period will be USD 50. Details of calculated fee will be written to the

SC.ADVISORY.CHG file. The Account Officer of a particular portfolio can review
these fees and post an amount that is below the minimum fee specified or above the
maximum amount. In case daily accrual of fee is required, the accruals will also be
based on these minimum (in case the calculated fee is below the minimum amount) and
maximum (in case the fee calculated is above the maximum amount) amounts and not
based on the calculated amounts.

The system contains functionality that allows you 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 The SAFECUSTODY.VALUES application is used to set-up both
Management Fees and Safe Custody Fees. CHARGE.TYPE field specifies the
type of charges . Only 'SC' (safekeeping charge) or 'IC' (Investment Advisory
charge)
The table is used to specify the top level information including the CATEGORY
to which to post the fees and the transaction codes to use.
MAN.ACC.CALC Field specifies the type of MANAGED.ACCOUNT as
defined on the SEC.ACC.MASTER that will have charges applied to them.

COMPANY.CALC field is a multi-valued field associated with the
CHARGE.TYPE field to indicate whether the fees are calculated on a Company
wide basis or at an individual portfolio basis.COMPANY.POST field multi-
valued field associated with the CHARGE.TYPE field to indicate whether fees
are posted on a Company wide of individual portfolio basis.
If the selection is YES it defaults the frequency values following at SAM, If NO
is opted it allow users to specify charge date for individual SAM.
Specifies the frequency at which the charges will be made. This field consists of
two components as follows -
1) Next Statement Date ie the default value calculated by the system depending
on the frequency. 2) Frequency: 1-5 type SS (uppercase alpha or numeric, first
character alpha) characters.

There are four ranges of calculation type. PERIODIC.OPEN used when the
charges run is an automatic charging run controlled by the ADVISORY.FREQ
field on the SEC.ACC.MASTER record for the portfolio and this is the first
automatic run for the portfolio. PERIODIC.NORMAL is used when the charges
run is an automatic charging controlled by the ADVISORY.FREQ field on the
SEC.ACC.MASTER record for the portfolio and the portfolio has previously
had Advisory Fees calculated for it. CLOSURE.NORMAL is used when the
fees are being calculated because a portfolio is being closed and the portfolio
has previously had Advisory Fees calculated on it. CLOSURE.OPEN option
used when the fees are being calculated because a portfolio is being closed and
the portfolio has never had Advisory Fees calculated on it.
PERIOD.START, PERIOD.END and NO.OF.MONTHS fields allow the user to
specify the number of months in the period for the period type defined in the
associated CALC.TYPE field. This is done using the characters -,+,L,C and O
together with numeric input where; O represents the date of the portfolio
opening. L represents the date of the Last Fees Run. C represents todays system
date
Thus C-1 is the calendar date before today. O+1 is the calendar date after the
opening date of the portfolio.
If the SAFECUSTODY.VALUES field COMPANY.CALC is set to 'Y' this field
is a no input field that will default from SAFECUSTODY.VALUES.

PERFORM.ACCRUAL field is associated with the CHARGE.TYPE .You
should only set this field to MONTHLY if you require monthly accrual of the
fees.
ACCRUAL.CATEG field is the category code of the internal account number
that holds the accrual balance for the safekeeping fees or the portfolio advisory
fees depending on whether it is associated with the CHARGE.TYPE
DEP.CHG.CATEG.CODE field specifies the category code
DEP.CHG.CR.CODE specifies the transaction code to which the Depository
charge is to be posted to be used in respect of Depository charges.
ACCRUAL.CATEG field is the category code of the internal account number
that holds the accrual balance for the safekeeping fees or the portfolio advisory
fees depending on whether
it is associated with the CHARGE.TYPE POST.CHARGES field specifies
whether clients accounts are to be automatically debited with safe custody
charges.
POST.CHARGES field specifies whether clients accounts are to be
automatically debited with safe custody charges.
DEP.CHG.CATEG.CODE field specifies the category code
DEP.CHG.CR.CODE specifies the transaction code to which the Depository
charge is to be posted to be used in respect of Depository charges.

T24 handles different type of processing to capture and complete/settle trading
activity.
It has the facility to capture an order directly or through modeling into an
application SEC.OPEN.ORDER. The order is transmitted to the market to get
the broker quotation of price and availability of security in the market. The
confirmation from the Broker is updated into the file SC.EXE.SEC.ORDERS,
which on completion takes you to the next application SEC.TRADE. It is also
possible to directly capture a trade.
On completion of trade, messages to Broker and Depository are sent. If System
has been set to Actual settlement, then there is need to capture settlement
through another application namely SC.SETTLEMENT.
Off Market trades can also be captured through a different application namely
SECURITY.TRANSFER and position transfers between Customer, portfolios or
depositories are handled by POSITION.TRANSFER in which case no cash
updates will be done. Both these applications also could go through
SC.SETTLEMENT.
Finally all these transactions update the holdings of the investor in the file
SECURITY.POSITION. Open orders, completed trades, unsettled and settled
positions are all maintained in SECURITY.POSITION.

When a securities transaction is authorised accounting and security positions
related to that transaction are updated immediately. This is known as contractual
settlement, i.e. when the contract is completed settlement can be assumed. But
there is provision for both contractual and actual settlement for securities
transactions. In the actual settlement scenario the security positions relating to
the transaction are updated in the normal way but there are new fields added
which hold total unsettled purchases and sales and these are updated when the
stock is delivered. The accounting is not updated until the cash had been paid.
Actual settlement can be switched on by setting the ACTUAL.SETTLEMENT
field on the SC.PARAMETER file to ‘YES’. If the ACTUAL.SETTLEMENT
field on SC.PARAMETER is left blank or set to ‘NO’ you will then continue to
use contractual settlement .
If actual settlement is turned on, actual or contractual settlement is controlled at
a contract level.

Even when the parameter is setup for actual settlement, it is at the transaction
that user can choose the settlement type. The choice can be done for the cash
and securities separately which implies that the respective movements are going
through actual settlement. For example if CASH.HOLD.SETTLE alone is set as
YES, then movement of cash is taken as actual while SEC.HOLD.SETTLE set
as YES implies that securities movement is going through actual settlement. The
type of settlement at the transaction level is s NOCHANGE field. By default
T24 takes the contractual settlement.
Automatic Settlement: Sometimes the Bank may contractually enter into an
agreement with Customers that the Bank Settle the Customers Nominal / Cash
on the Settlement due date irrespective of whether the Broker honours the trade
or not.
Example Mr. Bond calls his Bank and orders the bank to purchase 100 shares of
MICROSOFT. Mr. Bond has an Agreement to automatically Settle on the Value
Date of the trade. In this case the Mr. Bond’s side will be completely settled on
the Value Date.
The Broker side will not be settled Automatically. Broker side has to be settled
manually.

When Actual settlement is set as Yes, then transactions does not stop withy
SEC.TRADE. Authorisation of SEC.TRADE creates a record in
SC.SETTLEMENT with the same Id as the trade. The creation of a record in
SC.SETTLEMENT will be either as a live record ( when one of the parties
involved has a contractual settlement) or with a status FHLD. Settlement can be
input only after the value date of the transaction (irrespective of trade or value
dated accounting). If one of customer/broker has been setup for actual
settlement, then during COB.
SC.SETTLEMENT record contains all the details of the trade and has different
sections for capturing the settlement details from broker/customer. In the case of
multiple broker/customer in a trade, multi value set of fields are available for
input of settlement.
The total nominal for all the brokers for that particular security is summed up
and defaulted in the field TOTAL.NOMINAL. TOTAL.NOMINAL is the same
for brokers and customers hence just the one field. TOTAL.BROKER.AMT
may contain charges/commissions hence making it different from the value in
TOTAL.CUST.AMT.
TRADE.CCY is defaulted by every transaction . TRANS.CODE is the
transaction code used by the customer in the original transaction.
CU.XRATE.ACY is the exchange rate between the account currency and the
trade currency. This is defaulted from the original transaction and cannot be
changed.

For input of settlement of a trade, T24 has the feature to complete settlement
separately for each component – cash and securities, broker and customer with
an effective date of settlement.
The settlement details can be partial or complete and details of cash/securities
need to be given. When nominal settlement mentioned, then positions gets
updated as settled and when cash is settled, accounting gets raised.
A nominal settlement is first entered in the field BR.NOM.RECD.DEL. The
fields TOTAL.NOM.SETTLED (for broker) and NOMINAL.TO.SETTLE (for
customer) are immediately updated with this settlement nominal by adding them
to the existing value in these fields.
Then the user distributes the nominal settled by the broker among the customers
in the field CU.NOM.RECD.DEL. This updates the field NOMINAL.TO
SETTLE by subtracting this nominal from the value in it.
The total nominal distributed among the portfolios cannot exceed the total
nominal settled by the broker i.e. SUM (CU.NOM.RECD.DEL) must be equal
to SUM (BR.NOM.RECD.DEL).
The nominal settled for each customer/broker cannot be greater than the
nominal outstanding for that particular customer/broker i.e.
BR.NOM.RECD.DEL <= BR.NOM.OUTSTAND.
The total nominal settled by the broker has to be completely distributed among
the customer portfolios i.e. at the time of commitment the field NOMINAL.TO
SETTLE must be equal to zero.

The ‘Reveres function is not allowed in the SC.SETTLEMENT application
because it is linked to the original transaction. However, the users are able to
amend the previously authorised SC.SETTLEMENT record by using the Reverse
fields on the file.
A nominal settlement can be reversed using the field BR.REVERSE.NOM. This
updates the fields TOTAL.NOM.REVERSED and NOMINAL.TO.REVERSE.
Now you can reverse the nominal from customer portfolios by using the field
CU.REVERSE.NOM. For a broker, you cannot reverse a nominal greater than
the value in the field BR.NOM.SETTLED. For a customer, you cannot reverse a
nominal greater than the value of the CU.NOM.SETTLED. SUM
(CU.REVERSE.NOM) has to be equal to SUM (BR.REVERSE.NOM). Cash
settlements can be reversed in the same way. Settlement and reversal cannot
take place at the same time.
A settlement record cannot be committed or authorised unless it has a settlement
or reversal taking place in it.
Before reversing a transaction (e.g. SEC.TRADE) with related settlements, it is
advisable to unsettle the settlements (SC.SETTLEMENT) first. Otherwise,
unpredictable results will occur if the reversal is subsequently deleted.

In the case of actual settlement, it is possible for the Bank to enter into an
agreement with their customers for automatic settlement of their transactions. In
such cases, the customer defined in CUSTOMER.SECURITY can be specified
with AUTO.CUST.SETT as Yes. In transactions involving these customers the
customer specific fields will be updated in trade as contractual ie. Settlement is
taken as completed without user input. Similar setup ca\n be done for broker
also,
All Dealer Book Trades are AUTO.CUST set to ‘YES’
In case of Contractual settlement, then SC.SETTLEMENT record replaced by
SEC.DEL.CONTROL record for Broker side ONLY
If the field SEC.HOLD.SETTLE is not set to YES in the original transaction,
then SEC.DEL.CONTROL is updated as usual. But if actual settlement is
requested for stock in the original transaction i.e. SEC.HOLD.SETTLE is set to
YES, then SEC.DEL.CONTROL will not be updated. The user will instead use
the settlement application to perform the actual settlement.

Record are created for handling the settlement of cash/nominal in
SC.SETTLEMENT. If the field CASH.HOLD.SETTLE is set to ‘YES’ in the
original transaction, on committing the record, accounting entries are created in
the SC.SETT.ENTRIES and can be seen using ENQ SC.SETT.ENTRIES. When
the transaction is authorised STMT.ENTRIES are raised for value the next
working day as forward contingent entries in STMT.ENTRY. If not on the actual
value date if transaction have a value date of greater than the next working day.
Once settlement has taken place the contingent entries become real ones.
When the record is committed, the live files SC.SETTLE.CUST and
SC.SETTLE.TXNS are updated. The fields UNSETTLED.NOM.CR and
UNSETTLED.NOM.DR on the relevant SECURITY.POSITION records are
updated. The field UNSETTLED.NOM on the relevant SECURITY.TRANS
records is updated. If the field SEC.HOLD.SETTLE on the original contract is
‘YES’ then when the contract is authorised, the closing balance on the relevant
security position will be updated immediately as usual but will also be flagged
as unsettled for that position by entering that nominal amount in the appropriate
unsettled nominal field, depending on whether the nominal is being credited or
debited. This will continue to appear on the valuation of the customer portfolio
but will not be available to sell or transfer out without the user accepting an
override. When settlement takes place the settled nominal amount is reduced
from the total unsettled nominal amount in the unsettled nominal field.

When CASH.HOLD.SETTLE in a transaction is set to Yes, then on authorising
a trade suspense entries are raised to various internal accounts mentioned in the
parameter or overruled by a setting the broker type of customer
CUSTOMER.SECURITY.
As the cash portion is settled, suspense entries get revered by contra entries and
entries to customer/broker are raise.
When settlement is done partially, then based on the net amount settled, system
takes prorated charges for the settlement.
For example: A customer has purchased securities for a value of USD 15,000
with a charge of USD 300. Now the net amount is USD 15,300. If settlement is
made for USD 10,200, then the settlement will be USD 200 towards charges and
PL entry is raised accordingly.

Trade dated accounting and actual settlement.
Let us take a purchase of a share by individual customer for value of USD
10,000 with a charge of USD200. On the broker side, the value of security is
USD 10,000 with a brokerage of USD 100
On trade date
Customer Suspense account Dr. 10,200
Miscellaneous suspense
for customer charges Cr 200
Broker Suspense Account Cr 10,100
Misc suspense for brokerage Dr 100
Depending on the parameter set up F entries are raised for Customer account
and Broker Nostro account for customer net amount and broker net amount.

Trade dated accounting and actual settlement on settlement.
Let us take a purchase of a bond by individual customer for value of USD
10,000 + interest accrual of USD 200 with a charge of USD200. On the broker
side, the value of security is USD 10,000 + interest of USD 200 with a
brokerage of USD 100
On settlement date
Customer Account Dr. 10,400
P/L account for customer charges Cr 200
Broker Account Cr 10,300
P/L account for brokerage Dr 100
Customer Suspense account Cr. 10,200

Miscellaneous suspense
for customer charges Dr 200
Broker Suspense Account Dr 10,100
Misc suspense for brokerage Cr 100

The category code for posting the difference if any in the settlement is
provided through the SC.PARAMETER table. It could be either a internal
category or a P&L category .In the CUSTOMER.SECURITY table field
OVERPOST.SETT.TOL determines whether an amount exceeding the
tolerance value established can be posted. It is possible to specify tolerance
amount for specific currency in the depository record of
CUSTOMER.SECURITY. Any application that creates these types of files can
go through this process and be settled with a cash tolerance. Deals with the
broker / depository (in the case of corporate action processing) settlement cash
amounts only.

Deals with the broker / depository settlement cash amounts only. In case the
broker trade nominal in the SC.SETTLEMENT record is fully settled , which
can be done either manually or from an incoming SWIFT and the cash amount
settled is not equal to the amount outstanding, but is within the tolerance
specified (+/-), the transaction will be considered as fully settled. The
difference between the amount due and amount settled will be posted to the
tolerance category account specified in field SETT.TOL.CATEG in
SC.PARAMETER.
There is no provision for tolerances on the customer side of the transaction.

In a value dated accounting setup and when automatic settlement is set as YES
accounting takes place as follows.
For a transaction with value date that is less than or equal to today, then the
settlement takes place online.

There are enquires available to view the holding of the customer.
Positions by Portfolio needs a portfolio number and gives details of the
positions held by the portfolio, security wise.
Positions by Security needs selection of the underlying security and gives the
list of all portfolios which have a holding in the selected security.
Positions by Depository gives the positions with a Depository for each portfolio
security wise.
During Close of Business, three different reports are generated by the system.
The first report is the list of pending orders.
The second report is about orders which have been executed and the third report
is the orders which have expired and hence could be purged.
Other reports are available showing depot positions, unsettled trades, daily trade
activity, inventory (trading positions) etc, or can be user defined and included in
COB .

SC.SETT.ENTRIES is available for unauthorised for accounting entries for the
outstanding unsettled positions. SC.UNSETTLED is a detailed enquiry for each
unsettled transaction. It can be drilled down from SC.UNSETTELD.CUST
which gives details of unsettled transactions by customer.
All unsettled transactions can be got from SC.UNSETTELED.RPT report.

SECURITY.TRANS table holds all transaction details. For a trade/transfer
created when the records are in INAU. For position transfer/diary/ entitlement
created only when authorised.
This file will contain Transaction by transaction track down of UNSETTLED
Nominal’s.
In SECURITY.POSITION table the fields UNSETTLED.NOM.CR and
UNSETTLED.NOM.DR will mention the total nominal unsettled.
It holds cost of position in various components/currencies, position for a
portfolio by security and depository , the settled and unsettled details, holds
Repo/ reso position, holds securities lent position and also holds the details of
blocked securities.

SC.TRADING.POSITION table holds the position details for Own Book
portfolios ,It holds details of accrual and amortisation .
SC.TRADE.POS.HISTORY holds historic details of SC.TRADING.POSITION
held monthly
SC.TRANS.POS.HISTORY holds historic transaction details that build to
SC.TRADING.POSITION table .

The SECURITY.TRANS record is a live file which will record the broker /
counterparty transaction values instead of depository on completion of the
transaction. The SECURITY.TRANS record for the depository will be created
when settlement happens in the SC.SETTLEMENT record simulating securities
settled by broker to depository. The Id is same as the transaction suffixed by a
serial number. Generally 2 one for the customer and another for the depository.
Under US settlement three records are created
The Gross and net amount in security and trade currency.
The table holds the information to be used for valuation purpose in three
currencies ie security, reference and local currency.

SECURITY.TRANS table hold details in three currencies.
COST.INVS.BASE.CCY , COST.INVST.REF.CCY and
COST.INVST.SEC.CCY Field holds the gross amount together with the charges
in the three currencies.
GROSS.COST.BSE.CCY , GROSS.COST.REF.CCY GROSS.COST.SEC.CCY
Fields holds the gross amount.
GROSS.COST.BSE.CCY , GROSS.COST.REF.CCY GROSS.COST.SEC.CCY
Fields holds the gross amount.

BOOK.COST.BSE.CCY, BOOK.COST.REF.CCY, BOOK.COST.SEC.CCY
Fields contains the net cost of the transactions
GR.BK.COST.BSE.CCY, GR.BK.COST.REF.CCY, GR.BK.COST.SEC.CCY
Fields contains the gross cost of the security transaction in the security
All the amounts are with a sign. A negative sign for debit and positive for a
credit to the position.

The latest security positional details are stored in SECURITY.POSITION table.
This cannot be modified except by one of the security transactions described
above or by the addition of new securities following certain corporate actions.
A position will exist for every client / security combination, whether the
underlying position belongs to the own portfolio or his customers. The file
stores positions in both Average Purchase Price and Weighted Average Price
Basis. The key to this table is quite complex as it is a T24 live file. It can be
broken down into the following components:
PORTFOLIO, SECURITY, DEPOSITORY, NOMINEE, MATURITY DATE,
RATE and SUB.ACCOUNT . Normally the first four is used.
There will be no SECURITY.POSITION records for broker / counterparty.
When an order to buy or sell securities is in the system it updates the field
NET.OPEN.ORD.POS on the SECURITY.POSITION record relevant to the
order. This process is controlled by the field UPD.OUTST.ORD.CRED on
SC.STD.SEC.TRADE. If the field UPD.OUTST.ORD.CRED is ‘NO’ then the
field NET.OPEN.ORD.POS is only updated by orders that debit securities (i.e. a
sell order). When a SEC.OPEN.ORDER is authorised the
NET.OPEN.ORD.POS field is updated on the SECURITY.POSITION record
relevant to the order. So for example if it is a sell order for 1000 shares this field
will be updated with +1000. If it is a buy order then, provided the field
UPD.OUTST.ORD.CRED is set to ‘Y’ on SC.STD.SEC.TRADE, then this field

will be updated with -1000.

SECURITY.POSITION table hold details in three currencies Security currency
,Reference Currency and Local currency .Cost investment details hold the cost
of closing nominal at average cost. Purchase cost taken for average cost .
COST.INVST.BSE.CCY field holds the cost of the security position identified
in the CLOSING.BAL.NO.NOM field in the local currency of the T24 system.
COST.INVST.REF.CCY field holds the cost of the security position identified in
the CLOSING.BAL.NO.NOM field in the reference currency of the portfolio
identified in the SECURITY.ACCOUNT field of this record. Exchange rates
used will be as of the individual transaction that have built this security position.
COST.INVST.SEC.CCY This is the cost of the security position identified in the
CLOSING.BAL.NO.NOM field in the Security Currency of the security
identified in the SECURITY.NUMBER field of the SECURITY.POSITION
record. Exchange rates used will be as of the individual transaction that have
built this security position.
GROSS.COST.BSE.CCY field holds the gross cost of the security position - i.e.
the cost before charges, commissions, taxes etc. have been applied - in the local
currency of the system. GROSS.COST.REF.CCY holds the gross cost of the
security position in the reference currency of the portfolio identified in the
SECURITY.ACCOUNT field of the record. GROSS.COST.SEC.CCY Field
holds the gross cost of the security position in the security currency of the
security identified in the SECURITY.NUMBER field of the record.

Book cost holds the total cost details including sale transactions.
BOOK.COST.BSE.CCY field contains the total weighted cost of the security
position in the local currency. BOOK.COST.REF.CCY field contains the total
weighted cost of the security position in the reference currency of the
underlying portfolio. BOOK.COST.SEC.CCY field contains the total weighted
cost of the security position in the security currency.
GR.BK.COST.BSE.CCY field contains the total gross weighted cost of the
security position in local currency
The gross weighted cost is calculated ignoring the impact of commissions,
charges and taxes etc
GR.BK.COST.REF.CCY field contains the total gross weighted cost of the
security position in the reference currency of the portfolio.
GR.BK.COST.SEC.CCY field contains the total gross weighted cost of the
security position in the security currency.
Value dated position/ cost holds total cost investment as on date excluding
forward trades.
Value dated book cost holds total book cost as on date excluding forward trades.

VALUE.DATED.POSN field is the value dated security position. The field
contains the value dated number of securities held by the Security Position. This
field is normally only updated during Batch processing and is not updated
online unless a portfolio valuation is requested for the SEC.ACC.MASTER.
This field is used to update the V.DATE.NOMINAL field on the
SC.POS.ASSET file and hence is used as the number of securities held as at the
value date.
VALUE.DATED.COST This field is the value dated cost of the position
identified in the VALUE.DATE.POSN field in the security currency of the
security identified in the SECURITY.NUMBER field.
VALUE.DAT.COST.BSE No Input field showing the value dated cost of the
position in the base currency of the system. VALUE.DAT.COST.REF No Input
field showing the value dated cost of the position in the reference currency of
the portfolio identified in the SECURITY.ACCOUNT field.
VAL.DAT.BKCOST.BSE field contains the total gross weighted cost of the
value dated security position in local currency
The gross weighted cost is calculated ignoring the impact of commissions,
charges and taxes etc VAL.DAT.BKCOST.REF field contains the total gross
weighted cost of the value dated security position in the reference currency of
the portfolio. VAL.DAT.BOOK.COST field contains the total gross weighted
cost of the value dated security position in the security currency

The unsettled nominal are held broker wise.
UNSETTLED.NOM.CR Field holds the nominal of securities relating to this
security position that remains unreceived
UNSETTLED.NOM.DR Field holds the nominal of securities relating to this
security position that remains undelivered.
BLOCK.EFF.FROM field shows the dates when the next change in blocking
value will occur.
NEW.BLOCK.AMT field shows the amount that the existing block will be
effected by when the next change in blocking value will occur. If a
NEW.BLOCK.AMT is positive then the block will be increased by this amount.
If a NEW.BLOCK.AMT is negative then the block will be reduced by this
amount. This field is updated when an SC.BLOCK.SEC.POS record is
authorised & it has an EFF.FROM.DATE later than the system date or an
EFF.TO.DATE.
NO.NOM.BOND.LENT field will show the number of securities in the security
position currently lent. Part - or all - of a Security Position can be lent using the
application BOND.LENT.MASTER. This
REPO.NOMINAL Field holds the amount of nominal that has been lent from
this position. RESO.NOMINAL Field holds the amount of nominal that has
been borrowed for this position.

From the trade transaction details are captured in SECURITY.TRANS. When
the original trade transaction is authorised, SECURITY.TRANS records are
created for all the files updated by it. If actual settlement has been turned on for
that transaction, the field UNSETTLED.NOMINAL is updated by the nominal
amount involved in the updating. When settlement takes place the settled
nominal amount is reduced from the total unsettled nominal amount in the
unsettled nominal field. The SECURITY.POSITION table is also updated.

unsettled nominal field. The SECURITY.POSITION table is also updated.

unsettled nominal field. The SECURITY.POSITION table is also updated. After
running the COB the value dated details get updated.

SC.TRADING.POSITION is a live file containing additional information to
that contained in the SECURITY.POSITION.
In this table , the component records relate only to own portfolios. The
information is selected by book and security and kept updated whenever a
security is traded.
It provide such information as realised and unrealised trading profit and loss
details.
Details relating to the Trading Position of each security are recorded within this
file. After COB is run various balances are updated. Asset balances, contingent
asset balance and contingent interest accrual details are updated.
As well as storing individual trading statistics, this table is used to provide the
data for Enquiry records and reports.
This table is used to provide up-to-date information to the Enquiry
SC.TRADE.POS that you can use to supply with holdings and performance
details of security positions including the latest unrealised P/L details. This is
based on the latest prices available.

DAILY COUPON ACCRUALS
DB: Interest Earned Not Collected I.E.N.C Interest Receivable
Asset Account (RE.CONSOL.SPEC.ENTRY) with Interest to Post.
CR: Interest Received Category (CATEG.ENTRY)
with Interest to Post When a month-end is involved, the procedure differs in the
way that daily accruals processing will be performed on a daily basis up to the
last calendar day of the month and not up to the day before the next working
day. In the Start of Day process of the next working day, all remaining accruals
up to the day before the next working day will be posted with the consolidation
posting's occurring as the first job in the End of Day processing. The following
example illustrates the accrual process when a month end is involved:
Fri Sat Sun Mon
30 31 1 2
On Friday 30th EOD accrual process will generate only 2 accrual entries
i.e. the 30 and 31 only. On Monday 2nd Start of Day
DB/CR: Profit and Loss interest entry
(CATEG.ENTRY) for the lst. On Monday 2nd End of Day
DB/CR: Special consolidation entry for the 1st
and normal End of Day of the 2nd.

YIELD.TO.MAT field will display a Yield for the security position based upon
the general formula of
CUR.COST.POSITION = CF1/(1+r) + CF2/(1+r)**2 + ... + CFn/(1+r)**n
Where; r = Yield CFn = Income during period n n = number of days since trade
divided by number of days in year. The yield will then be found by iteration.
AVERAGE.YIELD field will display an Average Yield which is derived from
the yields on the transactions. The system will use the average price concept to
derive the average yield of the position.
The rules are as follows: 1. If position changes from 'long to short' or 'short to
long' then use the yield on the new trade; else 2. if 'buy on short' or 'sell on long'
then use the current average yield on the position; 3. otherwise work out the
new average yield by using the true cost of position where true cost of pos =
value dated cost of pos - discount provision

REVAL.UNREAL.P.LCY Field specifies the amount of the Revalued
Unrealized Profit/Loss in the Local Currency.
REVAL.UNREAL.PL Field specifies the amount of the Revalued Unrealized
Profit/Loss.
REVALUATION.DATE specifies the Date of the last Revaluation.
REVALUATION.PRICE field holds the lowest recorded market price for the
security of this holding. The field is cleared if the nominal of the holding is
returned to zero.It is used for the revaluation of dealer books that have the
POST.UNREAL.PL field set to RVAL.
When the sale is completed then realised PL is booked.
COB transactions STP.ORG Transaction Id of transaction input during COB

Step 1 A purchase trade input on 4th Dec with value date on 15th Dec for a bond
to a dealer book at a price 99 $
Interest at 6.173 for 66 days from 10 Oct to 15 Dec resulting to 111.62$
Step 2 After COB taking the date to 15th, a sale of 7000 nominal input with
value date as 15th Dec at a price of 101$
Market price is 99.75
After another COB, the related position files are….
Interest on purchase = 111.62
Interest on the sale = 78.13
Interest on the balance (as on 15/12) is 33.49
Interest accrual from 15/12 to 21/12. the next working day = 3.55 ( shown in the
STP record on a daily basis
Total coupon accrual is 33.49+3.55 = 37.04

SC.TRADE.POS.HISTORY table holds historic position of SC.TRADING.
POSITION records. The Id is STP Id concatenated with YYYYMM where Y is
year and M is month.
The daily details are maintained in each multi value set. The details of
cumulative accruals and daily accruals are held in the record.
Value dated and currency position as on each date is held in this table.

SC.TRANS.POS.HISTORY holds historic position of all the transactions details
which form the position in STP. All details available in STP during ONLINE
updation under transaction moves into the above file.
CONT.REAL.PL field represents the value of the Contingent Realised P/L in
the Trade Currency. This field will be recycled everyday as and when a P/L are
realised.

The SECURITY.TRANSFER transaction enables the free transfer of securities
into or out of a portfolio.
The transfer may be against payment or free of payment. It allows both security
and financial update. The customer, broker and depository advice are generated.
It is particularly useful in two very important cases:
The initial setting up of positions on a newly delivered T24 System, i.e at the
time of take over from a Legacy system.
In cases when customers, for whom the T24 user maintains custody operations,
either BUY from or SELL to third parties directly.
It may also be used to transfer securities in or out where a Banks Client has
dealt direct with a broker and has asked you (the Bank) to settle the transaction
on his/her behalf. This is sometimes referred to as Third Party Deals.

Transaction between the customer on one side and a broker, counterparty or
client on the other side. The charges for the transfer get defaulted from the
SCTR.GROUP.CONDITION for the customer. The security transfer could be
contractual or actual settlement.
Is a transaction used within the securities Module to transfer securities in or out
of a Clients' Portfolio Account. The Security concerned may be delivered in or
out either against payment or free of payment.
In common with the Security Trade application it allows both Security and
Financial updates as well as producing Client Broker and Depository advices
where necessary.

POSITION.TRANSFER transaction will enable the user to transfer one or all
securities from one portfolio account to another or from one Depository
Account to another. It is also possible to specify a particular Customer and or a
certain nominal amount only which needs to be transferred.
It may be used therefore as an internal transfer of a security between a Banks'
Customers, where positions will be automatically updated. It is used to transfer
some or all Positions from one portfolio to another belonging to the same
CUSTOMER.
Transfer some or all Positions from one portfolio to another belonging to
another CUSTOMER, subject to override.
Transfer some or all Positions belonging to one portfolio from one depository to
another.
Transfer some or all Positions to a CUSTOMER having more than one portfolio
from one depository to another.
Transfer between depositories, between nominee accounts and between sub
accounts are possible
Where the user is changing Depositories it will instruct the Old Depository To
transfer one or all Securities to the New Depository.
SECURITY.TRANSFER differs from the POSITION.TRANSFER in that it
allows the transfer of a specified number of share type securities or a nominal

amount bond type paper. The POSITION.TRANSFER, on the other hand, is used to
effect the movement of an entire position from one location to another.

If AUTO.SELECT field is set as Y then the positions for transfer are displayed
with options of changing any of the details of transfer. The multi valued fields
the required security may be selected. The number of nominal can also be
chosen depending upon the transaction.
Transfer some or all Positions from one portfolio to another belonging to the
same CUSTOMER., from one portfolio to another belonging to another
CUSTOMER, one portfolio from one depository to another, Positions to a
CUSTOMER having more than one portfolio from one depository to another.
Since there is no cash transfer involved and mere transfer of positions. Only
SEC.HOLD.SETTLE field is applicable.

Valuation of the portfolio could be run manually online or done as batch run
automatically. System initiated valuation is done as part of COB.
Valuation of portfolio of its clients is maintained for calculating fees due from
them to the Bank, performance and modelling of portfolio which are handled by
the Asset Management module. The details are available portfolio wise . Further
it is possible to get details asset type wise, sub asset type wise date wise.
In addition to valuation of own book portfolio, interest /discount accruals and
amortisation of interest/discount in the case of debt instruments are done.
Interest and discount accrued for valuation purpose, capitalisation of interest.
For own book revaluation of all securities on a mark to market basis are done.
This could be due to the changes in market price, currency exchange rates and at
the time of sale of securities.

There are two valuation enquiries
Enquiry SC.VAL.COST can be run giving the portfolio no. Can be specified
with online valuation as YES/NO to do online valuation
Enquiry SC.VAL.MARGIN is used to look at margin valuations. Once the
valuation has been completed in the above enquiry, then margin enquiry will
contain all the details with margin information for each security.

SC.POS.ASSET is the main file built from SECURITY.POSITION for the
security transactions . The table gets built for the valuation of other modules
with which interfaced . This is handled in detail in ASSET MANAGEMENT
Valuation. Interface to other modules is setup in the ASSET.TYPE record. The
suffix of the default portfolio is available in SC.PARAMETER. When online
valuation is run, the file gets built up. This is also run during COB. The Id of
the record will be <portfolio.id>.<sub.asset.type>.<asset.type>
SC.POS.ASSET.WHILE.COB table holds SC.POS.ASSET details when
valuation is run during COB.

For own book portfolio marked to market valuation of the position with respect
to the market price fluctuations or exchange rate fluctuations. The accounting
entries of the revaluation and position updates are done during revaluation
process.

Revaluation is booking of unrealised profit or loss based on the cost of the
securities. This is marking to the market.
If unrealised Profit the accounting entries are generated as
Debit Internal account and Credit Unrealised Profit Category
(CATEG.ENTRY)
with Unrealised Profit.
If Unrealised Loss then debit unrealised loss Category (CATEG.ENTRY)
and credit Internal account with Unrealised Loss.
Revaluation is done only for own book portfolio.
POST.UNREAL.PROFIT field in SC.STD.SEC.TRADE table controls
whether or not unrealised profit from Dealer Book portfolios is posted to the
loss provision category or not..
Other rules regarding revaluation are provided through SEC.ACC.MASTER for
each portfolio.
The price for revaluation is obtained from price field from
SECURITY.MASTER. The average cost of the securities are calculated using
the purchase price. Portfolio POST.UNREAL.PL Field defines whether post
unrealised profits and/or loss for this portfolio are to be posted

IAS39 specifies that available for sale portfolios must book unrealised
revaluation figures on equity, not on P&L. At SEC.ACC.MASTER level we
can currently define if we wish to revalue the portfolio or not, and we can
determine what category to use for the booking. This category is not
changeable.
For IAS39 we need to expand this so that revaluation figures (unrealised P&L)
can be booked on equity.
We must ensure that if the Bank changes the parameters for a particular
portfolio from EQUITY to P&L and vice versa, the unrealised P&L is reversed
from the original category/account/line and re-booked to the new one. This
change does not affect realised P&L.
Fields UNREAL.CAT.PRF and UNREAL.PL.CAT.LOSS would now accept
internal account category (category code range 10000 – 18999) also apart from
P/L category range.

For example a SAM record is set with revaluation as YES, daily frequency.
If the transactions input as a purchase transaction of 3000 nominal at 99 when
the market price as 99.75.
After COB, entries are updated as under.Unrealised profit of 22.5 credited to
category defined as Unrealised profit category
The same amount is debited to the internal account defined under Unrealised
profit provision of SAM record. Calculation is 3000*(99.75-99)/100 = 22.50
(profit)
In the case of a portfolio type as AVAIL.SALE (defined in the SAM record), it is
possible to specify the internal account category

On the next day when the price moves to 99.9, then after COB, the revaluation
will be as under
Revised revaluation profit is 3000*(99.9-99)/100 = 27$
If Reval method is ADJ,
The entries raised only for the difference (27-22.5) = 4.5
If Reval method is I/O,
The earlier entries are reversed as debit to profit category with credit to
internal account of 22.50
A fresh entry is raised for 27 by credit to profit category & debit to the
internal account

BOOKING OF REALISED PROFIT/LOSS
If Realised Profit DB: Special Entry (RE.CONSOL.SPEC.ENTRY)
Asset Account with Realised Profit.CR: Realised Profit Category
(CATEG.ENTRY) with Realised Profit.
If Realised Loss Debit Realised Profit Category (CATEG.ENTRY)
with Realised Loss Credit Special Entry (RE.CONSOL.SPEC.ENTRY)
Asset Account with Realised Loss.

Corporate actions for a security position could involve only cash, only stock or a
combination of both. Cash option for a share include dividend payment, while it
is coupon payment for debt instruments. Stock options include bonus payment,
rights etc. When ever a takeover or merger happens there is possibility of
combination of both cash as well as stock options.
For a particular type of corporate actions the specified event can be defined for
a security..
Based on the security for which the event has been included, and based on the
holdings entitlements are created for each portfolio.

When a publicly-traded company issues a corporate action, it is initiating a
process that will bring actual change to its stock. By understanding these
different types of processes and their effects, an investor can have a clearer
picture of what a corporate action indicates about a company's financial affairs
and how that action will influence the company's share price and performance.
This knowledge, in turn, will aid the investor in determining whether to buy or
sell the stock in question. Examples of corporate actions includes dividends,
coupons, redemption, bonus, take over and rights.

Any event which brings material change to a stock is a Corporate actions.
Parameter setup for defining the characteristics of each event of corporate action
Different types – RIGHTS,COUPON,DIVIDEND, etc to be done .
The declaration of the event is captured either manually or through external
feed . Creates the entitlements of the portfolio based on the holding as on a
particular date Options to be exercised by the portfolios

Corporate actions processing using service agents
Contractual or actual settlement is possible for corporate actions. It may involve
receipt of cash or security from the depository.
Based on the event, security position are updated
Events could be gross or net of Tax . For event it should be parameterised. Tax
setup based on the customer residence/status

Delivery message are generated to the depository .
Actual settlement is linked to the SC.SETTLEMENT file for actual settlement.
Appropriate accounting entries are generated and position updated
Specific rounding of nominal and handling of short position handled.
COB Processing for fixed events namely coupon/redemption can be included in
parameter for processing during COB

This application will allow user to set up different types of events that will be
included in the corporate actions/benefits processing suite of programs. In this
application, for each event user can specify whether an event will simply pay
cash, issue new securities, consist of a combination of both or allow the user to
pick different options for a particular portfolio
CASH field to indicate whether cash is payable on type of the DIARY event
which is being defined. For example when dividend is announced there is a
certain percentage of cash payout .
SECURITY.UPDATE field to indicate whether there can be a change in the
Security holdings of the portfolios as a result of the diary event which is being
defined. For example the security is updated in a bouus or rights issue.

REINVEST field to indicate whether any cash offered can be reinvested in the
original security. This flag should be set to 'Y' if the Corporate Action being
defined is a re-investment corporate action. That is one where the dividend (or
coupon) received from the holding of a particular security is reinvested in that
security. The resultant ENTITLEMENT records will calculate the amount to be
received by the portfolio and the number of securities that can be purchased
with that amount of cash at the current market price of the security from the
SECURITY.MASTER record that defines the security.
OPTIONS field to indicate whether multiple options are offered to portfolios as
a result of the event which is being defined. If this field is set to 'Y' then
ENTITLEMENT records will always be created on hold and the user will have
to indicate which option the particular portfolio is going to take before the
system will allow validation of the ENTITLEMENT record.
NEW.SECURITIES field to indicate whether the new securities offered by the
diary event which is being defined can be different from the originating security

RETAIN.ORIGINAL field is used to indicate whether the portfolios retain their
original holding once the diary event being defined executed. If this flag is set to
'NO' then the original holding will be backed out as a result of the Corporate
Action. For example a Bond Redemption should set this flag to 'NO'. If a partial
removal of the original holding is required (i.e. in a partial redemption) the
RETAIN.NOMINAL field on the ENTITLEMENT application should be used
in indicate that part of the holding unaffected by the Corporate Action.
FREE.SECURITIES field to indicate whether any free securities are offered by
the diary event which is being defined. If this field is set to 'NO' and there are
securities credited to the portfolio then T24will assume there is a price
associated with them. For example this should be set to 'Y' for a Bonus or a
Stock Dividend Corporate Action and 'N' for a Call Payment or Warrant
Conversion. RIGHTS field to indicate whether any securities will be issued by
the diary event being defined. If the field is set to 'Y' then the Corporate Actions
being defined in the DIARY.TYPE record is a Rights type Corporate Action.
That is holding a particular security on the Ex Div Date will result in the
portfolio being credited with a number of tradable items which can then be
bought or sold up to the Pay Date of the Event. On the Pay Date of the Event the
Rights will be converted to another security - usually at a fixed cost per right. If
this field is set to 'Y' then for the period between ex-div date and pay date any
SEC.TRADE or SECURITY.TRANFER done by a portfolio in the Rights stock
will be recorded on the ENTITLEMENT record in the SEC.TRADE.ID.

COMMISSION.TYPE ID of the default Commission Type to be used while
processing DIARY records. Must exist in FT.COMMISSION.TYPE file
Charges are setup for each event . The charges to be e valid record in
FT.COMMISSION TYPE
The transaction type used for the corporate action event is defined through
SC.TRANS.TYPE table.
Various category are defined for Exchange profit , Re-allowance PL along with
related transaction
EXCHANGE.PL.CAT Specifies the Category Code to be used for the posting of
exchange Profit & Loss entries.
REALLOWANCE.PL.CAT This field is used to specify the profit and loss
category to which reallowance entries will be posted from the DIARY
application.

VERIFY.REQUIRED is a YES/NO field The field used to control whether this
type of Corporate Action needs to be verified. Only input of YES or No is
allowed with the field defaulting to NO. If this field is set to YES then any
ENTITLEMENT record created for this type of Corporate Action will need to
be accessed with the 'V' (Verify) function before input is allowed. If it is NO
then the Entitlement records can be Input or Authorised directly depending on
whether the Entitlement record concerned has enough information to have an
INAU or IHLD status. All the Entitlement records created by a single Diary
record can verified together using the application SC.ENT.VERIFY.
DIARY.CREATE field l control the level at which a DIARY record will be
created for this type of corporate action. Valid input into this field will be 'AUT',
'NAU' or 'HLD' - meaning authorised, unauthorised and hold respectively.
AUTO.ENTITLE field will control whether ENTITLEMENT records are
automatically created when the DIARY is authorised. Valid input will be 'YES'
or 'NO'. The default will be 'NO'.

SUSPENSE.ACCOUNT is a mandatory field allowing the user to input the
category of the suspense account to be updated with postings for the depository
side of accounting entries generated by this corporate action.
An internal account in the local currency must be set-up for this category.
UPDATE.NOSTRO is a YES/NO field controlling whether or not the system
will directly update the Nostro account for the depository side accounting
entries or only the suspense account identified in the SUSPENSE.ACCOUNT
field. If this field is YES then the Nostro Account will be updated. If this field is
NO then the Suspense Account will be updated. Once the DIARY.TYPE record
has been authorised then this field cannot be changed.
FWD.ACCT field controls whether forward entries will be created by this
corporate actions or not. Valid input will be 'YES' or 'NO'. If this field contains
'YES' it cannot be changed to 'NO' or null.

ROUNDING field is used to define the rounding rules . 'DOWN', 'UP',
'STANDARD' and 'FRACTION'. The default will be 'STANDARD‘
DENOM.LEVEL field will control the way in which the conversion is done. If
this field has been set to 'UNIT' then the system will convert the minimum
trading unit first and then round the resulting figure. The resulting rounded
figure will be used in calculating the new nominal figure. If the field has been
set to nulls or 'HOLDING' the conversion will be done on the nominal figure
and the resulting nominal figure will be rounded.

NOM.ROUNDING.METHD field used to specify the rounding rule to be used
in the nominal calculation for the redenomination of the security. The field will
be used in conjunction with the old and new trading units on the old and new
securities.
The possible values in the field are 'UP' for rounding up ; 'DN' for rounding
down ; 'LG' for a legal rounding mechanism ; 'LOT' for LOT Rounding ‘ DEC ’
for the Odd Lots consolidation.
ROUNDING.LEVEL field that will control the level at which the ROUNDING
takes place. This will be an optional field. Valid input will be 'CUSTOMER',
'DEPOSITORY'. The default will be 'CUSTOMER'. At the 'DEPOSITORY'
level, the rounding can be 'STANDARD' or 'DOWN'. The 'STANDARD' option
means a standard adjustment. The 'DOWN' option allows pro-rating the
unallocated securities and cash remaining to customers with fractions.

If LOT is not specified in NOM.ROUNDING, then no odd lots are created and
the system does rounding based on DN, UP, LG and no effect is seen on the
value in ROUNDING

ROUNDING UP DOWN STD UP
DOWN STD
10000 1500 1250/1250 1500/0 1429
1428/4 1429
15000 2250 2000/1000 2250/0
2143 2142/6 2143
20000 3000 2750/750 2750/750 2858
2957/1 2857/1

To decide which ENTITLEMENT records to adjust the system uses the
following criteria:
First the system will adjust those portfolios with the largest delta in the direction
of the rounding.
Where more than one portfolio has the same delta the adjustment will be to the
portfolio with the greatest values in the VALUATION.AMT field in the
SEC.ACC.MASTER file.

SBL.DIV.PROC field will indicate if SBL process is activated or not. Only
input of either YES or NO is allowed.
DRIPS field distinguish DRIP event from other types of corporate events.
Can be set to YES if REINVEST flag is set to YES. This field is only used to
authorise diary without reinvestment price.
CASH.REMAIN is a YES or NO type of field controlling whether the system
will automatically assign any unused entitlement to the cash option of this type
of Corporate Action.
For some types of multiple option corporate actions (such as a SCRIP Dividend)
there will be one - or more - options where the portfolio receives securities and
an equivalent cash option. If this flag is set to YES then the user can select the
option they require and any unused holdings (due to the terms of the offer,
rounding etc.) will automatically be used for the cash equivalent. If this field is
NO then selecting a particular option will cause the system to use all the
holdings on that option, even if there may some part of the holding unused.

BLOCK.POSITION Specifies whether the Security Position is to be blocked by
execution of a corporate action of this type.
If a position is to be blocked it can be blocked either at authorisation of the
DIARY record, i.e. when the unauthorised entitlements are created, or when the
ENTITLEMENT is authorised. BLOCK.POSITION creates a record in
SC.BLOCK.SEC.POS. DIARY, then blocked at unauthorised Entitlement and
released when ENTITLEMENT is authorised. If ENTITLEMENT then blocked
at authorised Entitlement
ALLOW.SHORT.POSN field indicates whether to process the Corporate Events
on Short/Zero Positions or Not

DEF.INSTR.APPLY Field to indicate if default Instructions will be applied on
the ENTITLEMENTS generated with this DIARY.TYPE. Used to define the
number of days prior/after to trade/value date
For any DIARY records created during the running of a COB, based on the
setup in the SC.PARAMETER file to be correctly processed for the fields
CASH.HOLD.SETTLE or SEC.HOLD.SETTLE the field EOD.DEF.ACT.SETT
in DIARY.TYPE has to contain the values “CASH”, “STOCK”, “BOTH” or
null. Based on the value selected by the user in this field, the DIARY records
will be updated accordingly.
.

SBL.DIV.PROC field will indicate if SBL process is activated or not. Only
input of either YES or NO is allowed.
DRIPS field distinguish DRIP event from other types of corporate events.
Can be set to YES if REINVEST flag is set to YES. This field is only used to
authorise diary without reinvestment price.

SC.PRE.DIARY application is used to capture data from external feed. The
SC.PRE.DIARY application is a basic copy of the DIARY application. It is only
used to receive the information from swift messages such as the security
number, the event type, and the depository. SC.CA.PARAMETER should be set
up with Id as DIARY.
If all the data is needed by the DIARY application, the OFS process creates the
DIARY record with the same key as the SC.PRE.DIARY record. The user can
choose the DIARY status in DIARY.TYPE keyed on the event type of the
message as “HLD”, “NAU” or “AUT”. In this last case and if the
AUTO.ENTITLE field of DIARY.TYPE is set to “YES”, the authorisation of
the DIARY record generates the ENTITLEMENT records in the same way as
the online command after checking aggregate nominal.

OFS,SOURCE already set up before the creation of records.
ID – DIARY/ENTITLEMENT/SC.SETTLEMENT . For creation of DIARY
from SC.PRE.DIARY no services required.
ENTITLEMENTs are created from DIARY when services are initiated.
SC.SETTLEMENT for auto authorisation of settlement record for the trade.

For the purpose of using service agents in Corporate actions, the following files
needs to be set up.
For running the service a batch record should exist with no batch stage
mentioned .
Another record is created with the same Id as the BATCH record .
For example SC.CORPORATE.ACTION is a record used for Corporate
Actions.

In a multi company setup XXX is Company Id in batch (I.e. BNK)
SC.ENTITLE.CREATE selects record in the file SC.ENT.WORK with Id
unlike PRICE… which will be the DIARY Id and process the selected
records to create the ENTITLEMENT
SC.ENTITLE.CREATE.POST – selects the record in SC.ENT.WORK.POST
,get the ENTITLEMENT in INAU/IHLD for the DIARY record
SC.DIARY.REVERSAL selects records from SC.DIA.REV.WORK
SC.DIARY.REVERSAL.POST
SC.STOCK.CONV.SETTLE selects records from SC.UNSETTL.TXNS
SC.STOCK.CONV.SETTLE.WORK
SC.ENTITLE.MODIFY – selects records from SC.ENT.WORK with Id like
PRICE…

A record is created in SC.PRE.DIARY .When the same is authorised, then
based on the setup in the file DIARY.TYPE , a record is created in DIARY in
IHLD/LIVE . The level at which the DIARY is created will be controlled by
the new field DIARY.CREATE on the DIARY.TYPE file. This field will
contain ‘HLD’, ‘NAU’ or ‘AUT’ meaning the DIARY record will be created
on hold, in an unauthorised state or in an authorised state respectively. The
OFS process runs for:
- MT550 Notice of rights , MT551 Notice of event
- MT552 Notice of offer or privilege, MT554 Advice of money income
- MT555 Advice of income in the form of securities
- MT556 Advice of redemption
- MT560 Notice of bond or shareholders’ meeting
- MT563 Corporate action confirmation
- MT564 Corporate action notification
- It is used to receive the information from the SWIFT messages such as the
security number, the event type and the depository.
- MT568 Provide complex instructions or narrative details relating to a

corporate action event

T24 handles processing of inbound MT 568 messages. MT 568 is sent by
account servicing institution to the account owner or its designated agent. The
message is used to provide complex instructions or narrative details relating to a
corporate action event.
On receipt of MT 568 message, the system would update the relevant
SC.PRE.DIARY record.This is already created by processing incoming MT 564
message with the narrative details. The narrative details would be updated in the
ADDL.NARRATIVE field in SC.PRE.DIARY. SC.PRE.DIARY record to be
updated would be identified based on the value in LINK.REF field in
SC.PRE.DIARY.
This field would be updated while processing MT 564 message and when a new
MT 568 message is being processed, the reference in the message would be
compared with LINK REF to identify the correct SC PRE DIARY record to be
updated. The system has the capability to handle multiple MT 568 messages for
a single event.
In practice, MT568 messages are sometimes used without a preceding MT564.
On receipt of such messages, T24 will create records in SC.PRE.DIARY and
store all the important fields from the incoming message, particularly the
narrative. However, the processing of corporate events via DIARY and
ENTITLEMENT will not be triggered in this case.

The Id of pre diary record is prefixed by SCPDIA. The details like Security,
Type of event, Ex date of the event, Depository information and the rate or ratio
at which the benefits are applicable are captured.
If all the data is needed by the DIARY application, the OFS process creates the
DIARY record from the SC.PRE.DIARY record. The user can choose the
DIARY status in DIARY.TYPE keyed on the event type of the message as
“HLD”, “NAU” or “AUT”. In this last case and if the AUTO.ENTITLE field of
DIARY.TYPE is set to “YES”, the authorisation of the DIARY will create the
ENTITLEMENT appropriately in IHLD/INAU

DIARY records are created from SC.PRE.DIARY through external feed or
manually directly through the application. If any of the processes attempts to
create a DIARY record that is a duplicate of an existing DIARY record then a
override error message “DIARY EXISTS FOR This EVENT” will be generated
. A DIARY is defined as duplicated if it is for the same security number, same
ex. date and same type of corporate action as one that exists already.. The fields
EVENT.TYPE, SECURITY.NO and EX.DATE are the same as those for a
DIARY record that already exists. The error message is an override message
rather than blocking error message as there are some cases where this is
possible. For example a special dividend is paid on the same day as a periodic
dividend is also paid . If this message is produced for the automated creation of
a DIARY record then the DIARY record will not be produced. During COB the
routines for Coupons/Redemptions to be defined in SC.PARAMETER with start
and end dates .

The Id format is prefixed with DIARSC. The definition of the declaration of the
corporate event are captured. The security details, event, rate , option ,Ex date
and value date are also defined. The details of the security for which the event
has been declared. For example in case of take over the existing securities and
new securities are different and have to be specified separately.

The EVENT is as defined in the DIARY,TYPE table. Based on the definition in
the DIARY.TYPE, we have the following details to be input.
For CASH event option rate is defined.
For STOCK event ratio to be given, price for the new security and the RIGHTS
details
Multiple options when both cash and stock options are applicable.

All Security movements that have a Value Date before the EX.DATE in the
DIARY will be included. All positions where the EX.DATE is less than the
Value Date will be ignored. Entitlements will be generated only when the
EX.DATE is greater than the Value Date. Value date is date on which payment is
due to made
PAY DATE on which payment is made. Typically it is same as value date but
can be different if value date is non business day.
RECORD.DATE Field is optional date field that can be before, after or equal to
EX.DATE. The Record Date of a Corporate Event does not affect the beneficial
entitlement to the event, but does affect the way the event is processed with
regard to who will receive the outcome of an event directly and where the
outcome is due to/from.

The settlement type for the event is defined. Actual settlement or contractual
settlement. In the case of ACTUAL.SETTLEMENT the fields
CASH.HOLD.SETTLE and SEC.HOLD.SETTLE is defined as yes like in the
case of trade.
SC TAX CODE a.nd SC TAX TYPE fields in DIARY have the values defaulted
from SC TAX CODE attached to SECURITY MASTER.
If TAX SOURCE LOCAL is set to SOURCE, then the entries to be raised will
be similar to entries raised for source tax processing in ENTITLEMENT. If set
to LOCAL, then the entries raised will be similar to entries being raised now for
EUSD taxes and local taxes. If the field has a null value, then it will be assumed
to be taxes to be levied locally.
For example if the depository has deducted at source and there are no
adjustments to be made, then the entries will be:
Dr Nostro – Depository net amount 2945
Cr Customer 2915
Dr Flat tax source 1000
Cr Flat tax source 1000
Dr Solidarity tax – Source 55
Cr Solidarity Tax – Source 55

Cr Church tax – Local 30

If the System successfully located any qualifying holdings, then the authorised
DIARY record will contain details of these. The authorised DIARY will contain
the benefits attributable to each option, which will, in turn, be broken down into
depository. To set which depositories are eligible for Corporate Actions
processing input “Y” or “N” as required in the CORPORATE.ACTIONS field
of the CUSTOMER.SECURITY record, for each depository
SC.ENT.WORK gets updated with the DIARY Id to enable the service agent to
process the event.
ENTITLEMENT will be generated when the service agents are initiated
Steps to initiate the service agents are – Initiate the TSM in AUTO mode and the
agent for Corporate action also as AUTO. Now the agents run as phantom and
when the Diary is authorised, ENTITLEMENT records created in INAU/IHLD
depending on the options setup in the corresponding record in DIARY.TYPE

There may be occasions when a DIARY is required to be RERUN.
The rerun may be required when new positions/portfolios are to be included
subsequently. For this the RERUN flag in DIARY should be set to YES. Service
Agents to be initiated to run as done earlier. Revised entitlements are created.
Option is possible only when all ENTITLEMENTS are in IHLD/INAU..

When ENTITLEMENT is created then the following details are written back
into the DIARY.
Number of ENTITLEMENTS created, Depository nominal available for the
event
Depending on the setup of CUSTOMER.SECURITY for depository (Field
corporate.actions as Y/N) the positions are processed
When ENTITLEMENT is authorised, DIARY is updated with Details of
entitlement authorised
Depository options exercised Delivery message sent to the depository Cash
amount due from the depository.

If the AUTO.ENTITLE field is ‘YES’ then the ENTITLEMENT records will be
automatically created once the DIARY record has been authorised. The creation
of the ENTITLEMENT records will follow the rules already established.
Therefore, if there are no options for the corporate action and the
ENTITLEMENT record validates correctly then the ENTITLEMENT will be
created in an unauthorised state.
If a corporate action has options but there are standing instructions telling the
system which option to take then the system will use those standing instructions
to automatically validate the ENTITLEMENT record when it is created. In this
case the ENTITLEMENT record could be created in an unauthorised state even
if the corporate action has options .

VALUE/TRADE DATED POSITION Based on the setup in the DIARY (Field
TRADE.OR.VALUE), all holding before trade or value date is considered for
the event
If the event has multiple options, then ENTITLEMENT record is in IHLD
Exercise one of the options by the customer Multiple options exercised partly
Defaulting account no From the SAM record If the event type has been setup
General for the Currency Finally first account If MEMO account, then suspense
account mentioned in ACCOUNT.CLASS is used.

If DIARY.TYPE is set as verify required, then all records verified individually
or using SC.ENT.VERIFY.
Individual ENTITLEMENT record. can be manually authorised by using the
Authorise Function.
Online bulk authorisation of all the unauthorised ENTITLEMENT records
linked to a DIARY using the existing application SC.ENT.AUTHORISE.
By use of the new start of day process SC.SOD.ENT.AUTH. This process will
be controlled by two new fields on the DIARY.TYPE application. These
fields will be called AUTH.DATE and AUTH.DAYS. Both of these fields
will be optional fields. They will be used to update the AUTH.DATE field
on the ENTITLEMENT record. For example if the AUTH.DATE field on
the DIARY.TYPE record is VALUE.DATE and the AUTH.DAYS field is 2
then the ENTITLEMENT record will be have its AUTH.DATE field updated
with a date 2 working days after the value date. It will be possible to input
zero in the AUTH.DAYS field if authorisation should take place on the
VALUE.DATE for example however it will not be possible to input a
number less than zero into the AUTH.DAYS field. The start of day
authorisation of ENTITLEMENT records will thus work by selecting those
unauthorised ENTITLEMENT records that have been validated but not
authorised (i.e. those unauthorised ENTITLEMENT records with a status of
‘INAU’) with a date in the AUTH.DATE field that is less than or equal the

system date and then authorising them.

When ACTUAL SETTLEMENT has been included in the DIARY, then records
created in SC.SETTLEMENT for each entitlement with the same Id as the
ENTITLEMENT. It Defaults the automatic settlement from the
CUSTOMER.SECURITY
Position updates when a stock movement is the result of an event, then position
updates take place
In such cases a record is created in SECURITY.TRANS for the
ENTITLEMENT with the DIARY Id suffixed with a sequence number
Accounting entry for each authorised cash event of an entitlement are generated
on authorisation

For Bond type securities it is possible to partially automate Coupons and
Redemptions
In the SC.PARAMETER table ,where the from & to dates are defined then
during COB, system identifies all such events falling between these dates.
System, produces a warning report detailing the positions and due amounts per
security to be monitored by Back Office. On due date DIARY record is created
and if the agents are running in AUTO mode, the ENTITLEMENT record gets
created for the holdings. Thereafter standard processing apply SC.ONLINE job
in the ONLINE stage of the batch processing

Individual entitlement can be reversed using the reverse function except the last
one for a Depository Last ENTITLEMENT gets reversed only after reversal of
dairy
To reverse the DIARY record, service agents XXX/SC.CORPORATE
ACTIONS has to be initiated along with TSM
Along with the DIARY the last ENTITLEMENT record also gets reversed

The main types of Corporate Actions are Dividends, Coupon payment,
Redemption, Stock or cash. Bonus, Rights and reinvestment.

Generally a CASH type of Corporate action is used for cash dividend payment.
Setup accordingly in DIARY.TYPE is made with cash update as YES and other
definition fields as NO
The dividend or cash rate per share/bond has to be specified in the DIARY
record.
Gross or Net payment for the event to be specified.
When this type of DIARY is authorised entitlements created for each portfolio
holdings.

Coupons and Redemptions have specific rates and dates defined in the
SECURITY.MASTER.
The rates can be fixed or variable. Processing of coupon and redemption
possible during COB.
For COUPONS the processing is similar to CASH event except that No rates
need to be given. Picks up Coupon rate from the SECURITY.MASTER. Coupon
period calculated from the accrual start and end dates in the
SECURITY.MASTER
If the Bond is being Redeemed in Security Currency then the
Gross Amount = Nominal Redeemed (Total Position or Partial Portion)
* Redemption Percentage Price (Rate on Request Record).
b. If the Bond is not being Redeemed in Security Currency then the
Gross Amount = Nominal Redeemed * Redemption Actual Price

For REDEMPTIONS it is possible to redeem the bond fully or partially by
specifying the nominal to be redeemed.
Redemption price taken to be 100 (par) but can be over-ridden if needed

Based on the rate furnished in the DIARY record the ENTITLEMENT amount
is updated. For partial redemption , the optional nominal to be modified as per
the option exercised

BONUS type of Corporate Actions is used when additional shares are given to
holders on a ratio to existing shares.
CASH is set to NO.
SECURITY.UPDATE is YES
BONUS type of Corporate Actions involves POSITION updates for the
portfolio.

Stock and Cash event Corporate Actions is a combination where beneficial
owner able to receive entitlement as additional securities or cash payment, or a
combination of both.
When the DIARY is created and services run, ENTITLEMENT record is
created in IHLD. This will enable the user to specify the required option per
customer.

It is mandatory to multi value the option field to furnish details of the options.

It is possible for the user to use the ENTITLEMENT application to opt for a
mixture of the two options. For example using 50,000 of the original Abbey
National holding to give 15,000 Lloyds TSB stock and using the remaining
35,000 of the original Abbey National holding to give 17,500.00 GBP if the cash
percentage is 50.
However each ENTITLEMENT record has to be processed individually as it is
not possible to pre-record an option.
The ENTITLEMENT record is created with a status of ‘IHLD’. This is because
until the options are selected it is not possible to calculate any commissions and
taxes that the portfolio may be subject to until the decision concerning the
corporate action has been made.
If the option description is chosen for only one option, then the entire nominal is
exercised as single option.
It is possible to retain a portion of the nominal without exercise.

Initially holder given “rights to new shares” in a ratio to his existing position,
usually at a fixed cost and at future date
The rights can then be exercised, sold or more rights bought to increase
entitlement (use SEC.TRADE)
“Rights” will have to be defined as a separate security in SECURITY.MASTER
where the field RIGHTS is set as YES
In the DIARY record, the rights ratio together with the rights security and ratio
of new shares must be furnished
When a DIARY is authorized the record in ENTITLEMENT is created in the
LIVE file with the opt status as PENDING. Next, the ENTITLEMENT record
has to be input with the option and finally authorized to complete the exercise
the rights option for the portfolio.

ENTITLEMENT record created in the LIVE file with opt status as “pending”
with the security position for the rights security updated. T24 creates with 2
options, one for the rights and other for lapsing the rights.
Now the rights have to be exercised in the ENTITLEMENT when the record
moves to INAU. ENTITLEMENT record has the opt status updated as
COMPLETED
Authorise the ENTITLEMENT. Position in rights security becomes zero, and
the new share position is updated

BR.RIGHTS.NOM field is the equivalent to BR.OUTS.NOM field and will
hold the Broker/Counterparty Outstanding Nominal corresponding to individual
transactions with respect to Rights Security under the associated multi value
field BROKER.TXN.ID field .
DEPOT.HOLDING field will reflect the effect that the position has on the
Depository, a negative figure will be produced when the Portfolio has caused a
shortage at the Depot and a positive figure will be produced when the Portfolio
holds stock in the Depot.The field will be calculated as the
QUALIFY.HOLDING - outstanding credit transactions + outstanding debit
transactions + non-returned settled stock borrows - non-returned settled stock
lent.

RIGHTS.NOM Field is the equivalent to OUTSTAND.NOM and will hold the
outstanding nominal from the Broker/Counterparty with respect to Rights
Security under the associated multi value field BROKER.NO. This field will be
updated only if field SETTLE.METHOD in SC.PARAMETER is set to “US”.
The Rights security which is traded externally from the market need to be
always treated as Contractual and added or reduced from the Depository Rights
holding

When Drips is set as “YES” the entries before input of the price will be to the
internal suspense account (REINVEST.SUSP).
Based on CUST.OR.BANK the remaining cash will be credited to the customer.
Alternatively, if “BANK” is specified then a PL category has to be specified to
credit the remaining cash after reinvestment.

Before the price is furnished, entries are raised as under
For the cash option, the customer is credited.
For the reinvestment option, cash equivalent to the value of reinvested stock is
credited to the drips suspense mentioned in DIARY.TYPE
The total amount is debited to the Corporate action suspense
On the input of the price, the above entries are reversed and revised entries
raised as under
For the cash option customer is credited
For the remaining cash after the reinvestment option, either the customer is
credited or the bank’s PL is credited depending on the setup in the
DIARY.TYPE
The Corporate action suspense is debited.

A DRIPS type of corporate actions and a DIARY created for DRIPS type is
shown above.

It is a market practice, if required, to trade short across positions .
This short position is often covered by a stock borrow in order to effect delivery
in the Market.
Whether the short position is covered by a stock borrow or not, the Portfolio
position will continue to show as short within T24
In corporate actions, processing of short positions and unsettled debit
transactions, including flat position is done. It is possible to do allocation of
elections for option events to the portfolio depository and broker/counterparty
level

Flat position is when the position is zero but there exists unsettled transactions
giving rise to the position
Allocation of elections for option events to the portfolio can be done at
depository & broker/counterparty wise in the ENTITLEMENT.
Short sale (settled or unsettled) including the transaction covered by a stock
borrow.
The borrowed positions are created in T24 using the REPO module.

ALLOW.SHORT.POSN field will indicates whether to process the Corporate
Events on Short/Zero Positions or Not. Zero positions will be processed only
when either an outstanding debit/credit transaction or a settled non-returned
borrow/lend exists. The ACTUAL.SETTLEMENT field on SC.PARAMETER is
set to “Yes” and the SETTLE.METHOD field is set to “US”. This will not be
affected by the setting of customers or transactions to contractual settlement,
however it should be noted that if the Broker side of a transaction is set to
contractual settlement, then there is no ability to establish the outstanding
transactions and the desired result may not be achieved. When the
ALLOW.SHORT.POSN field on the DIARY.TYPE application is set to “Yes”,
then the new fields on ENTITLEMENT will be populated with details of both
credit and debit outstanding transactions, details of any non-returned settled
loans and borrows, together with details of the effect that the Portfolio is having
on the Depot position. ENTITLEMENT records will also be created for
positions that are short as of the Ex-date –1, in this case the
QUALIFY.HOLDING field will be updated with a negative amount. Non-
returned settled loans/ borrows, will be established as of the RECORD.DATE
If the ALLOW.SHORT.POSN field on the DIARY.TYPE application is set to
“No”, then the new fields will only be populated with details of the outstanding
credit transactions and existing functionality will then be followed to calculate
the outcome of the event. Only long position as of the Ex-date -1 will be
processed and short positions will not create ENTITLEMENT records.

BROKER.TXN.ID System updated field used to store
a)Broker and transaction reference of the original outstanding debit/credit
transaction concatenated by a "*"
e.g. 100516*SCTRSC0307100013
b)Counterparty and settled non returned stock borrows/lends done via REPO
concatenated by a "*”
TRANS.TYPE is a system updated field used to store brokers transaction type
for the transaction defined in BROKER.TXN.ID.
BR.OUTS.NOM field is used to display the amount of nominal outstanding
from the Broker/Counterparty for the transaction defined in the related
BROKER.TXN.ID. Input to this field is allowed to adjust fractions. When this
field is changed, the value in the fields DEPOT.HOLDING and
OUTSTAND.NOM of the respective Broker get adjusted accordingly.
OPTION.DESC field provides a brief description of the Option, updated by the
system from the originating DIARY record.

OPTION.NOM field is associated with the last six fields make up an 'OPTION'
to choose from.
The user can select to use all their holding against one option OR split their
holding between the different options by entering the number of the Nominal
they wish to take up in this field. This amount added to the total of the
SELL.NUMBER and BUY.NUMBER must be equal to the EVENT.NOMINAL
for the ENTITLEMENT record to be activated.
DEPO.HOLDING is a system generated field which will reflect the effect that
the position has on the Depot (Agent), a negative figure will be produced when
the Portfolio has caused a shortage at the Depot and a positive figure will be
produced when the Portfolio holds stock in the Depot. The field will be
calculated as the QUALIFY.HOLDING – outstanding credit transactions +
outstanding debit transactions + non-returned settled borrows – non-returned
settled loans.
OPT.DESC.DEP ia system generated field, used to display the description of
the option(s) available for the event. This field is no input for mandatory events.
The value in this field will be similar to the value in the OPTION.DESC field.
This field and the OPT.NOM.DEP field form an associated multi-value set.

SC.ENT.INSTR table is used to define the Corporate action standing instruction
for customer or portfolio.. INVESTMENT,PROGRAM table is also used to
define the standing instructions for all customers attached to that investment
programs
Both the files handle default instructions for the following events
RIGHTS,STOCK.CASH,REINVEST and ODDLOTS.
The events can be defined for any one of the following:
A valid security number, S- followed by a valid sub-asset type , A - followed
by a valid asset type and ALL

If RIGHTS field contains ‘TAKE-UP’ then the portfolio will take-up as many
of the stock as possible only selling the remainder rights. If the field contains
‘SELL’ then an order to sell any rights received will be the default action. If the
field contains ‘BUY.MORE’ then the system will automatically create an order
to buy the rights required to round up the number of stock the system will
receive
ODD LOTS field has option either Yes or No
If STOCK.CASH field has ‘CASH’ entered then the default will be the cash
option. If ‘STOCK’ is entered then the default will be the stock option.
If ‘RECOMMEND’ is entered the system will look at the
‘RECOMMENDATION’ field for the stock on the SECURITY.MASTER
record. If this field contains ‘BUY’ or ‘STRONG BUY’ then the stock option
will be taken, if this field contains ‘HOLD’, ‘SELL’ or ‘STONG SELL’ then the
cash option will be taken.
If the field REINVEST contains ‘YES’ then any income received as cash will
be reinvested to buy more of the security paying out the cash. In this case a
SEC.OPEN.ORDER record will be automatically created to purchase this
amount. If the field contains ‘NO’ then any cash received will be paid to the
settlement account of the portfolio owning the stock.

f the field REINVEST contains ‘YES’ then any income received as cash will be
reinvested to buy more of the security paying out the cash. In this case a
SEC.OPEN.ORDER record will be automatically created to purchase this
amount. If the field contains ‘NO’ then any cash received will be paid to the
settlement account of the portfolio owning the stock.
SELL.ODD.LOTS Field will contain the standing instruction to be used when
deciding whether to automatically sell any odd lots received. This field will
allow input of 'YES' or 'NO' only.

It is possible to set up default standing instructions for ENTITITLEMENT
records. The key for default is DEFAULT in SC.ENT.INSTR table. When a
DIARY record is created , T24 will check the values is set to ‘YES’ in
DEF,INSTR.APPLY field. The date on which the instructions is to be applied
while creating ENTITLEMENT is calculated using the values in the fields
DEF.DB.OF.DAYS, DEF.PRI/AFT and DEF.INSTR.SEL.DATE from
DIARY.TYPE and stored in the field DEF.INSTR.DATE of DIARY record.
During the Start of day processing, T24 will search for any unauthorised
ENTITETLEMENT record where the default instructions should be applied.
At this stage, only instructions for RIGHTS or OPTIONS (STOCK/CASH) will
be checked. The REINVEST.INCOME and ODD.LOTS instructions will be
applied at the authorisation stage of the ENTITILEMENT record.

The setup files for TAX are as under:
CONDITION.PRIORITY set the Priority items of tax conditions for a customer
TAX.TYPE provides the description of the type of tax
TAX.GEN.CONDITION specifies the grouping of customers based on the
condition defined
For example if SECTOR is priority item then a group can be formed for all
customers whose RESIDENCE is US.
CUSTOMER.CHARGE table customer charge group for the tax is updated.

TAX table holds the rate of tax with effective date. For example Capital Gains
Tax.
TAX.TYPE.CONDITION specifies the applicable TAX record for each of the
tax groups .
APPL.GEN.CONDITION is another table in which, grouping condition can be
specified for the contracts
ID is either DIARY or ENTITLEMENT
COUPON.TAX.CODE record is keyed on the security domicile and defines the
source and local tax rates applicable for each security type.
The user can choose between a TAX code and a TAX.TYPE.CONDITION code.
When a TAX.TYPE.CONDITION code is used, the tax rate depends on the
rules set up in the CONDITION.PRIORITY, TAX.GEN.CONDITION and
TAX.TYPE.CONDITION files. In this case, the tax calculation is based on the
customer type
SECURITY.MASTER Coupon tax code record is specified

TAX.TYPE table set up is USDOMTAX . Based on the
CONDITION.PRIORITY fields the TAX.GEN.CONDITION are defaulted. A
new group is formed for US residents. The charge group is defaulted into the
CUSTOMER.CHARGE for a customer whose residence is US.

For the TAX.TYPE USDOMTAX, a record defined in
TAX.TYPE.CONDITION with the tax for each tax group .

In the above record , the definition of tax could be directly to the tax record or
Tax definition could be linked using the TAX.TYPE.CONDITION which will
be applied based on the customer.

Tax calculated only if the DIARY.TYPE record for the event has the flag for
TAXABLE as YES

From the previous flow chart, the customer group is picked up and in addition
the contract group is combined to arrive at the tax to be applied.

Source Tax
Source Tax = ABS (Gross.Amount) * Source Tax Percentage
Local Tax
Local Tax = ABS (Gross.Amount) * Local Tax Percentage
Split: For Source and Local Tax, fields here specify whether tax entries are
from ENTITLEMENT are to be posted separately to customer’s account or
included in net cash credit
CUST/DEP fields define whether tax calculation is based on conditions
relating to residency of Depository or of customer.

For some Corporate Actions, the customer can recover a part of the tax paid.
This Recoverable Tax amount is for information purposes and no accounting
entries are generated.
Can be defined for a share/bond in the COUPON.TAX.CODE
A tax code or TXN.TYPE.CONDITION can be defined
Defaults into the DIARY when the event is a gross type of event

Three fields are involved in the Stamp tax calculation:
STAMP.CALC.RTN field indicates the name of the routine that will calculate
the amount subject to the tax and post it on the
ENTITLEMENT record. There is no validation against the routine name entered
in this field.
STAMP.MIN.AMT field contains the amount in charge of the bank. Only
stamp tax amounts greater than this amount will be charged to the customer.
STAMP.CAT.BK field indicates the category to which the stamp tax in charge
of the bank should be posted.

Gross
Entitlement amount of 30000 @ 1% tax will imply 30000-1%*30000 = 29700
credited to customer & 300 credited to the tax account (internal account)
Net
Entitlement amount of 30000 @ 1% tax will imply 30000 credited to customer
with tax credit of 30000*100/101 displayed for information. No accounting
takes place

Specified in CUSTOMER.SECURITY, SCTR.GROUP.CONDITION and
DIARY.TYPE
The charges to be a FT.COMMISSION.TYPE
System first checks to see if CUSTOMER.SECURITY record of customer has
setting
If yes, then charges based on that.
If not, looks into SCTR.GROUP.CONDITION
If not, then charge based on DIARY.TYPE setting
Customer Net Amount Customer.Net.Amount =
Gross.Amt - Foreign.Charges - Commission - Commission.Tax
- Source Tax - Local.Tax
Bank.Customer.Net.Amount = Gross.Amt
Depository Net Amount
Depository.Net.Amt = Total Customer.Net.Amount + Total.Customer.Comm
+ Total.Customer.Local.Tax
Bank.Depo.Net.Amt = Total.Cust.Net.Amount - Total.Cust.Foreign.Charge
- Total.Cust.Source.Tax

The accounting entries for entitlement are generated as follows. When
ENTITLEMENT is authorised, then entries are raised by credit to CUSTOMER
cash account and a debit to the internal suspense account for that purpose.
When all ENTITLEMENTs under a DIARY are authorised including those for
depositories, then the internal account is credited with a debit to the depository
account or the Nostro account for the total value of the distribution. This will
happen when UPDATE NOSTRO is set to Yes. The eligible amount is
calculated GROSS or NET of taxes and charges as specified at DIARY level.

Customer - Long Position or Positive Customer.Net.Amount
a. CR: Customer Current Account or SUSPSCCR if Memo Account
entry to be in Trade Currency, (STMT.ENTRY) with
Customer.Net.Amount.
b. DB : Internal Wash Account SUSPENSE, (STMT.ENTRY) with
(Customer.Net.Amount + Commission.Amt).
CR: P&L Commission Category (CATEG.ENTRY) with Commission.Amt

CR: Tax Internal Account (STMT.ENTRY) with Commission Tax Amount.
CR: Stamp Tax Internal Account (STMT.ENTRY) with Stamp.Tax.Amt
BANK Customer - Long Position or Positive Customer.Net.Amount

??? CR: Special Entry LIVEDB Asset Account (RE.CONSOL.SPEC.ENTRY)
Bank Customer.Net.Amt
DB: Internal Wash Account (STMT.ENTRY) with Bank.Customer.Net.Amt

When all the ENTITLEMENT depository records are authorised, then the
following entries are raised:
CR: Internal Account SUSPENSE (STMT.ENTRY) with
(Total CUSTOMER.NET.AMOUNT + COMMISSION.AMT)
DR: Depository account/Nostro account

After each Entitlement and after last Entitlement is authorised the accounting
entries are generated.

DIARY record can have a number of different securities involved. For example
a take-over corporate action may find a security being replaced by a different
security and some loan stock. The delivery of the new security and the loan
stock could take place at different times, especially where some customers have
assented to the take-over and other customers have dissented from the take-over.
Consequently if there is one SC.SETTLEMENT record for the corporate action
this record will be quite complex.
For this reason where there is more than one stock involved in a corporate
action then an SC.SETTLEMENT record will be created for each stock
movement. If there is a cash expectation as part of this type of complex
corporate action then a separate SC.SETTLEMENT record will be created for
the cash movement
Another difference with DIARY is that the other side of the transaction is a
depository rather than a broker or counterparty. Consequently the BROKER.NO
field will contain a list of the depositories involved in the corporate action when
the SC.SETTLEMENT record has been updated from a corporate action.

On authorising of each ENTITLEMENT
Credit Internal suspense account for customer settlement suspense for
the customer amount
Debit Internal suspense account for broker settlement suspense for the
settlement amount
Credit Internal suspense account for miscellaneous settlement suspense
for the commission amount for the corporate action

After each Entitlement authorised the accounting entries are generated.

On settlement and authorization of the respective SC.SETTLEMENT record,
entries to the settlement suspense will be reversed and entries as under will be
raised.
Debit Internal account for Customer settlement suspense
Credit Customer account
Credit Internal account for broker settlement suspense
Debit Internal account for Corporate action suspense
Debit Internal account for miscellaneous settlement suspense for the
commission amount
Credit Profit & Loss Category

After each Entitlement is settled and authorised the accounting entries are
generated.

On completion of all the settlement records for a depository and provided
update NOSTRO is mentioned in the DIARY.TYPE
Credit Internal account for Corporate action suspense
and Debit Depository Nostro Account for all the entitlements

After last Entitlement is authorised the accounting entries are generated
provided update NOSTRO is mentioned in the DIARY.TYPE.

EB.ACTIVITY table is file is used to define and control the output of delivery
messages from all T24 applications using Soft Delivery.
Activities that produce delivery output are defined by the records on this file.
These activities relate to specific events during the life the contract.
The delivery messages relating to each of these events may, if required, be
produced prior to the event itself. The number of days in advance of the event
that the messages are produced is defined on this file
EB.ADVICES table controls the output of delivery messages, the format of the
messages and deal slip formats for an EB.ACTIVITY.
An account owner sends this message to those who service the accounts
(account servicing institution). MT 565 is sent to the custodian/depository.
The message is used to provide the custodian with instructions on how the
account owner wishes to proceed with a corporate action event. Instructions
include investment decisions regarding the exercise of rights issues, the election
of stock or cash when the option is available and dividend reinvestment.

MT565. INSTRUCT is used to send MT565 messages to the depositories
online, when elections on optional corporate events are received from their
clients. With this you can generate MT565 messages for a single entitlement or
for a group of entitlements even before the Nth Entitlement is authorised.
ID comprises of Alphanumeric characters.
You can specify the diary record number and, if required, the depository and
subaccount in the multi-valued set of fields DIARY.ID to SUB-ACCOUNT. The
Fields DIARY.ID and DEPOSITORY will be multi-valued fields whilst the
SUB.ACCOUNT field will be a sub-valued field.

After verification of the record, matching ENTITLEMENT records relating to
this DIARY event that have been updated with the clients’ elections but not yet
instructed to the agent are selected and the message is generated for the
aggregate nominal for each options
ENTITLEMENT/DIARY record are updated with the delivery reference Id .
For the final ENTITLEMENT record authorised, message is automatically
generated.

MT540 Receive Free will be generated if the customer is buying and the broker
is selling stock with broker delivery instructions set to FREE i.e.
SC.DEL.INSTR record with WITH.PAYMENT.FLAG set to “NO”
An MT541 Receive Against Payment will be generated if the customer is
buying and the broker is selling stock with broker delivery instructions set to
DAP i.e. SC.DEL.INSTR record with WITH.PAYMENT.FLAG set to “YES”
An MT542 Deliver Free will be generated if the customer is selling and the
broker is buying stock with broker delivery instructions set to FRE i.e.
SC.DEL.INSTR record with WITH.PAYMENT.FLAG set to “NO”
An MT543 Deliver Against Payment will be generated if the customer is selling
and the broker is buying stock with broker delivery instructions set to DAP i.e.
SC.DEL.INSTR record with WITH.PAYMENT.FLAG set to “YES”

MT 544 Receive free confirmation
This is an inward message to be processed in T24. An MT544 will be processed only if
the MSG.TYPE field in SP.STP.PARAM is set to “544”. This message will be received
from the depository to whom an MT540 Receive Free is sent. This message will
confirm the receipt of stock in full or in part from the respective Broker with whom the
Trade has been done.
MT 545 Receive against payment confirmation
This is an inward message to be processed in T24. MT545 will be processed only if the
MSG.TYPE field in SP.STP.PARAM is set to “545”. This message will be received
from the depository to whom an MT541 Receive against payment is sent. This message
will confirm the receipt of stock in full or in part and Payment in full or in part from or
to the respective Broker with whom the Trade has been done.
MT 546 Deliver free confirmation
from the depository to whom an MT542 Deliver Free is sent. This message will confirm
the receipt of stock in full or in part from the respective Broker with whom the Trade
has been done.
MT 547 Delivery against payment confirmation
from the depository to whom an MT543 Deliver against payment instruction is sent.
This message will confirm the delivery of stock in full or in part and Payment received
in full or in part from or to the respective Broker with whom the Trade has been done.

For each ENTITLEMENT created for diary which involves the stock update, a
SECURITY.TRANS record is created. SECURITY.POSITION will be updated
with the increase in the stock due to the entitlements.

Non Stop Corporate Actions processing is enabled for all DIARY.TYPE events .
The functionality is available for both Customer and Own book positions.
The following applications relating to Corporate Actions can now be done while
COB is in session.
Create, amend and rerun a new DIARY record.
Input and amend ENTITLEMENT records created during COB
Reversal and deletion of both DIARY and ENTITLEMENT that were created
during COB is allowed.
When Actual Settlement is on, the SC.SETTLEMENT records created as a
result of the Corporate Action event can also be processed.
This is not supported for any records created prior to COB.

Jan to mar calc on 31/3with other three options with posting on 15/4
Closing – January with January 31 balance, February with February 29
balance, March with March 31 balance
Average – weighted average January balance on January 31 and so on.
Month average – month end weighted balance of 3 months /3 for the period
Example : January 10000, February 12000, March 15000 – closing
Weighted average January 10000, February 12000, march 12000 then average
10000 for 1 and so on
Calculation Of Safe Custody 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.
This method facilitates review by Account Manager within the charge period
and collect the fee on the due date.

For monthly accruals, 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.
Dec End PV = 10000, Jan End PV = 20000 and Feb End PV = 60000
Custody commission calculated for the period is SGD 180 on Mar 1st
Reviewed, altered by the RM and posted SGD 90 for the value date of 31st Mar
Dr – client account by SGD 90 with a value date of 31st Mar
Cr – Internal accrual category account by SGD 90 with a value date of 31st Mar
From the date of posting example 15th March, the accrual should be based on
SGD 90 for the whole period. Already posted amount to be reversed and the
accrual should start as SGD90 as a base. For accrual, the new rate =
90*4/30000*100=1.2% (for the whole period) PERFORM.ACCRUAL This
field is associated with the CHARGE.TYPE. You should only set this field to
either DAILY or MONTHLY if you require accrual of the associated fees at that
selected frequency. Valid values of 'MONTHLY' , 'DAILY' or 'NO'
If set to a value of 'MONTHLY' or 'DAILY' then the ACCRUAL.CATEG must
also be set. DAILY is only valid if records set to use the PREV.MONTH.CLOSE
method.

The safekeeping and management fees have now been enhanced to accept a
Second fee code and percentage when the calculation method is ‘DETAIL’ and
if fee accruals are set to be performed ‘Daily’. If specified, then the amounts
calculated for individual assets based on DET COMM CODE and DET
PERCENTAGE will be totalled up to form the base amount on which the
SECOND FEE CODE will be applied. The amount so calculated will then be
considered the management or safekeeping fee to be charged to the customer.
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.
Under 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.

INTEREST.DAY.BASIS for the purpose of accrual possible 360/360,366/360
or 366/366 .
DAILY.ACCR.TYPE field is set as DAILY.RATES to calculate fees on prorate
basis.
When FT.COMMISSION.TYPE record is set with a date suffix to effect rate
changes in between charge period.
DAILY.POST.DATE field is define posting day on daily accrual.
FEE.GROUP used to link with local reference field in SM/ACCOUNT for
grouping asset – useful for metal ac in account.

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 (PV base of Dec * r1 for 10 days)+ (PV base of Dec * r2 for
remaining Jan days)+(PV base of Jan *r2 for Month days)+ (PV base of Feb*r2
for month days).
Pro-rating for rate changes during the period
Pro-rated calculation for interim rate changes possible If rate changes on Feb 1st
(for the fee period Jan to March), fee for Jan will be calculated at the old rate
and the Feb and March fees will be based on new rate

Opening of a portfolio
Opening on 20 Feb. Q1 will have 40 days calculated on end of Feb Securities
Value
After calculation (CD) before booking date (BD) =during grace period March
days not included for Q1, but added to Q2 90+20 days. Calculated on value end
of Mar, Apr & May. Hence Q2 fee = 50 days on March End PV*rate + 30 days
on Apr End PV * rate + 30 days on May End PV * rate
After booking (BD) and before value date (VD)March days not included for Q1,
but added to Q2 90+4 days. Calculated on value end of Mar, Apr & May. Hence
Q2 fee = 34 days on March End PV*rate + 30 days on Apr End PV * rate + 30
days on May End PV * rate
Closure of a portfolio
closure on 20 Feb, then Jan fees + Feb*20/30 + No Mar Fees
After calculation (CD) before booking date (BD) =during grace period closure
on 10 Mar, Jan Fees + Feb Fees + Mar*10/30,
to re-calculate & post new debit amount accordingly
After booking (BD) and before value date (VD)Closure on 26 Mar, Jan Fees +
Feb Fees + Mar*26/30 days.
To Reverse the already posted Fee and recalculate and post the fee upto 26th
March.

Portfolio closed in January (first month) Closing on 20 th January:
Q1 will have (PVBase at December end * rate for 20 days).
The calculations will stop on that date
Portfolio closed in February (second month) Closing on 20 th
February:
Q1 will have (PVBase at December end * rate * Jan days) +
(PVBase at January end * rate for 20 days)
Portfolio closed in March (third month) – after show fee date
Closure on 10th March
Fees will be (PVBase at December end * rate * Jan days) +
(PVBase at January end * rate * Feb days) + (PVBase at
February end * rate for 10 days).
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.

If the metal account has been included in the safe custody fee calculation at the
system level, then metal accounts (with currency declared as a precious metal
field as “YES” in the currency table) included in all the portfolios should be
subject to safe custody fee calculation. The system should have a provision to
attach a separate “FEE GROUP” to link charge type definition for all the
currencies declared as precious metals. The charge scale for precious metals
should be freely defined for the FEE GROUP as for the case of securities in the
GROUP CONDITION (SCSK.GROUP.CONDITION).
The system should take the previous month end closing balance on the account
and percentage if any defined to arrive at the base and the rates will be applied.
This follows the same cycle of calculation, accruals and posting

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.

Fees that are already posted for a portfolio will be available in the application
SAFEKEEP.HOLDING.POSTED.
This record can be reversed and upon authorisation of the same, a new record
would get created in SAFEKEEP.HOLDING.REVERSAL in IHLD which upon
authorisation will reverse the fees that is posted

DAILY.EXTRACT field in SAFECUSTODY.VALUES table controls whether
or not the system will perform an extract to the corresponding extract files
'SC.ASSET.BAL' or 'SAFECUSTODY.EXTRACT' on a daily basis or not. If the
field is set to 'YES' then the system will perform the extract on the day the
portfolio moves in the security.
When it is yes SC.SAFEKEEP.ACTIVITY and SC.ADV.FEES.ACTIVITY files
are built during COB. If the field is set to 'NO' then the system will perform the
extract only at the month end. In order for the system to be able to calculate the
charges based on the month's average balance the extract needs to be performed
on a daily basis. These two files holds details of the each day’s positions with
calculation of daily average balance.

It is calculated as weighted average

Similar calculation is done for SC.ADV.FEES.ACTIVITY also.

SAFECUSTODY.EXTRACT and SC.ASSET.BAL are fees related system files
. It is generated for a portfolio by asset or by security. The files are updated
monthly along with accrual.

Screen shot of the table is shown here.

Screen shot of the table is shown here.

SAFEKEEP.HOLDINGS and SC.ADVISORY.CHG are fees related system
files. The files are generated with the frequency specified in the parameter.
Created for each portfolio taking the total of all the details asset wise. The
amount of fees calculated by the system can be amended by the user before
posting.
Fees can be collected from different accounts, Field ACCOUNT can be

populated with any valid account number. override messages is generated if
different accounts not belonging to the portfolio is input to alert user.

The fees calculation is from the definition from the group condition and the
parameter for the fees.

Similar calculation and flow for advisory charge. It should be noted that no fee
is available for depository charges.

After the fees have been approved by the Account Officers, posting to customers
can be done online or during COB . For posting entries during COB, post
charges and company post fields must be YES on SAFECUSTODY.VALUES
table. For online posting, parameter to be set as post charges as Y. Record is
created in SC.SAFE.FEES.POST / SC.ADV.FEES.POST with the Id as the
account officer. Then the record is verified . Then initiate the service agent.
XXX/SC.SAFE.FEES.POST
The existing record in SAFEKEEP.HOLDING is updated as POSTED from
CALCULATED. Then new record created in SAFEKEEP.HOLDING.POSTED
table.

T24 Securities module contains a comprehensive Portfolio and Investment
Management Application, thus enabling account and/or fund managers to
provide a full range of services to private clients.
Mechanism for automatic intra-day revaluation of portfolios involved the near
real-time valuation process of identifying the triggers for valuation. The triggers
are nothing but events that will have an impact on the valuation of a portfolio.
In other words, any transaction or a static change that affects the portfolio value
is a trigger for the valuation process. The valuation process should be capable of
tracking such events and revalue the portfolio(s) in run time.
The real-time valuation user guide deals with the mechanism for automatic
intra-day valuation of portfolio based on triggers. The triggers are nothing but
events that will have an impact on the valuation of a portfolio. In other words,
any transaction or a static change that affects the portfolio value is a trigger for
the valuation process. Based on these triggers, valuation will be performed
online for select portfolios.
In a volatile market situation, the valuation swings could be huge and unless
there is a mechanism to update valuation automatically, the valuation based on
which the decisions are made by the Bank could be drastically different from
the valuation at the time the decision is made.
327
The existing valuation process can be divided into three major segments based
on the application/nature of transaction that is being processed:
Updating a Portfolio from an ACCOUNT - A Customer portfolio can be linked
to accounts on the system. It is necessary when opening a SEC ACC MASTER
to define precisely which accounts belong to the portfolio. When calculating the
value of a portfolio, the balance of those accounts will be included in the
valuation.
Updating a Portfolio from the Securities Module - Any securities transaction

must include one or more portfolios. The securities transactions could be trade,
transfer or corporate action. In case a securities movement is involved, the
SECURITY POSITION will be updated with the details of the movement and
the positions will be included while calculating the value of a portfolio.
Updating a Portfolio from Other Modules - Other non-SC applications can

update a portfolio, subject to their having been linked to the portfolio. In case
the other assets and liabilities are linked to a portfolio, the portfolio valuation
process will include these while revaluing the portfolio.
328
There will be several intra-day events like security price movements, security
position and account balance movements that could have an impact on the
portfolio valuation. In a volatile market situation, the valuation swings could be
huge and unless there is a mechanism to update valuation automatically, the
valuation based on which the decisions are made by the Bank could be
drastically different from the valuation at the time the decision is made.
The valuation carried out, as part of COB or when triggered through an online
valuation enquiry, revalues the entire portfolio even if there is a change only to a
specific component of a portfolio. Consider a portfolio that has holdings in fifty
Securities and has ten accounts linked. As part of the valuation process, the
entire portfolio will be revalued even though only change that has happened is a
price change in one of the securities in which the portfolio has a holding. This
could have an impact on the performance, especially in the case of large
portfolios with multiple positions and accounts linked to it.
329
The shortcomings like updating the true value of the portfolio can be overcome
by a mechanism for automatic intra-day revaluation of portfolios. The first step
in the near real-time valuation process will be identifying the triggers for
valuation. The triggers are nothing but events that will have an impact on the
valuation of a portfolio. In other words, any transaction or a static change that
affects the portfolio value is a trigger for the valuation process. The valuation
process should be capable of tracking such events and revalue the portfolio(s) in
run time.
T24 Real-time valuation engine caters to this requirement through
OV.PARAMETER.
It will, however, be possible to move portfolios in and out of this category at
any stage. If a dormant portfolio becomes active all of a sudden and there is
need to automatically track valuation for this portfolio intra-day, then this
feature can be activated for that portfolio. Similarly, this can also be switched-
off at any time for a portfolio that moves from being active to dormant.
330
ONLINE.VAL Field :- If set to YES, the events that have an impact on the
valuation are captured and the valuation process is initiated automatically for
the concerned portfolio(s).
EXC.EVENTS Field :- Contains details of the events that have to be excluded
from the list of triggers. If the Bank does not require real-time valuation to be
triggered for certain events, these events can be input in this field. This will
ensure that the valuation is not triggered when these events are encountered.
Tolerance can be set for price movements. This is to ensure that the valuation is
not triggered for minor price changes. Only if the price change is in excess of
the tolerance set, the valuation will be triggered.
If the tolerance is set in terms of Amount, the valuation will be triggered only if
the price change is in excess of the amount in PRC.TOL field. If the tolerance is
expressed as a percentage, then the PRC.TOL field will hold the percentage and
any price change in excess of the percentage specified will trigger valuation.
If PORTFOLIO field in OV PARAMETER is set to ALL, Online valuation will
be activated for all the portfolios. If not, the online valuation for specific
portfolios can be activated by setting ONLINE.VAL field in SEC ACC
MASTER to YES.
331
The portfolios that require real-time valuation is identified either through the
PORTFOLIO field in OV.PARAMETER or the ONLINE VAL field in SEC
ACC MASTER.
It must be noted that ONLINE VAL in SEC ACC MASTER can be set to YES
only if ONLINE VAL is set to YES in OV.PARAMETER.
It will, however, be possible to move portfolios in and out of this category at
any stage. If a dormant portfolio becomes active all of a sudden and there is
need to automatically track valuation for this portfolio intra-day, then this
feature can be activated for that portfolio. Similarly, this can also be switched-
off at any time for a portfolio that moves from being active to dormant.
If PORTFOLIO field in OV.PARAMETER is set to ALL, Online valuation will
be activated for all the portfolios. If not, the online valuation for specific
portfolios can be activated by setting ONLINE.VAL field in
SEC.ACC.MASTER to YES.
The portfolios that require real-time valuation is identified either through the
PORTFOLIO field in OV.PARAMETER or the ONLINE VAL field in
SEC.ACC.MASTER.
It must be noted that ONLINE.VAL in SEC ACC MASTER can be set to YES
only if ONLINE.VAL is set to YES in OV.PARAMETER.
332
333
334
335
336
Some of these triggers have an effect only on one element. For example, haircut
change affects only the margin value of that particular security or asset type,
whereas others have an impact on multiple elements. Example - a securities
purchase will impact both the securities value and cash account balance. Some
of these triggers are transaction based (securities transaction, funds transfer,
etc.) and some are static in nature (haircut change, price change, etc.). There are
also events that affect only a single portfolio (securities transaction, funds
transfer, etc.) whereas there are others that could affect multiple portfolios (a
price change of a security that is held by many portfolios).
The automatic valuation engine is capable of handling the various types of

events as detailed below:
Triggers based on static change – Haircut
Transaction triggers – Securities purchase, transfer, Deposit, Funds Transfer, etc.
Global triggers – Price change, currency rate change, etc.
Triggers that impact more than one element – Securities purchase (for example)
337
The real-time valuation engine will identify the element or elements that
has/have undergone a change as a result of a particular transaction and revalue
only that particular component.
A work file will be updated in case a triggering event is encountered for a

portfolio that is set for real-time valuation.
Once the work file is updated, running the BNK/OV.ONLINE.VAL.FINAL

service will revalue the portfolio affected by the transaction. The valuation
engine will pick the key and perform the revaluation of the component impacted
based on the key. The valuation details will be updated in SEC.ACC.MASTER
and SC.POS.ASSET.
338
A work file will be updated in case a triggering event is encountered for a
portfolio that is set for real-time valuation.
The key of the work file for the various segments will be as under:
Cash account movements - <Product Code>*<Account No>
Securities Transactions
Change in the portfolio holdings - SC*<Portfolio ID>.<Security

No>.<Depository>
Change in price - SC*<Security No>
Other Module Transactions - <Product Code>*<Transaction reference>
339
340
341
342
343
344
345
346
The concept of buying power summarizes the liquidity of the portfolio. It offers
a portfolio wide view of the amount available to invest and in that sense, more
comprehensive than, say, the cash flow checks that are currently carried out as
part of the order validation process.
The aim of the Buying power calculation as described in this document is to

ensure that the additional risk of an order is covered by sufficient Buying power.
To achieve this, the execution of the order is simulated and the effects on the
Buying power are computed.
Buying power is the potential amount that a client can invest, including cash
balances, credit lines (if any) and lending value of securities (hair-cut).
For a given portfolio, the buying power will be calculated as under:

Buying Power = Cash balances + lending value of securities + margin value of
other assets – pending orders – estimation value of other liabilities
348
The aim of the Buying power calculation as described in this document is to
ensure that the additional risk of an order is covered by sufficient Buying power.
To achieve this, the execution of the order is simulated and the effects on the
Buying power are computed. Only if the Buying power is greater than the order
amount, the order will be accepted and processed further. This approval process
applies to all new orders as well as to the amendment of pending orders.
Pending orders are orders that have been approved already, but are for some
reason not yet traded (e.g. limit orders).
The customer’s cash accounts (including term money), the margin value of the
customer’s securities and other assets creates the buying power. Pending
securities orders and other obligations reduces the buying power.
349
Before an order is processed, the buying power calculation engine will
determine whether there is sufficient buying power to meet the cost of
execution. This is done by simulating the execution amount and comparing it
with the buying power calculated. If the Order amount is less than the
Buying power, the system will raise an override to that effect. In this case, if the
order amount is less than the buying power, the order will be processed straight
away, else, override for buying power shortfall will be raised. Override will also
be raised if the calculated buying power is negative.
The overall principle of buying power check is governed by risk aversion.

Therefore, only the pending purchase orders are included in the buying power
calculation and not the potential positive cash flows on account of sell orders.
350
The following events trigger the buying power calculations
a) New Orders Ex:- Purchase
a) Amendment of pending orders Ex:- Purchase (only for nominal or price
change)
On the other hand, these events will not trigger the buying power checks
a) Sell Orders
b) Cancellation of pending orders
Buying power is the potential amount that a client can invest, including cash
balances, credit lines (if any) and lending value of securities (hair-cut).
The buying power will always be calculated in the reference currency of the
portfolio. The buying power, so calculated, will be compared against the order
amount (to determine whether sufficient buying power exists.
Setting the BUYING.POWER Field in OV.PARAMETER will ensure that the

buying power checks are carried out as part of the order valuation process
351
352
353
356
Before getting into the calculations of margin lending, let us look at the concept
of borrowing against the portfolio.
The maximum amount that can be borrowed against the portfolio is called the
Total Loan Value (TLV) of the portfolio and is determined by applying Loan to
Value Ratio (LVR) assigned to each security/group of securities/assets/liabilities
in the portfolio. The TLV is also known as the Margin Value and the LVR is also
known by the term Margin Rate.
357
Setting the MARGIN.LENDING Field in OV.PARAMETER to YES enables the
buying power and loan eligibility calculations. There is also a
MARGIN.LENDING Field in SEC.ACC.MASTER to identify the margin
lending portfolios. This field can be set only if MARGIN.LENDING is set in
OV.PARAMETER.
There are two distinct uses for the above calculations:

a)To determine how much can borrowed against a portfolio; and
b) To determine additional securities that can be purchased without cash using
the existing portfolio.
A customer who purchases securities may either pay for the securities in full or
borrow part of the amount from the bank. The portion of the consideration that
the customer pays is the customer’s equity.
While borrowing, as above, has the potential to increase the returns, the losses
can also potentially increase. Falls in the market value of the portfolio can
make the portfolio value less than the loan amount borrowed. This will result in
bank raising a demand on the investor for depositing additional cash/securities
or selling off securities/repaying loan for bringing the portfolio back on track.
This results in what is generally known as the Margin Call.
358
While borrowing, as above, has the potential to increase the returns, the losses
can also potentially increase. Falls in the market value of the portfolio can
make the portfolio value less than the loan amount borrowed. This will result in
bank raising a demand on the investor for depositing additional cash/securities
or selling off securities/repaying loan for bringing the portfolio back on track.
This results in what is generally known as the Margin Call.
As against the loan amount availed, the TLV of the portfolio is now be reduced,
resulting in a margin call situation. The customer has to now deposit additional
cash or bring in new securities to meet the margin obligation within the time
stipulated for clearing the margin call.
359
If the margin call situation is not addressed within the stipulated time, the bank
will be constrained to “force sell” some of the customer’s holdings.
In some cases, customers are provided a buffer to enable them to manage the
portfolios into a suitable position.
This buffer could either be a percentage of the market value or the margin value
of the portfolio.
For example if the margin value is USD 67,440.75, the loan value is USD
696,000.00, if buffer is set to 10%, then the combined value (margin + Buffer)
will be above the loan value (USD 741,848.25 as against loan value of USD
696,000). Therefore, no margin call will be triggered in this case.
360
361
362
363
364
365
366
367
369
Let us look at the Customer facilities and its impact of buying power
calculations.
If a newly opened securities portfolio has no security holdings but only an
account (USD) with a balance of USD 500,000 in it, the Buying power of the
portfolio will be USD 500,000. However, this will undergo a change if a
customer enjoys a facility with the bank.
In the above example, let us say, the client enjoys a facility of 50% with the
bank. The Buying power, with USD 500,000 cash, will be USD 1,000,000
(500000/50%). This means that the customer will be allowed to buy securities
worth USD 1,000,000 with a cash of USD 500,000. The loan component,
therefore, will be USD 500,000. As the facility granted to the customer is 50%,
the Loan to Equity ratio will be 1:1.
370
The facility will be at portfolio level and can be set only if
MARGIN.LENDING Field is set as YES in SEC.ACC.MASTER. Besides, the
facility should also be set at OV.PARAMETER level before it is set at individual
portfolio level. The facility at OV.PARAMETER level will act as the cap and
the facility at the portfolio level cannot exceed this.
Let us assume that the customer enjoys a 40% facility with the bank. This
means that the ratio of bank’s contribution to customer’s contribution will be
1:1.5 (40% from bank, 60% from customer).
371
The calculations begin to get complex when other positions get added to the
portfolio. Let us consider an example where there are some securities held by
the portfolio besides the cash balances in the account.
Let us assume that the customer enjoys a 40% facility with the bank. This
means that the ratio of bank’s contribution to customer’s contribution will be
1:1.5 (40% from bank, 60% from customer).
The buying power in this case will be determined as under:-

Buying Power = ((Cash/(1-facility)) + ((Stock * Facility/(1-facility)))
= ((50000/ (1-40%)) + (25000*40 %/( 1-40%))) = USD 83333.33 + USD
16666.67 = USD 100,000
As the customer has a cash balance of USD 50,000, the loan component will be
USD 50,000 (to meet the purchase consideration of USD 100,000).
In this case, it is assumed that there are no other liabilities and the LVR of new
security being purchased is 100%.
372
In the above example, let us assume that the new stock being purchased has a
margin rate of only 75% instead of 100% assumed in the previous example. The
buying power will now change as the LVR of new security is less than the
previously given LVR. The buying power, considering the new LVR, will be:
((Loan/(1-(Facility*New Stock LVR)) + (Stock* Facility/(1-(Facility*New
stock LVR))) =
= ((-50000 / (1- (40%*75%)) + (150000 *40 %/( 1 – (40%*75%))) = -71428.57
+ 85714.29 = USD 14285.71.
373
If there are fluctuations in the market prices of securities against which a facility
has been granted, there is a possibility of the total loan or margin value of the
portfolio going below the loan/facility availed by the customer. This would
result in a “margin call”, wherein, the customer will be forced to bring in
additional cash or securities into the portfolio or sell off some of the holdings to
make good the deficit
374
375
376
377
378
379
380
381
382
383
384
385
386
Besides the standard LVRs discussed earlier, it will also be possible to define a
Top-up LVR and Sell-out LVR. If these are defined, the margin value of the
portfolio will also be calculated using the Top-Up LV% and Sell-out LV%. The
top up and sell out margins can be specified at all levels where the standard
LVRs can be set:- MARGIN CONTROL, SUB ASSET TYPE, ASSET TYPE
and SC CUSTOMER MARGIN.
387
If the margin Value of the portfolio (applying the standard LVR) goes below the
loan availed on any given day, there will be no action taken in case top up and
sell out margins have also been specified.
However, on any day, if the Top-Up level is breached (margin value goes below
the loan amount with TOP-UP LV %), a top-up margin call will be made. The
customer will be asked to pay in more cash or reduce the cash or transfer in
additional eligible securities within a stipulated timeframe.
Similarly, if Sell-out level is breached, it is a more serious situation demanding
immediate action. A sell-out margin call will be made and the bank may even
initiate take action to sell some of the securities in order to cover the deficit.
It must be noted that the buying power calculations will only be based on
standard LVRs. The Top-up and sell-out LVRs will only be used to determine
the action required in respect of margin calls.
Since this is also another form of buffer, BUFFER in OV PARAMETER will
not be set if these margins have been specified and vice versa
388
389
A custodian is a bank or other institution that holds securities on behalf of
investors.
Custody, in short, is a service that deals with holding and administering
securities on behalf of third parties. In line with the growth of financial markets,
custody has also evolved into a complex business no longer characterized by
just physical book keeping of securities. Custody services are provided by a
variety of intermediaries.
The tasks performed by a custodian include
safekeeping of securities, delivering or accepting traded securities and
collecting prinicpal, interest, or dividend payments on held securities
Collectively, these services are called custody.
390
In case of an entity that acts both as an Investment Manager and Custodian, the
information needs of the portfolio Manager and client can be collated and
provided easily as all the information relating to the portfolio (like performance
details and valuation) are held internally.
In cases where the custody is external, the portfolio Managers need to get
accurate information about all the positions/assets under management for the
purpose of carrying out portfolio analysis, performance monitoring and
providing consolidated valuations. There should be an operational framework
that will enable him to provide consolidated reporting and monitor the
performance of the portfolios taking into account the externally held positions
as well. Portfolio Managers need access to the external positions in order for
them to carry out portfolio analysis and take effective investment decisions.
In order to meet this objective, all external transactions have to be captured in
T24 with all details like brokerage, charges and the actual exchange rates.
391
The “third party” custody positions could be held in separate portfolios in which
case a separate portfolio can be opened for each external custody mandate and
designated to a specific custodian. The portfolios, so designated, can be used
only for external or third party custody transactions.
It will also be possible to have external custody positions in the same portfolio
as custody positions. In such a scenario, there should be a mechanism to
segregate the external positions from the custody positions and identify the
same so that there is no risk of selling the same. In such a scenario, the
positions from internal and external custody have to be integrated. The details of
portfolio holdings could be seen from the SECURITY POSITION file
392
External custody transactions will be allowed only if EXTERNAL.TXN flag is
set to YES in SC.PARAMETER. The external custody transaction codes will
not be allowed with the transactions involving positions maintained internally.
Using ORDER.BY.CUST, the orders can be created for third party custody
positions as well. If the EXTERNAL.TXN Field is set to YES, the orders will be
created for third party custody positions. If this field is not set to YES, the
orders will only be created for the custody (internal) positions.
SEC.OPEN.ORDER will support placement of orders for third-party custody

positions. The orders for external positions will not be transmitted to the broker
as these are not meant for execution through the bank. In other words, the
DEAL.STATUS Field to be set to ‘TRADED’ in these orders so that trades will
be created directly on authorization of the order.
393
It must be noted that the functionality mentioned above pertains to “Direct
orders” from portfolio Managers. In this case, the respective portfolio manager
will instruct each deal directly. The transactions are captured in the bank’s
system only when the final settlement details are known, in order to mirror the
external positions.
The commissions and charges in respect of external custody transactions can be
specified only for the customer leg of the transaction and have to be manually
input.
394
external positions.
input.
395
external positions.
input.
396
397
398
399
400
401
402
403
404
Let us look at the third party custody orders routed through the in house dealing
desk.
If the entity is involved in external custody transactions, then it should allow
buying and selling of securities for the customers whose depository may be held
outside the entity. This is called In-house dealings.
In this case, the settlement is more complex as there should be an additional
outside trade to settle with the custodian.
A new field, INHOUSE.DEALING, will be added to SC PARAMETER to
determine whether third party custody orders can be routed through “in house
dealing desk”. Two fields, IN HOUSE CR TXN and IN HOUSE DR TXN, are
used to identify the third party custody or7ders routed through in-house dealing
desk.
405
In the first step, the transaction is settled with the broker. Since this position has
to be cleared, there will be a second (outside) trade to clear the position by
settlement with the custodian.
In case of external custody orders being routed through the in-house dealing
desk, on execution, the first trade will be the client trade with the executing
broker. The position will be updated with the external custodian details
Two additional trades will be created.
The first trade will be to clear the position by settlement with the custodian. The
customer will be the same as the customer in the first trade; however, the
transaction codes will be reversed. The Broker will be the external custodian as
specified in the order. The price will be recomputed to take into account the
commissions and other charges in order to square-off the accounting of the
original trade, while leaving the originally generated PL entries in place. There
will be no commissions and other charges in this transaction.
The second trade will be to capture the third party custody position in bank’s
books as is the case with direct third party custody orders.
406
407
408
409
410
411
412
413
External or third-party transactions do not affect the bank’s account. These
external positions (both security and cash) are only captured in the system to
enable Portfolio Manager to carry out portfolio analysis and to monitor the
performance of the portfolio.
In order to keep the accounting pertaining to external transactions out of the
bank’s GL, the accounting entries raised for a third party custody transaction
will be different from normal trade accounting.
A contingent account will be linked to the portfolio to capture the cash side of
external custody transactions.
For external custody transactions, only contingent accounts will be allowed. The
other leg will be posted to a suspense account as defined in SC.PARAMETER.
This will again be a contingent category, EXT.SUSP.CAT Field used for this
purpose.
414
The external custody positions will be reflected separately in SC.POS.ASSET
As the information is held in separate multi-values, the valuations can be
reported for External custody positions alone; or Custody (internal) positions
alone; or Consolidated positions.
The safekeeping fees will not be charged on external custody positions.
However, advisory fees will be levied with a proviso to suppress the same, if
required.
415
416
417
418
The corporate actions processing for external custody positions will also vary, as
these are just mirror positions captured in the system for the purpose of portfolio
analysis.
T24 creates entitlements by Sub-accounts/depository where positions are held
across multiple locations. In a similar manner, entitlements will also be created
for the third party custody positions.
In the case of cash events like cash dividend, the accounting for external
custody positions should not impact the bank’s books. This is on account of the
fact that the payments are received externally and are just being mirrored in the
bank’s system.
The entries have been posted to the contingent accounts specified to be used for
third party custody transactions.
419
US settlement method is for actual settlement. SETTLE.METHOD field in
SC.PARAMETER allows input of value "US". This field controls the special
processing of Generation of Broker Positions. When flagged in
SC.PARAMETER for the purpose of holding the unsettled position with the
broker and settled positions with the depository Customer enquiry shows
Customer due positions, settled Depository position and unsettled Broker
position. When Broker delivers, then unsettled Broker position and settled
Depository position changed to reflect settlement activity

The T24 System enables the recording of automatic bond lending initiated by
the depository. This is done using the BOND.LENT.MASTER transaction. You
may also enable the recording of share type lending operations by specifying
this requirement on the main SC.PARAMETER file for the bank using the field
SHARE.LENDING as YES.
The system is now enabled to record all bond and / or share lending details,
whether the request was initiated at portfolio or depository level.
To process FULL security borrowing and lending, REPO module to be installed,
This particular T24 module enables the recording of more complex lending and
borrowing transactions / scenarios as well as a number of REPO.TYPES.
There are two types of lending operations available. The first, at customer
(portfolio) level records the fact that securities have been lent from a specific
portfolio. The second, at depository (depot) level, to record that the depository
holding the security has initiated a borrowing (lending from the point of view of
the Bank) from the Bank’s security account

It is possible to process Stock Borrow lending transactions for customer and
own book positions through the REPO module
When a customer sells short through a SEC.TRADE , it can be covered either
through a SEC.TRADE or through borrow. If the customer requires the option
to cover the short position via a borrow rather than a close out using a
SEC.TRADE, then 2 transactions are recorded in REPO as under-
Market borrow from external counterparty to the wash portfolio
Internal lending from the wash portfolio to the customer
Likewise the stock lending can be done for a long position instead of a
SEC.TRADE /

The characteristics of different types of Repo contracts are defined through
REPO.TYPE table . The records available on this file are referenced from the
main contract file REPO.
The TRANSACTION.INDEX determines whether the contract is treated as a
Repo (a cash deposit) or as a Reverse Repo (cash loan), and is linked to the
PRODUCT.CATEGORY that defaults onto the contract itself.
DEAL.TYPE field IS STOCK.BORROW.LEND.
These DEAL.TYPE's are available to both REPOs and REVERSE REPOs.
GENERATE.FT field option is select YES or NO. When the user has selected
the option of YES the cash margin process messaging associated with this
REPO.TYPE will be handled via FUNDS.TRANSFER, with the generation of
the SWIFT linked to the original contract. No MM.MONEY.MARKET contract
will be generated. The accounting will be generated by associated
SECURITY.TRANSFER.
FT.TRANS.TYPE field used in conjunction with GENERATE.FT to assign a
value to the field TRANSACTION.TYPE in the FUNDS.TRANSFER contracts.

REPO.TYPE is BORROW and LEND with the deal type as
STOCK.BORROW.LEND
INT.BORROW AND INT.LEND with the deal type as INTERNAL In this case
the product category need not be specified
REPO.PARAMETER is a top-level parameter file that is keyed by the id of the
company to which the parameter record refers.
It holds the definitions of the valid portfolio suffixes for the counterparty
margin portfolio, the booking method of the initial margin,
the limit update treatment for REPO contracts and the no. of days post maturity
that contracts are moved to history
Create a portfolio for the wash account and the counterparty with the above
suffix.

For the Stock borrow/lend functionality in REPO the following trades are to be
input. Market borrow from external counterparty to the wash portfolio. This
creates a RESO.POSITION for the wash portfolio .Internal lending from the
wash portfolio to the customer . This creates a RESO.POSITION for the
customer (as the trade is a borrow for the customer) and a REPO.POSITION for
the wash portfolio.
The SECURITY.POSITION for wash portfolio shows ZERO closing balance
with borrowed/lent nominal under RESO/REPO positions and the customer
position reflects the short position along with the borrow amount under
RESO.POSITION.

Features of the trades are as follows.
The trades can be open ended. Early maturity of the trades is also possible. For
partial return of the borrowed/lent amount, margin calls can be used. Message is
generated to the depository and broker for the market trade which can be
suppressed by the user. The trades are independent transactions. Can be
multiple T1s against multiple T2s, however there is no direct link within the
system. Manual control ensures that positions borrowed offset positions lent i.e.
the control account (own book / wash position) should be at 0.

There is no link between trade 1 and trade 2 and there is no requirement to have
a T1 and T2, which offset each other.
For example, a client may return 100 shares on trade 2, and another client then
borrows 100 with another T2. There is no requirement for a return T1. In this
case the positions net out but this is not necessary: the position may be
maintained as a pending position between T2 and T1.
For example, client x returns 100 and client y borrows 60. The “own book /
wash” control account will have a position of 40, which would be manually
closed by users through T1 or T2 transactions.

The client position is not moved as a result of Trade 2. For example, if they are
short and borrow to cover this, they remain short (with a borrowed position).
Trade 1 produces an Agent/Depository instruction in MT 540 / 542 format.
Generally this is FOP, but this may also be DVP transactions. For all SBL
transactions, it must be possible to suppress the broker, depository messaging
with a flag on the transaction with BR/DEP.ADVICE.REQ type fields. No
depository messaging is required for trade 2, as this is an internal trade and we
are only switching between security positions wash – customer. Trade 2 booking
will tell us not only client, but also portfolio (where long and short portfolios are
held for the client).

The traded borrows and loans may or may not offset each other
The “own book / wash control” portfolio indicates where there are differences
by the presence of a position.
Can have settlement differences, which would arise because, for example,
although T2 has settled contractually or actually (using AUTO.CUS.SETTLE),
T1 is still unsettled.
T2 returns will be received with instructions as to which position should be
returned (in the case of multiple borrows making up the borrowed position).
P&L between Trade 1 and Trade 2 will be calculated outside the scope of T24
functionality. Fees are calculated outside the scope of T24 functionality.

T24 Securities Straight Through Processing Module (SP) has been designed to
achieve Straight Through Processing (STP) with the set of ISO 15022 messages
introduced by SWIFT. Straight Through Processing is the next step in the
evolution of Banking systems for the Securities industry. Delivery setup for both
outgoing and incoming message processing handled in T24
SWIFT categorises ISO 15022 messages as
Trade Initiation and Confirmation messages (TIC)
Settlement and Reconciliation messages (S&R)
Corporate Action messages (CA)
In addition the T24 Securities Straight Through Processing (SP) module
supports:
Trade Initiation and Confirmation messages (TIC)
Settlement and Reconciliation messages (S&R)

In order to achieve STP once an order has been authorised, in certain cases T24
should automatically accept any override generated at the trade level. These
overrides should be automatically accepted by T24 and merely recorded on the
trade for audit purposes. This needs to be parameterised by entity, application,
message, originating entity and portfolio .

The various type of SWIFT messages for SEC.TRADE are MT540 Receive
free, MT541 Receive against payment, MT542 Deliver free and MT543 Deliver
against payment.
For SC.SETTLEMENT transactions MT544 Receive free confirmation, MT545
Receive against payment confirmation,MT546 Deliver free confirmation and
MT547 Deliver against payment confirmation.

Some brokers send aggregated MT 515 messages. The aggregation is mainly
done for administrative convenience and for lowering the costs as there will be
fewer SWIFT messages and fewer settlements. The messages are grouped by
certain pre-defined criteria and only one message is sent by the broker per
group. The use of aggregated messages introduces the need for reconciling the
aggregated messages with the pre-execution messages (MT 513) received from
the broker and their underlying transactions.
As a consequence of this aggregation, the settlement instructions sent to the
custodian (MT 541 – Receive against payment, MT 543- Deliver against
payment) will also be aggregated. When settlement status (MT 548) and
confirmation (MT 545 or MT 547) is received from the custodian, they’ll have
to be disaggregated and reconciled with the underlying trades in the system
before updating the status/processing settlement for individual trades.

The system can handle aggregated trade confirmation messages received from a
broker if TRADE.AGGREGATION field is set to YES in
CUSTOMER.SECURITY record for that broker. The broker, in this case, will
send one MT 515 message for a number of trades having the same grouping
parameters. Once an aggregated message is received, it has to be reconciled
with the pending trades pertaining to these confirmations.
The aggregation of MT 515 will be based on the following grouping parameters:
Broker;
Security Number (Instrument)
Transaction Type – Buy/Sell;
Trade Currency;
Trade Date;
Settlement (Value) Date;
Depository;
Delivery Instruction; and
Stock Exchange

Once an order is executed and SC.EXE.SEC.OREDERS authorized, a record
will be created in SP.AGGREGATION (the ID of aggregation record will be the
SEC TRADE ID).
It must be noted that a record will be created in SP.AGGREGATION only for
trades where an allocation instruction (MT 514) is not required to be sent to the
broker. In case of transactions where allocation instructions are sent, an
individual confirmation (MT 515) will be received for each allocation sent. It
must also be noted that the back-dated transactions will not be included for
aggregation and as a result will not be updated in the aggregation table and the
reconciliation table. The confirmations for these transactions have to be handled
either manually or based on individual confirmation (MT 515) received from
the broker.

SP.AGGREGATION record snapshot is shown in this slide. Please look at the
details captured in this record

A record is then built in the reconciliation table (SP.RECONCILIATION) based
on the aggregation parameters specified. If a record already exists for the group
(the ID of which will be the concatenation of the aggregation parameters
specified), the quantity and amount details are adjusted to reflect the new
transaction being added to the group. If no record exists for the group, a new
record is created. The transactions will be added to the reconciliation record till
the time the status of the reconciliation record is changed to ‘MATCHED’ or till
the Cut-off time set, whichever is earlier.

In order to allow for small discrepancies in amount, tolerance levels can be
provided. The tolerance (expressed in percentage terms) will be specified in the
CONF.TOL.PERC Field in CUSTOMER.SECURITY. If there is a difference in
the amounts between the incoming message and the reconciliation record and
the difference is within the tolerance specified, the status will still be set to
‘Matched’ but the status narrative will be updated as ‘MTCHTOL’.
If there is a record with the same grouping parameters in ‘PENDING’ status,

reconciliation is then attempted. If there is no match, the status of the group will
be changed to “Unmatched” and the reason for reconciliation failure will also be
updated. The reason could be either Matching record for the group not found or
Quantity not matched or Amount not matched
For manual reconciliation, RECON.NOMINAL and RECON.AMOUNT will

have to be entered in SP.RECONCILIATION. If this matches with the nominal
and amount in the reconciliation, the status will be set to ‘MATCHED’ on
authorization of this record

SP.RECONCILIATION record snapshot is shown in this slide. Please look at the
details captured in this record

If the flag for settlement instructions is set for aggregation, the settlement
instructions to be sent will be aggregated. The aggregation pertains only to MT
541/543 messages and not the free of payment transactions (MT 540/542). With
aggregation, the settlement instructions will not be generated from the
individual transactions. Once the reconciliation of MT 515 is performed, a
consolidated settlement instruction will be generated. The sender’s reference on
the settlement instruction will be the MT 515 ID as stored in the reconciliation
record.
Consequently, the incoming settlement status messages (MT 548) and the
settlement confirmation messages (MT 545/547) will also be aggregated. Based
on the reference in the incoming message, the reconciliation record will be
identified.
If there is a match against a reconciled record, the status as in the incoming MT
548 message is updated for all the underlying individual trades.

If there is a match against a reconciled record, the status as in the incoming MT
548 message is updated for all the underlying individual trades.
As regards settlement confirmations, in case of a match, the underlying
individual trades will be identified and settlement processed for each trade. In
case of full settlement (nominal and quantity in the settlement instruction
matches with the nominal and quantity settled as per incoming message), the
settlement records pertaining to each trade is updated and settlement completed.
In case of partial settlements, the settlement of individual trades will be on a
pro-rata basis.

You have now learnt how to set up parameter and static files related to
settlement and corporate action processing in the securities module. You have
also learnt how to input transaction and processing of settlement and corporate
actions. You have also learnt how to set up charges and tax related to the
activity. You have also understand accounting and various delivery messages,
interpret valuation of position, process and interpret valuation of portfolios and
to set up safe custody and management fees.


T3TSCO - Securities Back Office - R13 1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

T3TSCO - Securities Back Office - R13 1

Загружено:

Авторское право:

Доступные форматы

T3TSCO - Securities Back Office - R13.

T3TSCO - Securities Back Office - R13.1 2

T3TSCO - Securities Back Office - R13.1 3

T3TSCO - Securities Back Office - R13.1 4

T3TSCO - Securities Back Office - R13.1 5

T3TSCO - Securities Back Office - R13.1 6

T3TSCO - Securities Back Office - R13.1 7

T3TSCO - Securities Back Office - R13.1 8

T3TSCO - Securities Back Office - R13.1 9

T3TSCO - Securities Back Office - R13.1 10

T3TSCO - Securities Back Office - R13.1 10

T3TSCO - Securities Back Office - R13.1 11

T3TSCO - Securities Back Office - R13.1 11

T3TSCO - Securities Back Office - R13.1 12

T3TSCO - Securities Back Office - R13.1 14

T3TSCO - Securities Back Office - R13.1 16

T3TSCO - Securities Back Office - R13.1 16

T3TSCO - Securities Back Office - R13.1 17

T3TSCO - Securities Back Office - R13.1 18

T3TSCO - Securities Back Office - R13.1 19

T3TSCO - Securities Back Office - R13.1 20

T3TSCO - Securities Back Office - R13.1 21

T3TSCO - Securities Back Office - R13.1 22

T3TSCO - Securities Back Office - R13.1 23

T3TSCO - Securities Back Office - R13.1 24

T3TSCO - Securities Back Office - R13.1 25

T3TSCO - Securities Back Office - R13.1 26

T3TSCO - Securities Back Office - R13.1 27

T3TSCO - Securities Back Office - R13.1 28

T3TSCO - Securities Back Office - R13.1 28

T3TSCO - Securities Back Office - R13.1 29

T3TSCO - Securities Back Office - R13.1 30

T3TSCO - Securities Back Office - R13.1 31

T3TSCO - Securities Back Office - R13.1 31

T3TSCO - Securities Back Office - R13.1 32

T3TSCO - Securities Back Office - R13.1 33

T3TSCO - Securities Back Office - R13.1 34

T3TSCO - Securities Back Office - R13.1 35

T3TSCO - Securities Back Office - R13.1 36

T3TSCO - Securities Back Office - R13.1 37

T3TSCO - Securities Back Office - R13.1 38

T3TSCO - Securities Back Office - R13.1 39

Override messages is generated if different accounts not belonging to the

MIN.MAX.CCY field specifies the currency in which the associated minimum

T3TSCO - Securities Back Office - R13.1 40

T3TSCO - Securities Back Office - R13.1 40

T3TSCO - Securities Back Office - R13.1 41

T3TSCO - Securities Back Office - R13.1 42

T3TSCO - Securities Back Office - R13.1 43

T3TSCO - Securities Back Office - R13.1 44

T3TSCO - Securities Back Office - R13.1 46

T3TSCO - Securities Back Office - R13.1 48

T3TSCO - Securities Back Office - R13.1 49

T3TSCO - Securities Back Office - R13.1 50

T3TSCO - Securities Back Office - R13.1 51

T3TSCO - Securities Back Office - R13.1 52

T3TSCO - Securities Back Office - R13.1 53

T3TSCO - Securities Back Office - R13.1 54

T3TSCO - Securities Back Office - R13.1 55

T3TSCO - Securities Back Office - R13.1 56

Customer Suspense account Cr. 10,200

T3TSCO - Securities Back Office - R13.1 57

T3TSCO - Securities Back Office - R13.1 75

T3TSCO - Securities Back Office - R13.1 76