Securities Administration
Securities Administration
Securities Administration
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Table of Contents
Overview.................................................................................................................................................. 4
Products ............................................................................................................................................... 4
Setup ....................................................................................................................................................... 5
[Link]................................................................................................................................. 5
[Link] .............................................................................................................................. 11
[Link] ........................................................................................................................ 12
Other parameter files ......................................................................................................................... 14
Static Processing ................................................................................................................................... 16
[Link] ................................................................................................................... 16
Broker and Counterparty ................................................................................................................ 17
Depository ...................................................................................................................................... 18
[Link] ........................................................................................................................... 20
Default Depository at Portfolio Level .............................................................................................. 22
Linking of Portfolio’s ....................................................................................................................... 23
[Link] ......................................................................................................................... 25
Minimum Holding............................................................................................................................ 27
Blockage of all Activity in one Security........................................................................................... 28
Cum and Ex Markers...................................................................................................................... 28
Automatic Bond Rating................................................................................................................... 29
Price changes for Securities .......................................................................................................... 30
Bonds with Factors ......................................................................................................................... 31
Deal/Transaction processing ................................................................................................................. 34
[Link] records ......................................................................................................... 34
[Link]................................................................................................................... 35
Stock Record ..................................................................................................................................... 36
[Link] ................................................................................................................... 37
[Link] ........................................................................................................................ 38
[Link] ........................................................................................................................ 39
DIARY / ENTITLEMENT ................................................................................................................ 39
ENQUIRIES .................................................................................................................................... 39
Posting of unrealised profits and losses ............................................................................................ 40
Trade Date posting Realised and Unrealised Profits ......................................................................... 41
Accrual and Amortisation of Discount and Premium ......................................................................... 48
Setting up “DISCOUNT” Processing .............................................................................................. 49
“DISCOUNT” Portfolios .................................................................................................................. 49
DISCOUNT Processing - LINEAR Overview ..................................................................................... 51
DISCOUNT Processing - [Link]....................................................................................... 53
Overview
The T24 Securities Module (SC) has been designed to enable the processing, maintenance and
control of trade, settlement and custodial functions on behalf of your Institution and, if applicable, your
customers. The Securities Module contains a comprehensive Portfolio and Investment Management
application, which in turn enables account and/or fund managers to provide a full range of services to
private clients. You may obtain details of the Portfolio Management application by reference to the
chapter dedicated to Portfolio Management.
There are numerous enquiries and on-line reports available. A selection of these will be described at
the end of this chapter.
Products
The Securities module is able to process a wide variety of negotiable instruments. Many of the
characteristics of certain security types have been parameterised to enable the easy addition of new
instruments as they are encountered.
Amongst the product types that can be processed are the following:
It is fairly straightforward adding new instrument types as and when required by specifying the various
processing “rules” associated with each.
Setup
There are several different means of processing movements of securities within the system. The
following sections show the parameter files, which must be completed prior to your being able to use
the facilities available within this module. Later in this document, there are examples of some of the
various transactions.
The complex nature of the SC Module necessitates the completion of a large number of parameter
files. These files contain basic information such as defaults, processing rules and accounts to be used
to record various profit and loss details. Most of the parameter files cannot be set-up prior to
installation as they are accessible only through the “id” of the User Company. TEMENOS Client
Services Group staff are always pleased to provide you with assistance and guidance at all times
during the setting-up of your System as some field responses once accepted by the System, cannot
be modified.
The following section lists the parameter files and indicates their usage. You will only be able to
examine, set-up or amend these files if your COMPANY file specifies that your organisation is
registered to use the SC application.
It is vitally important that you familiarise yourself with these files as they play a major role in how the
System performs various tasks and processes, sometimes on-line and sometimes during the various
overnight processes.
[Link]
The [Link] is the main securities application parameter file. To be able to use the T24
securities application, a [Link] file must therefore be completed for each company using
the System.
When completing this file for the first time, you should familiarise yourself with each field, referring to
the HELPTEXT where necessary, so that you ensure that you configure the Securities application to
enable your organisation to benefit in the best way possible.
[Link] record.
As can be seen by reference to the above extract, the [Link] file controls, amongst other
facilities, the default valuation routine required and the id of the local stock exchange (though this will
first have to be set-up on the [Link] file).
Please refer to the T24 Portfolio Management Application user guide for greater in-depth description
of the available valuation processes.
The [Link] file is quite large and will necessitate your moving on to a second or third
screen, depending upon your particular set-up, to enable you to input additional information.
[Link] record(Cont).
The above extract shows the second screen of a typical [Link] file. You will see that,
included in the information required, is the facility enabling you to specify the numbers of transactions
required before T24 background bulk processing becomes available.
This function enables you to, for example, enter extremely large transactions that may contain, say,
hundreds of individual customer purchases or sales of securities and releases your session to enable
you to continue work while the transaction is handled in the background.
Also contained in this parameter file and worthy of description are the [Link] and the
[Link] fields. The former enables you to effectively define the main id for the
[Link] file in which you record details of the various securities in which your
organisation performs trades. The default format, which you can configure simply by hitting the <CR>
key over the field, is ######-### which will enable you to use the Telekurs securities pricing system
identification numbers.
Whether you wish to use this format or define one of your own, you can only use “#” and “-“ characters
where the “#” character indicates a numeric equivalent and the “-“ will form part of the id. Thus, a
response of the default would enable you to define a security id as “000001-000” which you would be
able to access using “1”. Note that once you have authorised the [Link] file, this field
cannot be changed. If you are not using Telekurs, then you may simply define the key as all numeric -
up to 12 characters are allowed.
The latter field, [Link], enables you to specify an alternative means of accessing
individual security records for examination or entry into any of the various transactions and enquiries.
We have already discussed how the main id is controlled by the definition of the [Link].
Now, say, your staff also very frequently use the EUROCLEAR Clearance System to effect
settlements and they are used to the ids within that operation, you can use the [Link]
to enable the usage of that particular id, as well as the main id.
You can specify either of the following fields, all of which reside on the [Link] file:
Please refer to the HELPTEXT for field-by-field guidance. If there are any mandatory fields requiring
completion before you can affect input, you will be gently prompted to supply the missing information.
Some fields will require the specification of a category or a record from another file. Where possible,
the System will have been delivered with a basic selection already provided. For example, if you
wished T24 to perform price integrity checking on certain asset types, then the field [Link]
would require completion by you specifying the valid [Link] record.
Should you be using the [Link] application and wish T24 to raise automatically
any DIARY transactions during the Close of Business batch to enable maturity of bond type securities,
you should specify which [Link] should be used for this function by entering the appropriate
type into the [Link] field.
To enable automatic processing of bond coupons so that they are recorded as being due and also to
enable the coupon dates to be cycled, you should enter the appropriate [Link] allocated to
this task into the [Link] field. If this field has been updated then DIARY records will
automatically be created by [Link] and [Link] instead of [Link]
(the non-Corporate Actions coupon process) records.
The [Link] field on the [Link] file allows the user to control the update of
the capital gains transaction base. On setting this field to a value of 'YES' the system will maintain a
transaction base that may be used to show the capital gains positions on portfolio trading in a security.
[Link] record.
The field [Link] can be used to control the accounting generated from the system and accepts
a value of ALL or NULL.
When this is set to ALL then all account postings generated from transactions from all the SC
applications (including corporate action events) will be to be posted on the value date, these
transactions will be included in the start of day batch on the value date.
The close of business batch will then ignore these entries posted during the start of day, but will pick
up any transactions that have not been included, for example transactions entered on their value date.
The fields SOURCE TAX SPLIT and LOCAL TAX SPLIT can be used in conjunction when
processing Corporate Action events. If these fields are set to “YES” then separate Source/Local Tax
accounting entries will be posted. The customer will be posted with the gross amount for the cash
entitlement and a separate Source/Local tax amount.
The field [Link] can be set to “SINGLE” or “MULTIPLE”. If this field is left blank
then the system will assume “SINGLE”.
For a more detailed explanation of how this field and its associated files work please see the
appropriate section in the [Link] User Guide.
The [Link] field determines whether the [Link] that is created in hold status
from the order processing (directly from Order in case of traded orders and from
[Link] in case of transmitted orders) would have all the default charges and
commissions populated. The trade charges are currently computed at the field level in the transaction
or while committing the trade.
If the charges are calculated at the order or execution stage, these are then carried forward to the
trade that is created from order execution processing. Setting this field to “YES” would enable
population of the charges in the trade that is created (in IHLD status) from the order execution
processing even if no charges are computed at the order entry or execution stage.
The field [Link] controls whether the Bank can lend Share and Bonds as specified by the
[Link] record when using the application [Link]. If set to “YES”
then it is permitted to lend both Shares and Bond, if set to “NO” or left NULL then only the lending f
Bonds will be permitted.
[Link] record.
The above field descriptions are only a small selection of the total fields in the [Link]. All
fields in this parameter file can be configured individually to suite the banks implementation
requirements and achieve the desired results.
The onsite implementation team will be able to assist with any further detailed descriptions and
functionality.
[Link]
The [Link] file is used to store [Link] related parameters that are
shared across companies, only one record is allowed with a key of SYSTEM.
[Link] record.
The [Link] field denotes if Cum and Ex markers are to be in Swift format or not.
The linking together of Cum and Ex markers is handled using the [Link] and [Link]
fields, however input to these fields is only allowed if the [Link] field is set to “Swift”.
Input to these fields is validated against the [Link] to ensure Swift compatibility.
The field [Link] controls the level of duplication allowed in the fields I.S.I.N.,
[Link], [Link], [Link], [Link] and [Link] which can be defined as
alternate indexes.
If this field is set to blank or 001 then duplication of the index keys will be allowed but only one security
with a suffix of -000 will be allowed per index key. For example 100147-000 and 100147-001 could
share the same I.S.I.N. code but 100147-000 and 100148-000 cannot.
If the field is set to NO then a one to one relationship between the [Link] key and the
alternate index key must exist. No duplication will be allowed in any of the fields.
If the field is set to YES the no checking will be performed on the index keys and they may be used
any number of times on any number of [Link] records.
If the field is set to OVERRIDE then an override message will be produced if the key is already used
and acceptance will allow duplication.
The field [Link] determines whether the ISIN code entered through the
[Link] application is validated. If this is set to YES then the check digit must be as
calculated by system.
[Link]
The [Link] file advises T24 how to process a basic [Link] transaction.
This record rarely requires modification once it has been satisfactorily configured.
As shown below the initial fields contain many CATEGORY and TRANSACTION codes which relate
to debit and credit transaction entries that will be posted during trade capture.
The latter parts of the record, as illustrated in the previous screen extract, deal mainly with processing
rules, which also assist during trade entry.
For example, it may be a requirement to have the [Link] (security trade) transaction default
the security price from the [Link] file in every case. Alternatively, you may decide to
make it a manual process to be specifically input.
In the case described, the [Link] field should be set to “Y” if you wish T24 to default the
trade price from the [Link] file. This facility is only feasible where you can be
absolutely certain that your security files are up-to-date with regard to the latest pricing information.
This would only be the case if you had recently modified a price manually or your organisation obtains
pricing details from an automated third party system such as EXSHARE. If you cannot be sure, then
this facility can be used instead when you are processing a bulk [Link] necessitating a large
number of customer transactions all to be entered containing the same price.
To this end, the [Link] field can be changed to “Y” and then back to “N” once the
transaction has been successfully entered into T24. Remember you will need to change the price on
the relevant [Link] record to that which you wish to have defaulted - this also may be
changed back to the current price once the [Link] has been entered.
It goes without saying that if you use this facility to default a required non-current price, then you
should also ensure that no-one else on the System is likely to be entering other trades in the same
security.
This process, as are many of the various options available, is controlled through the usage of a simple
Yes/No flag to be entered into the relevant field. Some can be changed when required but some
cannot. Always refer to the HELPTEXT to ensure that you make the correct decision.
If your particular organisation regularly performs bulk security transactions (i.e. those containing a
number of customer trades in a single transaction) then you may wish to utilise a further feature
available with regards to any foreign exchange requirements arising from the transaction. The
[Link] field on this file can be set to “Y” or “N” to indicate whether or not you wish T24 to
total the currency requirements of each customer into a single amount for which a consolidated rate
can be obtained from the Forex dealers and entered into the [Link] field of the [Link]
transaction.
Setting this field to “Y” to enable consolidation will prevent you from entering specific rates for each
customer on the [Link] itself in the [Link] field. You can obtain further details in
the section of the user guide, which describes the [Link] application.
If the [Link] is set to ‘Y’ then the current system time (in [Link] format) will be
defaulted into any time fields within the order processing programs of [Link],
[Link], [Link] and [Link]
In this way you will ensure that they correctly reflect the way in which your Organisation and your
branches and subsidiaries wish the System to respond to each transaction type and as to the
selection of accounts relating to each transaction.
Since these types of parameters generally govern the way particular transactions and their respective
accounting entries are processed, you can, if you need to, change some of the information after you
have commenced “live” running.
Static Processing
[Link]
Before you can use the Securities Module, it is necessary to identify the customers with whom the
various day-to-day security activities will be performed. To do this, it is necessary to ensure that at
least one standard CUSTOMER record exists in T24 for every securities customer.
Once a CUSTOMER record exists, you need to advise the Securities Module as to the capacity (or
capacities) in which the customer is acting. This is done through the use of the
[Link] file.
This file defines the capacity in which the CUSTOMER acts in relation to your organisation. The
screen extract that follows shows how a typical record may look.
Before you can commence securities activities with anyone, you must ensure that both a
CUSTOMER and a [Link] record exist.
While you are working in the Securities Module, T24 will tell you if a particular customer has yet to
have a [Link] record set-up. At the same time, checks are made to ensure that
the role or roles that have been defined in the [Link] fields of the
[Link] record are compatible with the particular activity required. For example,
you will not be able to enter a customer into a broker field if the record is only set-up to be a customer
when you are entering security transactions.
It is quite possible for a particular customer to require more than one role. For example, you may
effect security transactions with another party who may, on occasion, act as a depository for some of
your Organisation’s securities. You may define any number of the following roles:
Role Description
CUSTOMER This type will enable you to open portfolio account into which to buy, sell,
hold and maintain securities on behalf of that particular customer.
Please refer t the section describing the [Link] file usage
later in the next section of your guide.
COUNTERPARTY Enables you to enter non-broker trading entities into the broker field of
any security transactions.
BROKER Enables you to enter brokers into the broker field on security
transactions.
DEPOSITORY This role enables you to enter or have defaulted, the depository
locations for delivery and receipt of securities within a trade.
CLIENT With this setting no [Link] record is required, but trading
of securities is still allowed. Cash is sent / received via other means.
However, the values [Link], MEMBERSWX and OTHERTRADER are not used by the
core system and only used to interact with local developments.
At the end of the day, a report is produced to show all the transactions that were undertaken with an
unauthorised broker. This report is an enquiry called [Link] which can be run as a
stand alone enquiry intra-day. It has also been added to the BATCH record BNK/[Link]
under the [Link] and DATA field and will be produced during the Close of Business.
It uses [Link] and [Link] records of the same name.
Depository
If you need to set-up a depository record, you can also advise T24 whether you wish the Corporate
Actions Module DIARY and ENTITLEMENT to monitor the securities held therein for any
[Link] records, which may be eligible for benefits. You can also specify the
commission types, which your Organisation is charged by the depository, if you know them, referable
to the Corporate Action types. These charge types must exist in the [Link] file
and on the Corporate Actions [Link] file.
The following extract will provide you with an example depository record:
Certain field validation is returned by the system based on the values populated in field
[Link]. For example [Link], [Link] and [Link] among
others can only be populated for a record that is defined as a depository in the [Link] field.
[Link]
This file is used to record individual portfolios within the Securities Module. A portfolio is created using
the standard customer number as recorded on the CUSTOMER file. To this must be added an suffix
extension to identify the actual portfolio. The format is therefore CUSTOMER-1 to indicate portfolio 1 or
CUSTOMER-123 to indicate portfolio 123 for that client.
In this way, up to 997 individual portfolios may then be linked to a single CUSTOMER. Note that
extensions 777 and 999 are reserved - you can obtain explanatory details by reference to the T24
user guide covering Portfolio Management.
The above extract illustrates how a typical [Link] might define the name for an “own
portfolio” which may be required if your organisation performs securities activity for its own account.
A portfolio that has been opened for usage by the organisation for its own securities is very different
from one that may have been opened for a private customer. For private customer portfolios, you need
to specify certain information such as each customer’s selected financial accounts that are to be used
when purchasing and selling securities and also for the distribution of dividends and other corporate
activities.
An own portfolio requires the specification of categories to which to post the various accounting entries
normally associated with securities activity - for example, trading and revaluation of profit and loss,
interest income and expense. In addition, you also have to specify information such as whether you
wish to post revaluation profits, losses or both rather than simply report them. Please refer to the help
text associated with each field for full details as to the various options, which are available and might
be applicable to your particular organisation.
Note that you can only define an own account portfolio if you enter the customer number, which you
will have set-up for use as the portfolio in the [Link] field on each [Link],
which you open for the purpose.
This fact is illustrated in the following extract, which shows how a typical [Link] may
look for a dealer book:
Once you have indicated that the record being opened is an internal portfolio, then most of the fields
immediately following the [Link] field, becomes mandatory. These require details such as
CATEGORY codes to which to post specific accounting entries and define some processing rules.
The extract above shows the last screen of a typical own portfolio in which various rules are defined
such as whether to post unrealised (revaluation) profits and losses (or both) into the accounts together
with the frequency at which to perform the revaluation.
In [Link] you can define fields to default a specific depository on the application
[Link] or [Link].
They are part of a multi value group and within this multi valued group, the fields [Link],
[Link] and [Link] can be expanded as a multi sub-value set.
Input to [Link] is restricted to records that are defined as DEPOSITORY in the field
[Link] on the [Link] file.
Input to [Link] has to be an operand. A drop down list shows the operands that can be used.
They are: EQ – Equal to; GE – Greater than or equal to; GT – Greater than; LE – Less than or equal
to; LT – Less than NE – Not equal to.
Once a [Link] or [Link] is input, the system will validate to see if there are any
values in these decision fields. Once a valid check is retuned then the depository defined in
[Link] will be defaulted on the contract.
If the return value is not valid, current functionality is assumed.
In the above example once the [Link] record has been input the system will validate
the [Link] portfolio record of the customer number and check for the above fields.
If the [Link] of the [Link] is less than or equal to 10 and the [Link]
is equal to GBP, then the depository defaulted in the contract will be CUSTOMER ID 100169.
Otherwise, we move onto the next multi value set of fields.
If the [Link] on the [Link] is greater than 10 then the depository record
100317 will be defaulted.
If none of the above match then current functionality will be assumed.
Linking of Portfolio’s
The concept of linking [Link] records together to form joint ownership is shown below.
• [Link] – This field will be used to denote the customer(s) that are joint holders of
the portfolio and must be the key to an existing CUSTOMER record.
• [Link] – This field will give the relationship of the joint holder to the primary holder
and must be an existing record in the RELATION application.
• [Link] – This is a free text field for the customer to enter their own details
[Link]
The [Link] file contains most of the information relative to each security on the
System. It is here that the various security transactions obtain the latest information concerning the
instrument featuring in the transaction. For this reason each file must be kept as up-to-date as
possible especially with regards to variable rate instruments so as to ensure that the interest rate
entered is in fact the latest rate.
Most master files can safely be ignored once set-up. For example, fixed rate bonds and ordinary
shares require very little maintenance once a new record has been authorised. In respect of the fixed
rate securities, T24 will automatically update the last and next coupon dates using the frequency
indicator to build the new coupon period details. However, you may wish to keep share type master
files updated with ex-dividend information although whether you add this information or not, you can
enter the complete details when completing Corporate Action DIARY records thereby enabling T24 to
process dividends due automatically.
In addition, T24 always provides reminders in cases where a security is nearing maturity, a coupon
date or when nearing a change of coupon rate for variable interest paper. The frequency and period in
advance for which you wish to be informed of any event is also under your control. It is also possible,
from this file, to block a security from a given date should it become necessary. This will prohibit any
form of activity, be it trading, transfer or any type of corporate action.
T24 uses a very high level indicator to differentiate between BOND and SHARE type paper within the
[Link]. The amount and type of information required to build a complete security
master record depends largely upon whichever indicator is chosen.
The screen extract that follows illustrates a typical example of a [Link] record in
respect of a fixed rate bond having equal coupons each year. You should note that this particular
screen uses a version of the standard master file transaction where the display comprises only those
fields that are relative to a bond type security.
Unless you use VERSION records, you may find that sometimes your display may comprise of 5 or 6
screens.
VERSION may also be used to logically group together related fields instrument-by-instrument type
as required. Please refer to the T24 user guide covering the usage of VERSION for more detailed
information.
The following screen extract shows how a typical [Link] record may appear once
successfully set-up.
The use of a VERSION to specifically show bond type securities ensures that important and logical
fields such as current coupon rates and periods can be shown. A VERSION designed to enable input
and examination of share records could very easily exclude these fields. In addition, there may well
exist information relating only to share type securities, which could be added to the display. For
example, the [Link] field that is used to indicate whether the shares are issued in bearer
or registered form.
Minimum Holding
The [Link] file allows the specification of a minimum nominal that a portfolio should
have in the stock represented by that [Link] in a field called [Link].
The multi value field [Link] on [Link] contains the transaction codes that
the minimum holding validation will be processed against.
As seen above [Link] contains SPR (Securities Purchase) and SSL (Securities Sale) so
when a [Link] that used SPR for the purchase or SSL for a sale of a security would validate
against the minimum holding for the particular security and give a suitable OVERRIDE message. If
the [Link] field is left blank then no minimum holding validation will take place on the
system.
Example :-
If the [Link] field is populated with 200,000 and you try to buy 100,000 of the stock
through [Link] using SPR, the application will check if your total holding for that security in that
portfolio meets or exceeds the minimum holding requirement. In the above case, if you already have
100,000 or more, then your total position for that security in that portfolio meets the minimum
requirements, If not, it produces an override message.
Similarly, when you try to sell the stock, if the total position for that stock in that portfolio falls below the
minimum holding requirement, an override message is produced.
The only exception to this is if you are trying to sell off all of one stock in the portfolio i.e. if the position
for that stock in that portfolio after selling will be zero. In that case, no override is produced.
By entering a date into the [Link] field on [Link], the security will be
prohibited from any type of transaction from that date. The [Link] field can then be
populated with a free format text.
The price of a security is affected by Cum and Ex periods and the field [Link] allows
these markers to be indicated on the [Link] record.
Entry to this field is validated against the [Link] file, if the [Link] field is
set to “Null” then only single value input of “Null” or “xd” will be allowed. If however the field is set to
“Swift”, then multi-value input will be allowed and the values can be any of those in the
[Link] and [Link] fields providing they are not opposites within the same multi-
value set. i.e. a price could not be both cum and ex dividend (CDIV and XDIV) at the same time.
Historic details of the price conditions for a date are stored on the [Link] application.
This application is automatically updated with the values in the [Link] fields on
[Link], whenever the [Link], [Link] and [Link]
fields are updated.
The application [Link] can be used to identify the rating of a bond or particular
[Link] file. The ID of this record is limited to 5 characters only.
As seen above the field [Link] can accept a value of DEFAULT, GOOD,
SATISFACTORY, STRONG or WEAK.
The field [Link] if required can be linked to an [Link] table like the one
shown below.
On the [Link] the RATING field is used to describe the rating of a bond. Any input to
this field has to be defined on the [Link] file.
The [Link] field is used to identify the source of the bond rating recorded and is restricted
to 2 options. Either Manual or Automatic. Manual suggests the rating was manually input by the user,
and Automatic suggests the rating was received via an external source. This is shown below.
It is also possible to control the input of historic prices and income on [Link] using the
application [Link] the fields [Link] and [Link] allow
inputs of ‘YES’, ‘NO’ and ‘OVERRIDE’. When a historic price, income or accumulated income is then
input using the [Link] file, the input is either, disallowed, allowed or allowed upon the
acceptance of a warning message.
[Link] screen.
Mortgage backed securities include such issues as Government National Mortgage Association paper
(GNMA) also known as Ginnie Mae.
In order to allow for processing requirements of the Ginnie Mae securities the following processes take
place T24:
The [Link] file field FACTOR enables the specification of historical and current factors.
Brady bonds, such as Brazilian “C” securities require, in addition to the specification of the factor, a
capitalisation rate.
In order to allow for processing requirements of Brazilian C Bond the following processes take place in
T24:
1. Specification of a capitalisation rate for bonds to enable the system to calculate the capitalised
interest and coupon interest accrued.
2. Ability to factor up the consideration calculated.
3. Ability to factor up the interest calculated.
4. Ability to factor up the valuation amount.
The setting-up of a security for which a factor is part of the pricing process is different from that of a
standard bond. For example, you should leave the field [Link] empty. If you do enter a
rate, it will be overwritten using information you have to supply later. The reason for this is that factor,
interest and, if applicable, capitalisation rates are all stored separately for these instrument types.
The following [Link] extract illustrates the fields for which the additional information is
required.
Additional information fields in the [Link] record for bonds with factors.
The above extract shows how you would set-up a “Ginnie Mae” or most other mortgage backed paper
for which a factor and a current interest rate is required. The [Link] field is intended to store the
application from date. You will be required to enter the data so that the latest details are always
displayed first (i.e. in descending date order).
For “Brady” type securities, inform T24 of the capitalisation rate which is to be applied for the current
period. You will also need to record the historical rates if you require entering any back-value trades.
The following extract shows how a typical Brazilian “C” Bond may look once you have specified the
coupon date, coupon, capitalisation and factor rates.
You can see that for this particular security type, you should include the [Link]. T24 distinguishes
factor bonds from “ordinary” bonds if the FACTOR field is populated. Once that decision has been
made, the occurrence of a value in the [Link] field advises T24 the security is a Brady Bond type
whereas, if that field is blank, then the security is assumed to be Mortgage Backed security type.
Deal/Transaction processing
[Link] records
The latest up-to-date security positional details are stored in the aptly named [Link]
file. This is a T24 “live” file and as such 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 T24 user (own portfolio) or his customers. The file stores positions in both Average Purchase Price
and Weighted Average Price Basis.
[Link] enquiry.
It is from this file that a large number of T24 enquiries and reports obtain detailed information. For
example, the basic ENQUIRY, [Link] and [Link] both use this file from which to
extract the latest information each time they are run.
Your T24 System should already contain the basic ENQUIRY [Link]. This ENQUIRY,
together with many others, makes use of the [Link] file to extract securities
positional information according to the selection criteria specified.
The key to this file is quite complex as it is a T24 “live” file. It can be broken down into the following
components:
[Link]
The [Link] is another T24 “live” file containing additional information to that
contained within the [Link] described earlier. In this case, the component records
relate only to internal (own) portfolios and provide such information as realised and unrealised trading
profit and loss details.
[Link] enquiry.
As well as storing individual trading statistics, this file may be used to provide the data for any
ENQUIRY records and reports. This file is used to provide up-to-date information to the ENQUIRY
[Link] that you can use to supply you with holdings and performance details of your
organisation’s security positions including the latest unrealised P/L details (subject, of course, to the
latest prices being available to T24).
Stock Record
Stock record works as a stock register. All stock movement are updated using two files
[Link] and [Link]. With this functionality T24 has the ability to consider
broker / counterparty positions (that is the nominal and amount due to/due from the broker).This
functionality us activated if the [Link] field in [Link] is set to “US” and field
[Link] is set to “YES”.
When set broker / counterparty traded values will be recorded in the [Link] record
pertaining to the customer on the transaction.
The value of “US” in field [Link] will only be allowed if the [Link] field in
[Link] is set to “YES”.
[Link]
The broker / counterparty values will be updated by the following applications [Link],
[Link], REPO, [Link], DIARY and ENTITLEMENT, which
all have the ability to create [Link] records.
As is the case with Depository position, there will be no [Link] records for broker /
counterparty.
These broker / counterparty details would be maintained until the transactions are fully settled via the
[Link] application. Once settled, these would be removed indicating that there are no
unsettled positions (or due from/to the broker).
[Link]
[Link] is a live file, which records the movement of security per each application that
updatesa [Link] record. Any partial settlement that updates the
[Link] will create a new [Link] record.
The [Link] record does not have any positive or negative sign but is driven by the
[Link] field to find the long or short movement.
After full settlement of the [Link] record more [Link] records are created
to record the transactional flow.
[Link]
The [Link] record is another live file which will record the broker / counterparty
transaction values instead of depository on completion of the transaction.
The [Link] record for the depository will be created when settlement happens in the
[Link] record simulating securities settled by broker to depository.
DIARY / ENTITLEMENT
When a DIARY is input and authorised and the service agent activated the ENTITLEMENT records
are created in INAU status.
When these ENTITLEMENT records are authorised the [Link] records are created to
show the unsettled nominal or cash due from the depository. The depository id is mapped to the
[Link] field in the [Link].
ENQUIRIES
The system is set to TRADE DATE accounting for BOTH accounts and securities as can be seen in
the next extract –
Now, having run a COB [Link] below confirms the forward value date of the nostro entry.
The above entry confirms the forward [Link] of the [Link], (T24
LIVEDR asset update).
Now, upon checking the revaluation entry for the above position, we should see a [Link] of
today.
The contra entry of the revaluation suspense above indicates the spot entry posted to P/L as shown in
the next extract –
We will now simulate a sale of 50% the position. Although at the present time, both purchase and sale
are forward value, any resultant realised and revaluation profit/loss are still taken immediately.
After the COB, the previous day’s revaluation entry is reversed because the test account is set to
perform the I/O method of revaluations (revalue one day, reverse the previous day and revalue afresh
and so on) rather than ADJ (revalue one day, update the next by an adjustment up or down as
required).
As can be seen, the reversing entry takes place for value the next working day (in this case, 13th
November). This is replaced with the next day’s revaluation P/L.
Further, since a part of the forward position has been sold, the realised profit is also booked for today.
This is evidenced in the next extract.
Realised profit and loss will also update the [Link] and therefore a
[Link] is built to update the [Link] balance of the holding in the security.
This can be seen in the extract following.
This function enables a means of accruing into P/L the difference between the cost of a security asset
and its known future expected maturity/redemption value on a straight-line (LINEAR) basis or, in
certain cases, a compound basis. For example, a security bought for $995,000 and having a face
value of $1,000,000 with 100 days to run until maturity will accrue discount, on a linear basis, at a rate
of $50 per day ($1,000,000 - $995,000 / 100 = $50). You can obtain more precise details of the linear
and compound methods in those sections of your User Guide immediately following.
Although this accrual/amortisation process is usually confined to non-interest bearing security types,
T24 will also process discounts / premiums arising on bonds, Gilts and other similar interest bearing
securities provided that they are set-up to include an acceptable [Link]. ALL security types
requiring discount processing must also be traded over a portfolio which has been set-up specifically
to process discount / premiums if this is required. However, a portfolio may well contain both securities
which are candidates for discount processing and some that are not.
There are no restrictions as to portfolio type (e.g. investment or trading) provided that all are ‘OWN
portfolios’.
No attempt has been made to introduce this processing into customer portfolio valuations.
Using various parameters on the portfolio records it is also possible to revalue discount securities.
Special processing has been included so that T24 recognises that discount may exist still to be
amortised or has been accrued in respect of a specific [Link] depending upon
whether UPFRONT or NO-UPFRONT discount processing is required. (Details of these two
conventions are explained later in this section of your User Guide).
“DISCOUNT” Portfolios
Before T24 can perform the discount process, it is necessary to configure the portfolios to enable this
operation.
NOTE - You cannot change existing portfolios to perform this operation, only new portfolios can be
configured accordingly.
[Link]
This field is used to specify whether LINEAR or COMPOUND methods of discount accrual are
required. If left blank or “NONE” is typed then no special processing will be performed.
There are some restrictions on the usage of the compounding method. You can obtain more details in
the section “DISCOUNT PROCESSING - COMPOUND method”.
[Link]
This field is used to specify whether, for the portfolio, discount is to be posted UPFRONT and
subsequently amortised daily or whether a NO UPFRONT policy is required with discounts and
premiums to be accrued instead. Upfront methodology requires the underlying assets to be grossed
up to par/face value within the accounts, therefore providing the discount/premium amount to be
amortised via a contra entry. This process is performed automatically by T24.
Your response should therefore be “Y” if you require the underlying assets to be grossed up and
discount/premium to be amortised until eventual maturity of each security asset. Enter “NO” if you
would prefer to have the underlying asset carried at its original cost and have the difference between
that cost and the future maturity value accrued instead.
NOTE that it is possible to post discounts and premiums without daily accruals taking place. If
accruals are required then this must be specifically requested by setting the ACCRUE DISCOUNT field
(see below) to "Y".
[Link]
This field is used to specify whether or not your Organisation requires the accrual/amortisation of
discounts and/or premiums in respect of “own portfolio” holdings of eligible security types.
If this function is required, then you will be asked to complete the [Link],
[Link], [Link] and [Link] fields.
[Link]
This field will normally be set to “NO”. If it is set to “Y” then when a sale transaction is entered, if any
discount has been accrued/amortised prior to the sale, then a proportion of the provision amount is
calculated based on the quantity sold over the stock held. This proportional amount is then transferred
from the discount P/L to the trading P/L under the entry type “Discount Sold”.
Finally, you will now need to specify the category, which is to be utilised to build the daily accruals and
resultant accrual/amortisation entries in your Organisation’s P/L accounts. This should be entered in
the [Link] field and must fall within the range 50000 to 59999.
The above extract illustrates how a typical portfolio may be set-up to enable T24 to perform the
accrual of discount and/or premium over the remaining life of a security.
The former premium will inevitably reduce the effect of the future interest income whereas the latter
discount will have the effect of enhancing the interest income or, if the underlying security is a non-
interest type, then the discount is in fact the income. The effect of holding either security until eventual
maturity at which time the holder can expect to receive the full redemption proceeds would, under
normal circumstances, produce a final P/L amount equal to the original premium or discount amount
(in addition to the final coupon).
To eliminate this end maturity effect which results in large once only postings to P/L, your Organisation
can elect to amortise the premium or discount over the remaining life of the security. The following
examples attempt to show some simple scenarios involving a bond type security held in an “own
portfolio” requiring LINEAR processing of discounts and premiums and has been set to have the
positions grossed up to par value.
Let us assume that the example USD security has 10 day’s remaining life.
The T24 overnight processing will accrue 1 day’s discount which in this case is $1,000 / 10 days * 1
day giving $100 to be credited to the discount P/L account.
On the second day, a further purchase of the security has taken place. In this instance the accrual
comprises $1,000 / 10 days * 1 day (for the original purchase) plus $450 / 9 days * 1 day for the
second purchase giving a total accrual for the day of $150.
This daily process continues until final maturity at which time the provision and the position at its cost
will be removed (in conjunction with the required redemption/maturity entries.
T24 is able to process sales of all or part of a position as can be seen in the next example.
For the sale transaction, the realised trading profit entry is passed based on the normal method of
comparing the cost of the sale against the cost of the position price equivalent. In this case the
calculation is $60,000 * ((99.03333 - 99.25) / 100) giving $60,000 * .0021667 = $130.
The next step is the removal of the provision, which was accumulating in respect of that portion of the
position, which has now been sold. This is affected using simple pro-rating of the provision. In the
case of the example, we have a provision brought forward of $250 in respect of a holding of $150,000.
The over-provision is therefore calculated $250 / $150,000 * $60,000 = $100. The over-provision is
therefore moved to the trading profit and loss account.
The final step is to continue the discount accrual process with that day’s calculation. This is done by
taking the position at cost ($90,000 * 99.03333) $89,130 plus the provision so far accrued (the
remaining amount) of $150 to give $89,280. This is then subtracted from the maturity value of $90,000
to give a potential income of $720 over the 8 days remaining until maturity - $720 / 8 = $90 per day.
Assuming there were no further transactions through to maturity, the situation on that day would
therefore be as follows -
T24 does not actually post the entries in this way, those above being shown so as to provide an
understanding as to the concept of the process. The System is able to process premiums or discounts,
including those positions comprising purchases and sales of transactions containing both premiums
and discounts.
NOTE that as well as basic bond type securities, there are other security types which may be
processed within a portfolio having been set-up to perform accruals or amortisation’s of discounts or
premiums. However, T24 will only carry out this function if the underlying [Link] file
[Link] field has been set to enable this process (see next section).
Before T24 can perform discount processing on any instrument, the underlying [Link] record
as recorded on the [Link] file record for the security must be of a type enabling this
function.
The purpose of the [Link] file is to advise T24 how to calculate the proceeds of a transaction
or to revalue a position given the price supplied on a trade or by the [Link] file. For
example, T24 needs to know whether a price of 90 translates to £90 per unit, £0.90 per unit or 90% of
a nominal amount. These rules and certain others are recorded within this file.
Therefore to enable T24 to perform discount processing, there is a field [Link] on the
[Link] file which must be set to “Y” otherwise any securities held within a portfolio having
been set-up for this process will be ignored.
The above screenshot illustrates how a bond type [Link] file should be set-up so that T24 can
perform discount processing in a compatible portfolio. The important fields here are the
[Link] and [Link]. In order to enable the process, the
[Link] field must be set to “Y”.
The DPRICE calculation method is exactly the same as the standard PRICE method, which has
always been available to enable the processing of Bonds and similar instrument types. The exception
is that in this instance it advises T24 that discount processing is required, provided the underlying
instrument is held within a compatible portfolio. Further checks will ensure that you also enter “Y” in
the PERCENTAGE field and T24 will automatically add “Y” into the [Link] field as the
DPRICE method has been reserved for this purpose.
The DISCOUNT method is intended for usage in respect of non-interest bearing securities, which are
traded at a discount and subsequently mature at their face value. Here too, both the PERCENTAGE
and [Link] fields must be set to “Y”.
The YIELD method is also intended to be applied to certain interest and non-interest bearing securities.
As before, both the PERCENTAGE and [Link] fields must be set to “Y”. However, as this
calculation method can be applied to both interest and non-interest bearing instruments and therefore
T24 will need to be advised as to which particular one you are setting-up. This is done in the
[Link] field where you should enter either “E” or “I”. The former “E” indicates that the
underlying security is priced at a yield EXCLUDING interest. The latter “I” indicates the opposite in that
the underlying security is priced at a yield deemed to INCLUDE interest.
The following section attempts to illustrate some examples of the [Link] file setting-up.
Security with a face (maturity) value of $100,000 bought with 100 days remaining until maturity - dealt
at a discount rate of 5% using a 365-day calculation basis -
⎛ 5 ⎞
⎜ 100 x ⎟
⎜
Consideration = 100,000 x 1 - 100 ⎟
⎜ 365 ⎟
⎜ ⎟
⎝ ⎠
= 100,000 x (1 - 0.01369863013)
= 100,000 x 0.98630136987
= 98,630.14
[Link] record.
Note that the [Link] has been set to “DISCOUNT” representing the usage of the
formula above the T24 screen extract.
⎛ ⎞
⎜ Nominal Quantity ⎟
Consideration Amount = ⎜ ⎟
⎜ 1 + Days Remaining x Rate ⎟
⎜ ⎟
⎝ Year Days ⎠
⎛ ⎞
⎜ ⎟
⎜ ⎟
Consideration = ⎜ ⎟
100,000
⎜ 5 ⎟
⎜ 100 x 100 ⎟
⎜1+ ⎟
⎝ 365 ⎠
100,000
=
1 + 0.0136986013
100,000
=
1.0136986013
= 98,648.65
Note that the [Link] has been set to YIELD and that the [Link] has been
set to [Link] representing usage of the formula illustrated above this T24 screen extract.
2,182,500
= 2,005,823.84
⎛
1+ ⎜
8.6875 365 ⎞
x ⎟
⎝ 100 360 ⎠
2,005,823.84 + 182,500
= 2,011,176.23
⎛ 8.6875 365 ⎞
1+ ⎜ x ⎟
⎝ 100 360 ⎠
2,011,176.23 + 183,000.00
= 2,016,107.72
⎛ 8.6875 366 ⎞
1+ ⎜ x ⎟
⎝ 100 360 ⎠
Discount for the remaining 326 days of the 2nd year at 8.6875% =
2,016,107.72 + 182,500.00
= 2,038,257.71
⎛ 8.6875 326 ⎞
1+ ⎜ x ⎟
⎝ 100 360 ⎠
Note that the [Link] has been set to YIELD and that the [Link] has been
set to [Link] representing usage of the formula illustrated above this T24 screen extract.
Most of the fields in the [Link] records cannot be changed once the underlying record has
been authorised.
In addition to the more common pricing techniques used to cater for bonds and shares, it is
recommended that you ensure your System contains at least one each of the three pricing techniques
illustrated above whether your particular Organisation wishes to take advantage of the described
amortisation facilities or not.
The discount formula is the pricing technique used for such non-interest bearing instruments as
US$ Treasury Bills, Bankers’ Acceptances and Commercial Paper having a life of less than a year.
The yield excluding interest formula is normally used to calculate the consideration in respect of
Eurocommercial paper and Euronotes having a life of up to a year.
The yield including interest formula is used to derive the consideration in respect of both US and
Eurodollar certificates of deposit having one or more coupons during their lives.
The processing of Thai Bonds priced on a yield basis require a specific [Link] to enable T24
to select he correct calculation method required to derive at the cash consideration.
The formula used for the calculation is shown below:
For straight bond there is calculation of price and settlement amount as follows:
Calculated gross price (price including accrued interest) in term of percentage compares with par
value
Accrued interest in term of percentage is to be fixed decimal points not exceeding 6 points (round up)
by rounding 6th decimal point up if value of 7th decimal point is equal or greater than 5 and not
rounding up if its value is less than 5.
Where as :-
DSC is number of day commencing from settlement date to next coupon payment date (day).
DCS is number of day commencing from last previous coupon payment date to settlement date
(day).
DCD is number of day commencing from last coupon payment date to redemption date (day).
y is yield to maturity (% per annual)
H is number of coupon payment per year (time per year)
g is coupon rate on bond certificate (% per annual)
(In case of trading during XI period, calculation is not included first coupon period. g/H for the first
period is 0)
n is remaining instalment of coupon payment (time)
Price including accrued interest (Gross Price or Dirty Price) and price not including accrued interest
(Clean Price) in term of percentage is to be fixed decimal points not exceeding 6 points (round up) by
rounding 6th decimal point up if value of 7th decimal point is equal or greater than 5 and not rounding
up if its value is less than 5.
Calculated clean price (price not including accrued interest) in term of percentage compares with par
value
Clean price = Gross price – Accrued interest
Calculated settlement amount using 2 decimal points by rounding 2nd decimal point up if value of 3rd
decimal point is equal or greater than 5 and not rounding up if its value is less than 5. All this is due to
using percentage of price and accrued interest with 6 decimal points (round up) for calculation.
Note the [Link] has been set to TYIELD this is a specific method for Thai bonds.
Security transactions containing purchases and sales of securities to be processed using these price
types should instead be located in a portfolio which has been set-up to utilise the linear method of
amortisation. You may, alternatively, locate these instruments into a non-amortisation portfolio instead.
The compound method provides an alternative means of accruing or amortising discount or premium
over the remaining life of an interest bearing bond-type security. Whereas the utilisation of the LINEAR
method will, accrue/amortise on a straight-line basis, the COMPOUND method will provide lower daily
accruals or amortisations during the earlier remaining life of the underlying security. These cash flows
calculated by the compound method increase as the security nears its eventual maturity.
While the basis for calculating the daily accruals for the LINEAR method is simple and straightforward,
the basis for COMPOUND is more challenging as it is based on the concept of “Average Yield” of the
value-dated position. Whenever the position is changed, a new average yield will be calculated; the
outstanding discount/premium and the amortised to date figure will be adjusted (see basic concept
illustration).
1. If position changes from “long to short” or “short to long” then use the yield on the trade
bringing about the switch - 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
Where:
[Link] = value-dated position (the nominal as on value date)
[Link] = value-dated cost of position (the cost at average price on
value date)
[Link] = discount provision (the amount accrued/amortised so far)
The amortisation amount is then calculated by the amortisation formula as described below. It will be a
proportion of the value-dated discount/premium such that the final amortisation amount will be equal to
the value-dated discount/premium on the night before the maturity date. The amortised to date figure
will be updated accordingly and the daily accrual will simply be the difference between today’s figure
and yesterday’s figure.
⎛ ⎟⎞
⎛ Ndays ⎞
⎜ (1 + YM ) ⎝ YD ⎠ ⎟ − 1
⎜
⎝ ⎠
Amort = Discount. Premium *
⎛ ⎟⎞
⎛ DM ⎞
⎜ (1 + YM ) ⎝ YD ⎠ ⎟ − 1
⎜
⎝ ⎠
Where:
YM = yield to maturity
Ndays = number of days to accrue
DM = number of days to maturity
YD = number of days in year
Assume that BUY1 is at 98.00 and the new average price of position after BUY2 is 98.50. Note the
change of the Value-dated Discount Premium and the Cost of Position.
If there is one coupon period or less until redemption, Yield is calculated as follows:
Where:
A = number of days from the beginning of the coupon period to the settlement date (accrued
days).
DSR = number of days from the settlement date to the redemption date.
E = number of days in the coupon period.
If there is more than one coupon period until redemption, Yield is calculated through a hundred
iterations. The resolution uses the Newton method based on the formula used for the function Price.
The yield is changed until the estimated price given the yield is close to price.
⎡ ⎤ ⎡ ⎤
⎢ ⎥ ⎢ rate ⎥
⎢ ⎥ ⎢ 100 * ⎥ ⎛
redemption N
frequecy rate A⎞
Price = ⎢
⎢ ⎛
⎜ N −1+
DSC ⎞
⎥
⎟ ⎥
+ ⎢∑
⎢ A=1 ⎛
⎜ A−1+
DSC ⎞
⎥
⎟ ⎥
− ⎜
⎝
100 * * ⎟
frequency E ⎠
⎢⎛⎜1 + yld ⎞ ⎥ ⎢ ⎛⎜1 + yld ⎞
⎝ E ⎠ ⎝ E ⎠
⎟ ⎟ ⎥
⎢⎣⎝ frequency ⎠ ⎥⎦ ⎢⎣ ⎝ frequency ⎠ ⎥⎦
Where:
DSC = number of days from settlement to next coupon date.
E = number of days in coupon period (year days/frequency).
N = number of coupons payable between settlement date and redemption date.
A = number of days from beginning of coupon period to settlement date.
where:
Pos. Changed
Disc. Adj = Curr. Disc. Prov *
Last. Pos
Where:
Where:
For example if we purchase 250,000,000 of a £1 bond @ 103.2% on the value date of 21/09/1994,
with a maturity date of 27/06/2001 and a coupon rate of 9 % giving a yield to maturity of 8.3492 %
The transaction proceeds are thus £258,000,000 where £250,000,000 is the asset value resulting in a
premium of £8,000,000 to be amortised. Under the linear method the daily discount accrual would be
£3,237.56. Thus the amortisation over time would give the following results:
a) On the date of sale, realised profit will be booked without adjusting for discount sold on the
sale nominal. However, accruals up to the sale trade date are taken into account. On this date
the realised profit category will be credited and LIVEDB will be debited.
b) On the value date of the sale the discount sold on a sale nominal will be adjusted by debiting
the realised loss category and crediting LIVEDB.
BS * ( K − VK ) Price Type 10
( P − VP)
BN * Price Type 11
100
Where:-
K = Unit Price
P = Price in %
VK = Not-paid amount (same currency as the price or the security value)
VP = Unpaid amount expressed as a percentage of the nominal value
BS = Number of units in trust
BN = Nominal value at maturity
The formula for the [Link] field in [Link] when set to “Price” will be
changed to incorporate the Telekurs price types of 10 and 11.
“Percent” is 100 if the PERCENTAGE field on the [Link] record is ‘Y’ and 1 if the PERCENTAGE
field is ‘NO’.
The field [Link] on the [Link] is used to store the amount that has not
been paid on a part paid security. In order to maintain T24 integrity for historic prices, this field will be
made no change after the security has been traded.
When further instalments are paid on a part paid security a new [Link] will need to be
input and the positions moved using DIARY and ENTITLEMENT processing.
⎛ BN ⎞
⎜ ⎟*K
⎝ N ⎠ Price Type 20
K
BS * Price Type 51
RN
Where:-
K = Unit Price
BS = Number of units in trust
N = Nominal Value
BN = Nominal value at maturity
RN = calculation nominal
Currently these price types can be set up within T24, however this would involve using a separate
[Link] for each unit nominal and specifying the unit nominal as a fraction (i.e. a unit nominal
of 1000 would need to be specified as 0.001).
The following fields in the [Link] application can be used to overcome this
cumbersome set up.
[Link] - This field will have the same effect as the [Link] field specified on
the [Link] application. If a value is entered in the [Link] then it will override any
value specified in the [Link] field.
This will apply to all [Link] that currently use the [Link] field on the
[Link] record.
[Link] – This field will allow two values to be specified “DIVIDE” or “MULTIPLY” and will be
used to decide if the value entered in the [Link] field divides or multiplies when used in
the price formula. Effectively the formulae will remain the same and there will be no change if
“MULTIPLY” is selected, however if “DIVIDE” is selected then the value in the [Link] field
(X) will be used in the formula as 1/X.
In order to protect the integrity of T24 for historical price calculations neither field [Link]
or [Link] will be allowed to be changed after the security has been trade. Any attempt to
amend these fields once the security has been traded will produce an error message.
The setting-up of a security for a floating rate of interest is slightly different from that of a standard
bond. The following [Link] extract illustrates the fields for setting up the floating rate
bonds.
The fields [Link] and [Link] are multi-valued to reflect the applicable rates and
the dates on which the interest rate would change. For example, in the [Link] above,
the rate of interest applicable till 4th of July 2003 will be 3.5% and the new rate that would be
applicable from 5th July 2003 will be 3.55%, which in turn will be valid until 4th August 2003.
By multi-valuing the [Link] and [Link] fields, the user can capture future rate
change dates till the maturity of the bond. The user can as an alternative capture the new rate change
date and new rate as and when a COB report notifies them. It is also possible to set the system to
build the rate change cycle information automatically thus avoiding the manual input of dates and
rates of interest, which can be quite tedious.
By setting [Link] to Standard, we are telling the system that a rate change frequency
needs to be automatically built. If this field is set to Null, the rate change cycle will have to be manually
entered by the user. The value in field [Link] will be the starting point for the rate change
date and depending on the value in [Link] field, calculates the next [Link].
While computing the date change, the system can also check for it being a good business working day.
In the above example, the value of 05ADJ in [Link] causes the system to check
HOLIDAY records for the country specified in [Link] and further more take into
consideration the value specified in [Link] i.e. following, preceding and modified to arrive
at the best estimate next [Link]. This derived value will be automatically populated into the
fields [Link] (now multi-valued) and [Link].
Having specified the dates, we can specify the interest rates for the reset by choosing the appropriate
[Link] record key in the field [Link]. The [Link] field allows
the user to choose either a BID or OFFER rate from the [Link] record. The user can
further specify a spread, if required, in the field [Link] that will increase or decrease the
all-in-rate for the bond. The appropriate rate of interest applicable to the bond will then be updated
from the [Link] record.
[Link] table.
For the [Link] referred above, the interest payments are 12 i.e. Monthly and we have
specified the BID rate to be chosen with a positive spread of 5 basis points. The system will therefore
pick the bid rate corresponding to the [Link] of 01M, which is 6.2813, and add the spread of
5 basis points to compute an all-in-rate of 6.3313%.
This rate will be populated in the [Link] by the Close of Business job that will look to the
[Link] to determine the lead-time required for the new rate reset. In the above example, the
value of 1 in [Link] will tell the system to look for a new reset rate one day before the
[Link].
The field [Link] could also be set as ‘SIMPLE’ or ‘COMPOUND’, which would allow for
coupon changes within the interest period.
As per the normal functionality, if the rate changes within the coupon period, the revised rate would be
applied for the entire interest period. So for example, if the interest period is from 1st January to 31st
March and the interest changes on 1st March, the revised rate would be applied for the interest period
from 1st January. However, if the COUPON METHOD is set to ‘SIMPLE’ or ‘COMPOUND’, the rate
applicable for the period from 1st January to 28th February would be the old rate and the new rate
would be applied from 1st of March.
There is also a facility to compound the interest calculations wherein the interest to be applied, taking
into account the example above, from 1st March would be computed using the new rate on the
Principal and interest accrued from 1st January to 28th February. When [Link] is set to
‘SIMPLE’ or ‘COMPOUND’, [Link] becomes mandatory. This field would be used
to define the frequency in which rate change from Periodic interest needs to be automatically updated.
Rounding methods of ‘UP’ and ‘DOWN’ as well as the conventional rounding (round OFF) can be
used. Conventional rounding ‘OFF’ is defined as if the decimal Figure to the right of the required
number of decimal places is 5 or greater rounding up to the next Figure will occur whereas rounding
down will occur if the Figure is 4 or less.
However the methods of round ‘UP’ and ‘DOWN’ ignores all decimal places to the right of the required
number of decimal places and rounds up by one Figure if ‘UP’ is selected or if round ‘DOWN’ is used
the last Figure will remain the same.
Some Bonds have the accrued interest calculated as an amount per single bond unit first before
multiplying by the bond nominal amount to obtain the full-accrued interest amount. In such cases Bond
Rounding will need to be applied to the interest per unit before multiplying by the nominal factor.
[Link]
This table is used to determine where rounding will take place during the bond interest calculation.
The Par Value is taken from the [Link] field on the [Link] file if the field
[Link] is set to “YES” on the [Link]. If this if value is set to “NO” a value of 1
is used in the above formula and calculations.
Using the [Link] the above calculation equates to the following fields :
Each field has an option of PRE or POST and dictates if each element of the calculation should be
applied to the calculation before (PRE) or after (POST) rounding takes place.
The fields in RED will be calculated first and then rounded; the fields in BLUE will then be calculated
using the result of the RED calculation.
[Link]
This table is used to configure how many decimal places will be used for rounding during and after the
bond interest calculation.
This table can accept 3 different ID formats. Each time a bond interest calculation is performed the
system will check to see which is the best method of rounding. The sequence of checking will always
be performed in the same order.
The [Link] field determines which rounding method to use and the [Link]
and [Link] fields control the rounding of the interest calculation during the calculation (e.g.
after all the PRE calculations have taken place).
The [Link] and [Link] fields control the rounding of the final interest calculation
after all other calculations have been completed. The [Link] determines the rounding
to be applied for final coupon amount computation pre calculation.
In some domestic markets, securities trading may be carried out using different methods of rounding
for day-to-day activity (trades and accruals) compared with the subsequent payment of coupons. In
some cases, depending upon the numbers decimals required to perform the calculations, the final
day's accrual before coupon date (the coupon payment) may differ substantially from the previous
days' accruals (accrued interest for the period) in the current period. The system generally passes
these adjustments to an internal suspense account as defined in fields, [Link] and
[Link] in [Link].
If this process needs to be by-passed for these security types and instead adjust the accrual instead
for the last day before coupon date so that the result goes directly to profit and loss interest received
category, the [Link] field should be set to "YES"
[Link]
To enable bond interest rounding, each [Link] record must have the
[Link] field set to “YES” as shown below.
The [Link] field will be populated with the best applicable Bond Rounding method at
the time the record is entered or displayed, however, this does not indicate which method will be
used in the calculations. Each time a Bond interest calculation is performed the system will check to
see the best available method at the time of the calculation.
Application updates
However, if the field [Link] is set to “Y”, the coupon calculated will be as per the following:
Nominal * Rate * Days in period (61 days) / Year days (which will be 364 in this case). The year days
of 364 is obtained by calculating the number of days between 13th December 2006 (the date the last
coupon would have been paid if the bond had been issued prior to that) and 13th June 2007 (Year
days = No. of days * No. of payments = 182 * 2 = 364).
The actual coupon period is 61 days but a quasi semi-annual period is created by extending
backwards the start date of the semi-annual period to 13th December 2006.
All Security movements that have a Value Date before the [Link] in the DIARY will be
included. All positions were the [Link] is lesser than the Value Date will be ignored.
ENTITLEMENT records will be generated only when the [Link] is greater than the Value
Date in the [Link] file.
SWIFT - Intermediary
The fields, [Link] and [Link] located within [Link] and
[Link] cater for occasions when multiple agents are required within payments of
funds.
However, the use of this facility can be performed subjected to override approval when the number of
required multi-value fields exceeds a predefined number in accordance with the value set in the
INTERMEDIARY field of the [Link] application.
The extract below shows the INTERMEDIARY field as having been set to “3”.
By setting the value to “3”, this means that the two multi-value fields [Link] and [Link]
may be expanded 3 times before an override appears. Input can only then be effected subject to
override approval being granted in the normal way.
This effect is illustrated below where the first extract shows an example [Link] having been
input with 4 occurrences of an intermediary in the same transaction.
The source of the override was caused by the input of 4 intermediaries as can be seen in the next
extract.
The INTERMEDIARY field on [Link] may be left blank or contain any numeric value up to
and including 99.
• The rules to automatically transfer the positions of certain customers from one depository to
another.
• The sub-accounts at a depository level.
[Link]
This application allows the user to set-up automatic depository transfer instructions for a particular
depository.
Criteria can be entered for any asset type, sub asset type, security domicile, customer nationality,
customer residence, or in a more generic manner on any field from the following applications:
CUSTOMER, [Link] and [Link].
Any input into the [Link] field must be defined as a depository on the
[Link].
[Link] record.
keyed on the Depository number, in this case the transaction depository. It will allow the user set-up
automatic depository transfers of stock. So that if a portfolio is part of a bulk trade that purchases
stock to be delivered to depository A (the transaction depository), then [Link] can
be set-up to automatically transfer that portion of the stock purchased on behalf of the portfolio to a
different depository.
Automatic depository transfers will work by effectively producing a depository transfer after a
transaction. The updates and delivery produced will be the same as those produced by
[Link] when transferring stock between depositories.
Consequently when checking the nominal of a position to see if there is enough stock to satisfy a sell
or transfer out the system will take onto account the set-up of the [Link] application
and check the position at the depository from whence the stock would ultimately come. This check will
be included for [Link], [Link], [Link] and
[Link].
Once the stock has been placed in the holding depository, as opposed to the transaction depository,
T24 will treat it the same as it would any other security position for the purposes of corporate actions.
The [Link] table can be individually defined to suite a particular need and may
look something like this.
The [Link] field allows choosing between the CUSTOMER and [Link]
applications. Any fields from the [Link] for these applications can be used to
form part of the routing criteria.
The [Link] field allows use of standard operands such as ‘EQ’, ‘NE’, ‘LT’, ‘GT’ and ‘GE’. A
typical [Link] record with the use of operand is shown below:
As per the setting above, for this depository, the securities domiciled in ‘CH’ would default to Sub
Account 1 ALL other securities would use Sub account 2 as the default.
If a [Link] record is changed or a new one input then the [Link] field is
set-up to ‘NEW’ or ‘CHANGED’ as seen in the example above.
The change to the sub account defaulting will take place after the Close of Business and the BATCH
record BNK/[Link] has been run. This batch job selects all the existing positions in the
depository affected by the change to the [Link] record. These records will have
the sub-account defaulted according to the rules set-up on the new or changed
[Link] record.
This application gives the ability to set-up rules that control which security positions are linked to which
sub-account.
For this purpose, the sub account is a field and a part of the key of the [Link]
application.
The sub account affected by the trade or the corporate action is identified with the [Link]
field in [Link], [Link], [Link], [Link],
[Link] and [Link] applications.
The [Link] is also added as a field on the ENTITLEMENT record and as part of the key of
the [Link], [Link], [Link] and [Link]
applications.
These two fields [Link] and [Link] are mutually exclusive to one another,
by setting either field will make the other no-input.
Input to this multi-value field must be a valid key on the [Link] file.
[Link]
This application will be used to define alternative identifiers and their formats.
[Link] –This field will determine the maximum length of the particular alternative ID, if the
value is greater than the value in the [Link] field in [Link] record [Link] then
the [Link] field will automatically be changed to the value in this field
[Link] – This field cannot be more that the number specified in the [Link] field. This
field will determine the minimum length of the particular alternative ID.
[Link] – This field will be used to set the format of the particular alternative ID, i.e. 2N3A3X
would be 2 numeric followed by 3 alpha characters followed by 3 alpha numeric, the total number of
characters entered here will be validated against the [Link] and [Link] fields.
A link to a subroutine could also be input here for validation of the ID, this will be achieved by prefixing
the subroutine name with an @.
[Link] – This field will allow the user to set up a mask for the identifier for example if ### - ##
- # was selected, then 123456 was entered, 123-45-6 would be displayed.
[Link] – This is a system maintained field and is set to YES when any record in the
[Link] file has a value corresponding to this alternate index.
Reversal of records on this file will not be allowed, however amendment of existing records and the
addition of new records will be allowed.
[Link]
The [Link] records created must then be added to the [Link] file.
[Link]
Once an [Link] record has been created the system will automatically update all
the [Link] records in the system and add this value to the field [Link].
The field [Link] can then be used if required to add a unique identifiers per each
security.
Stock Reconciliation
Stock reconciliation involves matching the T24 [Link] records against the
depository’s position. This is done by using MT549 SWIFT messages to request a statement of
holdings from the depository and matching the returned MT535 messages, i.e. the statement of
holdings.
The stock reconciliation module is made up of the following processes: -
A holding in stock reconciliation may be either from depository statements or T24 positions files, which
have to be matched in order to reveal reconciliation discrepancies. Each holding is independent and
no other products are affected by the Stock reconciliation functionality.
Statement Requests
A SWIFT MT549 must be sent to the depository for whom reconciliation is to be performed. This
message request can be performed either automatically or on an ad-hoc basis.
Automatic Request
The [Link] record pertaining to the depository for reconciliation needs to have the
field [Link] set with a frequency. With this set the Close of Business BATCH record
BNK/[Link] will automatically sent the MT549 request message.
You will also need to specify in the [Link] field, the particular format report you require. At
present, the System supports:
"TRADE" Denoting the positions comprise all trades up to and including statement date
"VALUE" Denoting positions comprise trades for value up to and including statement date. This
basis is the same as the SWIFT “CONTR” format.
At present the System does not support SWIFT formats "ACTUA" and "BOOKD". Further, although all
mandatory fields within the message type are reported, not all optional fields are supported and those
that are, not all valid codes are available.
The above screenshot illustrates a typical set-up to produce MT549 statements comprising trade-
dated positions on a daily basis.
Manual Request
• All securities in a specified sub-account, as above but enter a valid sub-account in the
field [Link].
• A list of securities in all sub-accounts, as above but use the [Link] multi-
valued set to add the security codes and leave [Link] blank.
• A list of securities in specified sub-accounts, as above but use the [Link] multi-
valued set to add the security codes and [Link] as required.
In the above example a SWIFT MT549 requesting a statement of holdings will be sent to the
depository EUROCLEAR for the period ending 27 AUG 2004. The request is specific for all sub-
accounts but the particular security code 000001-000 is required.
The statement period will allow any date to be entered but for TRADE dated reconciliation only the
current system date is valid.
The statement request process will send a SWIFT MT549 to the depository and at the same time take
a ‘snap shot’ of the T24 [Link] records. This ‘snap shot’ record will be used for
reconciliation against the returned MT535.
Based on the above [Link] the following SWIFT message will be generated
to the Depository.
Messages in the format of MT535s can be produced from the [Link] application to
pass a snapshot of the holdings. These messages will be suppressed and not sent to S.W.I.F.T.
Within T24, the Delivery module performs the function of mapping and formatting messages for
delivery of outgoing and incoming messages either by S.W.I.F.T. or other proprietary transfer
mechanisms. The Delivery module will be used to capture incoming and “outgoing” messages.
The following MT535 message has been diverted from the SWIFT out queue and will be used for
comparing in the matching process when the incoming message from the depository is received.
Holding Extraction
The holdings file is keyed on a composite key made up of depository code, sub account, security code,
position indicator (P for the T24 position and S for the depository statement position) and statement
date. These items are extracted from the S.W.I.F.T MT535 message. The sub account will be from the
[Link] application [Link] field where as the message will contain the
[Link] field. The security code will be the key to the [Link] application
where as the message will contain the ISIN code.
Automatic Matching
Automatic matching is performed if the statement date, depository, sub account, security code &
quantity match for two items where the indicator is different, i.e. an record with a P indicator may only
be matched to an item with an S indicator.
As explained above, in the normal course of events statements are received, extracted and
transferred to the holdings file. Automatic and manual matching processes will be available for the
user once Close of Business and Start of Day processes have been completed successfully.
The automatic matching will run for either one account or for all accounts and two items will achieve a
match if the statement date, depository, sub account, security code & quantity match for two items and
the indicator is different.
Manual Matching
In an ideal world all items have matching correspondent items but if this were true reconciliation would
not be needed. Where items do not necessarily have a corresponding matching item the process
needs user intervention. An enquiry listing unmatched items is available for manual matching where
automatic matching has not been possible.
It is assumed that the automatic matching process will match a large percentage of holdings. However,
there will always be occasions where a match cannot be performed resulting in some unmatched
items on the system. These unmatched items will require some intervention (by the stock
reconciliation department) to match them successfully. Items may only be matched to a single item.
This facility would cater for correspondent banks that do not transmit statements by S.W.I.F.T. Data
entry into the holdings for automatic matching.
Interwoven within T24 the ENQUIRY application provides users with the ability to create their own
on-line enquiries and reports to suite their needs.
Archiving
All holdings will be retained on file for a length of time determined by a parameter. Transferring them
from the live holdings file to an archive file on disk or indeed other media, safeguards historical data
and keeps the items file tidy so enhancing performance. Both matched & unmatched holdings
can be transferred to archive. The archive process will run as part of the Close of Business batch
processing and only transfers those items that have been matched and have exceeded the retention
period specified. Once transferred to the archive file, these items are still available for on-line enquiry
and reporting purposes.
[Link]
Set the INWARD parameters as shown below. This is to divert a copy of all incoming MT535
messages to the IN record in [Link]. You may be diverting a copy of outgoing messages for
some other purpose and in that case you should leave the OUTWARD parameters unchanged. The
OUTWARD fields are mandatory and the values shown below are suitable as default. The generic
carrier is used to capture outgoing records for Reconciliation.
The SWIFT carrier must be running for the messages to be diverted to the diversion file.
[Link]
The file, which contains the incoming messages is named in [Link] and in
[Link] field.
The file name where the position (‘outward’) messages will be found e.g. [Link], is
entered in the [Link] and the [Link] is MESSAGE.
Please note that the file names exclude the F. prefix.
You will have to set up the incoming and outgoing delivery requirements before you can Input and
Authorise this record.
[Link]
A [Link] must be set-up with the ID of the carrier. A model record is released with the
application.
[Link]
Set up a record for defining the carrier to which you will route MT535 messages. A model record is
released with the application.
[Link]
There will have to be a [Link] record for each depository for the STKREC carrier.
[Link]
The STKREC carrier must be added to the field [Link] in the [Link] record.
[Link]
Set up a record for each depository to be reconciled on [Link] to send the statement
messages to the stock reconciliation carrier and the statement requests to SWIFT.
Holdings Processing
The [Link] record [Link] is a process that when run converts the inward (MT535
message received from the depository) and outward (MT535 created by T24 for reconciliation
purposes) messages and creates records on the [Link] file.
The phantom is run by Verifying the record. It can be run interactively in which case it stops when
there is no more data available.
The above screen shows the phantom being active as shown in the STATUS field.
The [Link] can be stopped by using the Input function and selecting “STOP” in the field
[Link].
Recognition of Statements
The [Link] file, record IN contains the message text of statements from correspondents. The
sender’s address and the account identifier are compared with the appropriate fields in
[Link] to find the local depository number.
Recognition of position
The file [Link] (e.g. xxx = STKREC) contains the message text of position information in
MT535 format from T24.
Reconciliation / Matching
The purpose of Reconciliation is to identify differences between statement and position. To do this,
corresponding items are matched and what are left are the differences. There are two phases of
matching. Automatic matching is done by the system. Manual matching is required where human
judgement is required e.g. sub account or quantity differences.
Automatic Matching
Automatic matching may be run for a selected depository or depositories or for all depositories by
Verifying a record in the application [Link].MT571.
Manual Matching
The holdings file contains records for each statement or position entry. Holdings are matched by
entering the key of one in the [Link] field of its matching item. The method of doing this using
the facilities of a diagram is explained below.
[Link] [Link]
IN
[Link].
MESSAGES
[Link]
( FILE )
[Link]
Application
MANUAL
ENTRY/MATCHING
[Link].MT571
AUTOMATIC MATCHING
Revoking a match
To revoke a match, change the [Link] field to blank. Both sides of the match will then become
unmatched. This is only possible when the match is unauthorised.
Holdings input
This facility can be used for easy input of paper statements. It may also be used for correction of
statements on which some error has been detected or for a missing page where a re-transmission has
not been possible. The statement may be keyed in completely or may be entered in part.
Correcting a holding
If a holding has been input then you may change the [Link] record to correct it up to the
point where the record is authorised. Once authorised the only field that may be input is the
[Link] field.
Enquiry [Link].
Enquiry [Link].
Enquiry [Link].
Daily workflow
The Close of Business batch process produces the position information or “internal statements” in
MT535 format.
Most correspondents will send statements from their end of day process. This can mean they arrive
during your working day depending on the difference in time zones.
The [Link] process statement decoding the messages into [Link] records should
be shut down before the End of Day backups and restarted when the system is back on line. This can
be done by the system operator or by someone in the Stock reconciliation department.
Automatic matching can be run at any time during the online day. It is probably best to run it for all
accounts at the start of the day and run it for an account for which you receive a statement during the
day.
Statement of Transactions
MT536 is sent by an account servicing institution to an account owner or its designated agent. It
provides the details of increases and decreases of holdings (i.e. complete list of individual
transactions) done for a portfolio over a specified period of time.
A bank can act as both account servicing institution towards its custody clients as well as account
owner where the account is managed by a local custodian or a clearing house; in the former role it
needs to generate outbound MT536 and in the latter role it needs to process inbound MT536 for
reconciliation purposes. T24 can be configured to generate outbound MT536 messages (as an
account servicing institution); it, however, cannot process inbound MT 536 messages (as an account
owner).
T24 provides facility to generate outbound MT536 messages on a periodical basis (on a set
frequency) or on demand. It is also possible to generate reversal of MT536 messages.
The field PRODUCE.MT536 in [Link] should be set to YES; additionally, if there is any
cap on the maximum number of transactions that can be carried per message, then it needs to be
specified in field [Link].
Since an MT536 is generated at the portfolio level, it is mandatory to set the frequency in order for the
system to generate MT536 messages.
Once the above mentioned setup is in place, the system automatically records all the necessary
information for all the transactions done for the particular portfolio. Statements can be generated on a
set frequency or on demand by the following two ways.
1. COB Processing:
During COB processing, system selects those portfolios for which statement generation is due and
then automatically generates a MT536 message containing complete list of transactions that are done
during the statement period. It also creates a new record for every portfolio processed in
[Link] table with field [Link] as ‘SCHEDULE’. It also automatically
cycles the dates in [Link] according to the frequency.
2. An on demand request:
Statement requests can be made on demand (ad-hoc) by using the [Link] table
available for this purpose.
The user can input the portfolio id for which an ad-hoc statement is to be generated. Values can be
specified in the fields [Link] and [Link] give the required statement period.
The date fields in [Link] will not accept a date greater than current system date.
When a MT536 is generated either through a Close of Business processing or ad-hoc basis, it is
generated only for the customer. But if there is a requirement that client’s multiple MT536 need to be
sent to different interested parties, then the valid SWIFT id’s ([Link] in SWIFT format) of
those interested parties is to be specified in the field [Link] in [Link].
This field can be multi-valued to give multiple SWIFT id’s and also if no recipient is specified then only
one message would be generated for the customer.
Example showing the field with a valid SWIFT id ([Link] in SWIFT format)
T24 allows reversal of only the latest statement for the portfolio. Cancellation can be effected by
selecting the latest statement for the portfolio in [Link] table and then reversing the
particular record. Upon reversal, system automatically generates a MT536 with relevant tags
indicating reversal of the statement.
To generate an MT536 online, it is necessary to run the following service record available for the
company. (If the company is BNK, then it is necessary to run BNK/[Link] service).
Blocking of Securities
In T24 the application [Link] can be used to BLOCK and UNBLOCK
[Link] records held by individual portfolio’s.
Blocking Positions
A BLOCK transaction can be seen with the following example:
The system will validate the amount being blocked against the [Link], if the amount
to be blocked is in excess of the current holding then an error message will be shown. A BLOCK
transaction must be in place prior to any UNBLOCK transaction can be entered.
When a BLOCK transaction is entered [Link] and [Link] fields are mandatory,
[Link] defaults to the system date but can be forward dated.
If the field [Link] is left blank then this transaction is considered to be open-ended.
Once the BLOCK transaction has been authorised the [Link] record is updated as
follows.
The fields [Link], [Link] and PRODUCT are all updated. The field PRODUCT
forms part of a multi-value set of fields which can be utilised when a DX type transaction is also
blocked.
Unblocking Positions
An UNBLOCK transaction can be shown with the following example:
Additional Blocking
If the amount of 200 in the above example is to be increased, than a new BLOCK transaction should
be entered.
The field [Link] should be populated with this new amount, this will then be added to
any previous blocking amounts and create a new overall total. In this example a forward
[Link] of 5th June and an [Link] of 12th June have been specified.
As the above transaction has a forward [Link] and an [Link] specified the
information will be reflected when the [Link] record is updated.
All BLOCK and UNBLOCK transactions are incremental depending on the direction of the blocking i.e.
BLOCK is plus so increasing the overall position to be blocked, UNBLOCK is minus so decreasing the
overall position to be blocked.
The field [Link] in the [Link] will except a numeric value up to and including
999 and will be used to specify how many working days the records are kept before being committed
to the history file.
If this field is left blank then transactions will go to history immediately after the [Link] has
been reached. If no [Link] to date is specified i.e. the transaction is open ended then the
transaction will go to history immediately after the [Link] is reached.
It is possible to create an automatic BLOCK record with the application [Link] when
the user enters a DIARY transaction this can take place a two possible stages.
With a setting of DIARY in the field [Link] the blocking will happen when the
ENTITLEMENT records are created unauthorised.
With a setting of ENTITLEMENT in the field the blocking will happen when individual
ENTITLEMENT records are authorised.
A default value to this field is contained in the [Link] record and field [Link].
So between the time frame of the DIARY authorisation and ENTITLEMENT authorisation the above
BLOCK record will be active. An automatic UNBLOCK record will be created when the
ENTITLEMENT record is authorised.
When and if the call option is exercised the reverse and an UNBLOCK record needs to be produced to
unblock the [Link] file.
Two files [Link] holds three fields that are part of a multi set that
records the nominal, the exercise price and the estimation. This file is created once ENQUIRY
[Link] and [Link] are run.
The other file, [Link] holds fields the same as those on
[Link]. It also holds fields that hold the nominal at the value it should be valued at, the
market price, estimation and cost price. This file is built after running ENQUIRY [Link].
The field [Link] in parameter [Link] allows input of “YES” or ”NO” only
and controls during a transaction if an amount can be traded or not.
If this field is set to “YES” or left blank, an OVERRIDE message appears prompting the user to
override the block, enabling the transaction to continue.
However, if set to “NO”, then an error message is displayed when committing the record telling the
user it’s not possible to commit the transaction since the amount being traded is blocked.
If a block is created, and the date of the block is “TODAY”, then the [Link] will be
updated with the product, amount and price immediately. However, if the block is in the future, then a
Close of Business routine will update the [Link] when the date of unblocking the
options is “TODAY”.
The field [Link] in the [Link] allows an input of ‘YES’ or ‘NO’ and controls this
functionality. If set to ‘YES’ the associated field [Link] can be used and will allow the user
to identify which transaction types are subject to this processing.
In the example above only transactions using the [Link] record id of REC will be included.
The following [Link] transaction has a [Link] value of REC and will
therefore be included in the process.
The above transaction is also being processed through the Contractual / Actual process so a
[Link] record will be produced, after authorisation and the [Link]
record will be updated.
As you can see from above example the field [Link] is updated instead of the usual field
[Link].
Now as and when the securities are actually delivered and settled using the [Link]
process the above two fields in the [Link] will be updated as follows.
As and when the remaining nominal’s are settled the fields will again be updated in sync with one
another.









