TEMENOS T24

System tables

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.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

System tables

Table of Contents
Overview.................................................................................................................................................. 6
Account Definition Tables ........................................................................................................................ 7
ACCOUNT.CLASS .............................................................................................................................. 7
ASCII Tables ...................................................................................................................................... 11
ASCII.VAL.TABLE .......................................................................................................................... 11
ASCII.VALUES ............................................................................................................................... 11
Automatic Id Generation ........................................................................................................................ 13
COMPANY ......................................................................................................................................... 13
AUTO.ID.START................................................................................................................................ 13
Basic Id’s ........................................................................................................................................ 14
Unique Id’s ..................................................................................................................................... 14
1 Basic Id – LD application ......................................................................................................... 15
2. UNIQUE.ID – 5 character setting using REPO application .................................................... 16
3. UNIQUE.ID - Numeric setting, without exclusive lock ............................................................ 16
4. UNIQUE.ID - Restricted alpha and numeric setting ............................................................... 17
5. Setting long id for FUNDS.TRANSFER .................................................................................. 18
BROKER ............................................................................................................................................... 19
Payment Instructions ......................................................................................................................... 19
Calculation Parameters...................................................................................................................... 19
FX.DEAL.METHOD ............................................................................................................................... 20
Base Rate Tables .................................................................................................................................. 21
BASIC.INTEREST ............................................................................................................................. 21
BASIC.RATE.TEXT ........................................................................................................................... 22
PERIODIC.INTEREST ....................................................................................................................... 23
MARKET.RATE.TEXT ....................................................................................................................... 26
CATEGORY .......................................................................................................................................... 27
CARD.MANAGEMENT ......................................................................................................................... 28
CARD.STATUS.................................................................................................................................. 28
CARD.TYPE ...................................................................................................................................... 28
CARD.CHARGE ................................................................................................................................ 30
CARD.ISSUE ..................................................................................................................................... 31
Cheque Tables ...................................................................................................................................... 36
CHEQUE.TYPE ................................................................................................................................. 36
CHEQUE.STATUS ............................................................................................................................ 37
CHEQUE.ISSUE ................................................................................................................................ 38

TEMENOS T24 User Guide

Page 2 of 121
System tables

CHEQUE.REGISTER ........................................................................................................................ 40
CHEQUE.CHARGE ........................................................................................................................... 40
Company Tables ................................................................................................................................... 42
COMPANY ......................................................................................................................................... 42
Branches working on holidays ........................................................................................................... 45
COMPANY.CONSOL......................................................................................................................... 49
COMPANY.GROUP........................................................................................................................... 50
INTERCO.PARAMETER ................................................................................................................... 51
INTEREST.BASIS ................................................................................................................................. 52
Securities & Interest Basis ................................................................................................................. 55
Interest Basis 'C' & 'D' used in securities follow the rules indicated as under: ......................................... 55
Hirja Basis ‘H’ ..................................................................................................................................... 56
EB.ACCRUAL.PARAM .......................................................................................................................... 57
EB.SERVICE ......................................................................................................................................... 60
ENQUIRY SERVICE.LIST ................................................................................................................. 61
CONDITION.PRIORITY ........................................................................................................................ 62
XXX.GEN.CONDITION and XXX.GROUP.CONDITION ................................................................... 63
Country Tables ...................................................................................................................................... 69
COUNTRY ......................................................................................................................................... 69
COUNTRY.GROUP ........................................................................................................................... 70
Currency Tables .................................................................................................................................... 71
CURRENCY.PARAM ......................................................................................................................... 71
CURRENCY.MARKET....................................................................................................................... 72
Currency ............................................................................................................................................ 73
Customer Tables ................................................................................................................................... 75
CUSTOMER ...................................................................................................................................... 75
LEGAL.ID ........................................................................................................................................... 78
Container CUSTOMER records ......................................................................................................... 79
EB.ROLE ........................................................................................................................................... 84
CUSTOMER.CHARGE ...................................................................................................................... 85
CUSTOMER.DEFAULT ..................................................................................................................... 87
CUSTOMER.STATUS ....................................................................................................................... 88
CUSTOMER – Verification................................................................................................................. 89
DEPT.ACCT.OFFICER ...................................................................................................................... 90
GLOBAL.CUSTOMER ....................................................................................................................... 91
Relationships between Customers ........................................................................................................ 92

TEMENOS T24 User Guide

Page 3 of 121
System tables

Relation .............................................................................................................................................. 92
RELATION.CUSTOMER ................................................................................................................... 93
Sector .................................................................................................................................................... 94
Target .................................................................................................................................................... 95
Industry .................................................................................................................................................. 96
Duplicate Contract Checking ................................................................................................................. 97
EB.DUPLICATE.TYPE....................................................................................................................... 97
EB.DUPLICATE ................................................................................................................................. 98
Error messages ..................................................................................................................................... 99
EB.ERROR ........................................................................................................................................ 99
Holiday ................................................................................................................................................. 100
DATES ................................................................................................................................................. 102
Local Reference Tables ...................................................................................................................... 102
LOCAL.TABLE ................................................................................................................................. 102
LOCAL.REF.TABLE......................................................................................................................... 103
Charges and commissions .................................................................................................................. 104
FT.CHARGE.TYPE .......................................................................................................................... 104
FT.COMMISSION.TYPE.................................................................................................................. 106
Settlement Tables................................................................................................................................ 109
AGENCY .......................................................................................................................................... 109
Customer Number ............................................................................................................................... 110
BIC Code ......................................................................................................................................... 110
Multiple AGENCY record use .......................................................................................................... 110
NOSTRO.ACCOUNT ....................................................................................................................... 112
Tax Tables ........................................................................................................................................... 113
TAX.TYPE ........................................................................................................................................ 113
TAX.GEN.CONDITION ................................................................................................................ 113
Tax ................................................................................................................................................... 114
TAX.TYPE.CONDITION ............................................................................................................... 116
German Withholding Tax ................................................................................................................. 118
APPL.GEN.CONDITION .............................................................................................................. 118
REVALUATION.PARAMETER .................................................................................................... 119
EB.EXTRACT.PARAMETER ....................................................................................................... 119
Extract selected updates of files or complete files ................................................................... 119
EB.EXTRACT ............................................................................................................................... 120
EB.OBJECT ................................................................................................................................. 121

TEMENOS T24 User Guide

Page 4 of 121
System tables

TEMENOS T24 User Guide

Page 5 of 121
System tables

Overview
Provided as standard in T24 are the System Tables. These are used by applications to perform a
stand-alone function essential for normal banking operations. Since each table or application is usually
self-explanatory, this document will give a brief explanation on its use and connectivity to the rest of
T24.

TEMENOS T24 User Guide

Page 6 of 121
System tables

Account Definition Tables

ACCOUNT.CLASS
This table has three types of entries. This first type (ACCOUNT) provides the CATEGORY code
portion when building an Internal ACCOUNT Number (such as Computer Suspense Account). The
second type (CLASS) provides the parameters required to identify a group of accounts (e.g. NOSTRO
accounts) by matching the ACCOUNT details against those held in the ACCOUNT.CLASS record.
The third type is used to assign P&L classes.
When the RECORD.TYPE is “ACCOUNT” then the CATEGORY code must be valid and in the range
10000 to 19999.
When the RECORD.TYPE is “CLASS” the CATEGORY and SECTOR code fields are treated as multi-
value associated fields. Either field may be null but not both at the same time. Duplications of
CATEGORY and SECTOR code combined are not allowed within one entry on the ACCOUNT.CLASS
table.

ACCOUNT.CLASS input for Nostro accounts

TEMENOS T24 User Guide

Page 7 of 121
System tables

ACCOUNT.CLASS for Suspense

The following records are among those permitted:

NOSTRO
VOSTRO
BRANCH
BANK
MORTGAGE
MGDEPOSIT
SAVINGS

TEMENOS T24 User Guide

Page 8 of 121
System tables

For P&L the following ids are valid.

DXAMPAID
DXAMRCVD
DXCSNDUE
DXCSNEARN
DXCSNPAID
DXCSNRCVD
DXFXPAID
DXFXRCVD
FTMKTEXCHCR
FTMKTEXCHDR
MKTEXCHCR
MKTEXCHDR
TTMKTEXCHCR
TTMKTEXCHDR

For accounts the following ids are valid

AASUSPENSE ICASUSPDR SCCASUSP SUSPFTBULK
AASUSPENSE INTERCO SCDIFF SUSPFTINWD
ACERROR LCAMORT SLDIFF SUSPFXCR
ACERROR LCDIFF SLROLLOVER SUSPFXDR
AZINTADJ LCLSUSP SLROLLOVER SUSPLMMCR
AZINTADJ LDCANCEL SUSACONLINE SUSPLMMDR
AZROLLOVER LGCLOSE SUSPBDDR SUSPPD
AZROLLOVER LGCLOSE SUSPCREDIT SUSPSCCR
BROKER MARKETING SUSPDEBIT SUSPSCDR
CHQSUSP MERGEMM SUSPDXCGCR SUSPSLCR
CONTDIFF NDFGIVEN SUSPDXCGDR SUSPSLDR
CONTSUSP NDFTAKEN SUSPDXIMCR SWREVAL
CUSDEBIT NETTING SUSPDXIMDR SYFUND
DDCLAIM OFFBALSUSP SUSPDXOMCR SYFUND
DDSTD OFFLIMIT SUSPDXOMDR TFLC
DDSUSP OFFSPINT SUSPDXPRCR USPBDCR
DIFFERENCE OFFSUSPCR SUSPDXPRDR UTILLIMIT

TEMENOS T24 User Guide

Page 9 of 121
System tables

EUSUSPSCCR OFFSUSPDB SUSPDXRPCR UTILLIMIT

EUSUSPSCDR PDREPAY SUSPDXRPDR XCHALFWD
EXCHADJ PLCLOSE SUSPDXVMCR
FXCCYPOS RESFWDCR SUSPDXVMDR
IACLOSE RESFWDDR SUSPENSE
IACLOSE RESSWAPCR SUSPFRACR
ICASUSPCR RESSWAPDR SUSPFRADR

TEMENOS T24 User Guide

Page 10 of 121
System tables

ASCII Tables
ASCII.VAL.TABLE

The ASCII.VAL.TABLE is used to define which ASCII characters may be used for validation against
any 'IN2' routine defined on the ASCII.VALUES table. The 'IN2' routines are used to validate the
entry to particular fields.

ASCII.VAL.TABLE record

The format of the ASCII.VAL.TABLE allows any combination of ranges or single values of ASCII
codes to be defined.

Care should be taken when modifying the values allowed by the system, particularly when using
SWIFT type fields, as this may cause unexpected results by allowing non-standard characters to be
entered.

ASCII.VALUES

The ASCII.VALUES table is used to define ASCII value codes and ranges that may be used by
particular IN2 routines that validate entry to particular fields.

TEMENOS T24 User Guide

Page 11 of 121
System tables

ASCII.VALUES record for IN2 routines

Standard tables are provided for each IN2 routine but there is also the provision for user-definable
tables at a language and application level. Therefore different tables may be set up for particular
languages and applications. The application level definitions may be further subdivided into different
tables for different languages.

See the relevant help text for ASCII.VAL.TABLE, which is where the actual ranges and values are
defined.

TEMENOS T24 User Guide

Page 12 of 121
System tables

Automatic Id Generation
It is possible in T24 to generate the id of certain applications automatically, based of the previous
record id and a user defined set of criteria.

In order to utilise this feature the following applications need to be configured.

COMPANY
At each COMPANY level the generation of new id’s is initially set in the field PGM.AUTO.ID by
entering the application name and an optional parameter.

The optional parameter tells the system if the id for the application must be generated automatically
and that the user cannot enter one manually.

Example
To use the next id option in ACCOUNT but also allow manual generation:
PGM.AUTO.ID ACCOUNT
To permit only auto generation of next id:
PGM.AUTO.ID ACCOUNT M

AUTO.ID.START
This application is used to store/define the parameters for the generation of the id’s for one or more
applications. The key to this file can be basically anything so memorable id’s such as CONTRACTS or
ACCOUNTS may be preferable. The details in the record are multi-valued so you can set the criteria for
more than one application at a time. In theory you could use just the one record to preset all the
applications you wish to control, but in reality there may be times when you want to reset the id
starting point of one or more applications so individual or grouped records may be more beneficial.

Id generation can be a simple julian date generation for contracts; a number for a CUSTOMER
record; an ACCOUNT number (simple or based on an algorithm to prevent records having id’s too
similar); an id based upon the users department and even a complex unique id to prevent duplication
in large systems.

Although the id of AUTO.ID.START can be anything it is recommended that meaningful names are
used to ensure the current settings for an application can be seen readily.

TEMENOS T24 User Guide

Page 13 of 121
System tables

Basic Id’s
The id of many applications is in the style XXYYDDDNNNNN or XXXXXYYDDDNNNNN such as
LD0712300001 where:

XX or XXXX (or in some applications XXXXXX) is an application identifier.

YYDDDD is the julian date (year and day number)

NNNNN is the sequence number.

Though simpler to input and remember the usage of such sequential id’s does present problems in
larger institutions where a high transaction throughput is required together with minimal transaction
processing time. This method will find the last number used from the LOCKING table, workout the
next and lock it until the transaction is completed – thereby imposing a slight bottleneck id generation.
If this is acceptable then the basic id’s can be used. If faster response times and multi-threading is
used to generate large volumes of deals then the id generation should use the UNIQUE.ID settings
detailed below.

Unique Id’s

To use unique ids other than the standard julian based ones, the fields UNIQUE.NO, BASE.TABLE &
ID.LENGTH are used.

UNIQUE.NO is a YES/NO flag

BASE.TABLE is a set of characters that can be used in the key, needs to have more than 10
characters set.
ID.LENGTH indicates the length of the id allowable under select circumstances (must be more than
11 characters)

This method of generating the id removes the requirement for reading and locking a record on the
LOCKING table. Instead a key is generated and checked for exclusivity on the application (checks
the live, unauthorised & history files where applicable) if the id is exclusive we have the key to use, if
not then we generate the next and test for exclusivity again. To provide more exclusive id’s the field
BASE.TABLE can be populated with selected alpha or numeric characters (vowels are excluded to
avoid embarrassing letter combinations being generated). If BASE.TABLE is left empty then both zero
and vowels are excluded, again to avoid embarrassing combinations.

When using a set list of characters the system will check that there are sufficient entered to be able to
generate a variety of key combinations, lists greater than 10 would be needed.

TEMENOS T24 User Guide

Page 14 of 121
System tables

In using UNIQUE.NO a balance needs to be taken based on the number of transactions per day and
peak throughput. A simple setup for example which used a 5 digit sequence number appended to the
standard application identifier and julian date may be acceptable in smaller institutions generating a
few thousand deals, per application, per day. Larger transaction volumes would make this choice
impractical and therefore a more randomised key structure would be beneficial.

To make the above clearer we need to illustrate some of the settings with examples.

1 Basic Id – LD application

Requirement: Provide sequential id’s in format such as LD0712300001 to LD0712399999 with the
sequence resetting to 1 each day and the julian date (07123 in this example cycling each day).

Benefits: Id’s are sequential, memorable and simple.

Drawbacks: Locking of record can cause slower transaction throughput in large volume sites.

UNIQUE.NO, BASE.TABLE & ID.LENGTH fields are omitted on AUTO.ID.START record.

Simple Id generation

TEMENOS T24 User Guide

Page 15 of 121
System tables

2. UNIQUE.ID – 5 character setting using REPO application

Requirement: Provide id’s in format such as RP0712300001 or RP07123BDX12 with the julian date
(07123 in this example cycling each day).

Benefits: Faster id generation, no locking bottlenecks, easier multi-threading of new deals

Drawbacks: Deal numbers are not sequential.

5 character sequence using UNIQUE.NO

The above two examples are the recommended settings, if there is a requirement for settings using
the BASE.TABLE or ID.LENGTH fields then it is suggested that you contact Temenos first in order to
have the correct settings for the application.

Examples three, four and five are to illustrate the possibilities of using the UNIQUE.NO.

3. UNIQUE.ID - Numeric setting, without exclusive lock

Requirement: Provide id’s in format such as RP0712300001 ranging up to RP0712399999 with the
range resetting each day and the julian date (07123 in this example cycling each day).

TEMENOS T24 User Guide

Page 16 of 121
System tables

Benefits: Faster id generation, no locking bottlenecks, easier multi-threading of new deals

Drawbacks: Deal numbers are not sequential, first time calculation of unique id success rate reduces
as the volume of deals per day increases.

Restricting sequence to numeric

4. UNIQUE.ID - Restricted alpha and numeric setting

Requirement: Provide id’s in format such as TT0712300001 or TT07123BDC12 with the julian date
(07123 in this example cycling each day). Restrict characters to 1-9 and BDCFGH.

Benefits: Faster id generation, no locking bottlenecks, easier multi-threading of new deals

Drawbacks: Deal numbers are not sequential, first time calculation of unique id success rate reduces
as the volume of deals per day increases.

TEMENOS T24 User Guide

Page 17 of 121
System tables

Restricting valid id characters

5. Setting long id for FUNDS.TRANSFER

To use a longer id in FUNDS.TRANSFER to replace the earlier long id options, use a setup like this:

Long FT id

TEMENOS T24 User Guide

Page 18 of 121
System tables

Currently T24 Unique Id mechanism supports:

• FUNDS.TRANSFER
• TELLER
• REPO
• SEC.TRADE
• SECURITY.TRANSFER

NB After input or modification of the AUTO.ID.START and/or COMPANY record settings the user
must log out for the settings to take effect (as they are read at login time and stored in memory).

When using BASE.TABLE settings (other than blank) it is recommended to ensure the ID.LENGTH is
set to a pre-defined value. Use of these fields on standard applications without understanding the
possible impact can conflict with existing id validation in the application or for SWIFT compliancy.

BROKER
The BROKER table is used to define the banks authorised brokers.

Payment Instructions
The first section of this table is used to specify the broker's payment instructions, such as the
currencies in which the broker will accept payment, the default transaction code for brokerage entries,
and the account to which the brokerage funds are to be transferred. This account may be defined in
two ways:

1. The default specifies an internal account number, which is composed of the payment currency;
the category specified on the ACCOUNT.CLASS record BROKER and the sub division code
specified on the BROKER record. The actual internal account number is not shown on the
record.
2. The second method of account definition is the specification of a T24 account, which must be a
customer account that belongs to the BROKER. One account may be defined for each payment
currency.

Calculation Parameters
The second section of the table is used to determine different brokerage rates applicable to specific
deal types. During the deal input stages for the valid applications, if a broker code is entered then the
details of this table are obtained to default the brokerage amount for the deal. Certain aspects of the

TEMENOS T24 User Guide

Page 19 of 121
System tables

deal are matched to the parameters on this table to define a deal type. Each deal type is defined using
the following parameters:
• System Id
• Category
• Time

The System Id is used to define the application. At present valid products are Money Market, Loans
and Deposits, Letter of Credit, Drawings, Fiduciaries and Forward Rate Agreements. Category is used
to match on the product category of the deal. Time is defined as the number of days from the start
date to the maturity date.

Once a match has been found for the deal type, the currency of the deal is matched with a list of
currencies on the BROKER record. Then, according to whether the customer of the deal is a bank or
a non - bank, a rate or FT.CHARGE.TYPE or FT.COMMISSION.TYPE is returned on which the
brokerage calculation is based.

FX.DEAL.METHOD
This table is used by the main dealing/lending applications to record how the deal was booked. It is
used mainly for advices and reports and is entered in the Broker field on the relevant applications.

Enquiry showing list of FX.DEAL.METHOD types

TEMENOS T24 User Guide

Page 20 of 121
System tables

Base Rate Tables

BASIC.INTEREST
This table allows various frequently used floating Rates e.g. Base Rate, Prime Rate, Overnight Rate
etc., to be defined separately for each Currency. T24 Applications can access them as required.

BASIC.INTEREST record for Belgian Francs

Interest conditions can be linked directly to a Basic Interest record in this table, rather than defining the
Interest Rate details on each transaction record. Interest rates for accounts or groups should be
entered as a difference from a BASIC.INTEREST rate where possible.

When a rate change takes place, you will then need to update only the BASIC.INTEREST record
defined in this table with the new rate(s) and the date on which it is to become effective. This will then
automatically update all the transaction records, which are tied to that rate.

A description of each rate is held in the BASIC.RATE.TEXT table to allow the user to identify easily
each one of the BASIC.INTEREST rate table ID's. For this reason, a description is not included in
the input parameters of this table. The BASIC.RATE.TEXT table of descriptions must be defined
before creating this table.

T24 also provides a PERIODIC.INTEREST rate table. It caters for transactions where the Interest
Rate conditions may change on a pre-defined periodic basis, e.g. LIBOR and also according to the
current balance on the 'Prime Record'. The linking of 'Prime Records' to a BASIC.INTEREST Rate ID
or a PERIODIC.INTEREST Rate ID will depend on the conditions existing for various products
within the bank.

Negative interest rates can be given in the BASIC.INTEREST table as follows:

TEMENOS T24 User Guide

Page 21 of 121
System tables

BASIC.INTERST Table with Negative Interest Rate

BASIC.RATE.TEXT
This table defines descriptions of the BASIC.INTEREST and PERIODIC.INTEREST rate table ID's
to enable the user to identify each one of them easily.

BASIC.RATE.TEXT input screen

Each Description must be defined before creating rates records for the corresponding ID in the
BASIC.INTEREST rate table. It will be used as the enrichment to the corresponding ID when it is
displayed or printed during T24 processing.

Up to 9999 descriptions may be defined.

TEMENOS T24 User Guide

Page 22 of 121
System tables

PERIODIC.INTEREST
This table defines, for each currency, interest rates for any time period desired by the user, or in days,
e.g. 7 days, 15 days, 30 days. For each period defined by the user, both a BID and OFFER rate can
be entered.

Interest Rates can also be defined by amount, so a different rate can be entered for ranges from $1 to
$10,000 to between $10,000 and $25,000.

PERIODIC.INTEREST will be used by applications such as Forex to default interest rates on

forward contracts using the INTEREST revaluation method or the MM/LD applications to perform
automatic rollovers.

PERIODIC.INTEREST record rates

TEMENOS T24 User Guide

Page 23 of 121
System tables

The field USED.LAST.WRKING.DAY, when flagged, instructs the system to check whether the current
system date is the final working day of the month. If this is the case, when the rest period is defined
as a number of months, the system looks for the final working day of the appropriate month, rather
than selecting the equivalent working day. So for example, if February 26th were the last working day
in February, having a rest period of 1M would find the final working day in March, rather than simply
selecting the 26th March or the nearest next working day.

Another option which allows for local rate manipulation is the field LOCAL.ROUTINE which enables the
core routine to be overridden and user rates/spreads to be calculated based on local tables or criteria.

Local routine

Negative interest rates can also be input in the PERIODIC.INTEREST table. The field called
APPLICATION is used to specify the application id(s) that can use Negative Interest rates.

In order to control the usage of the rates there is also a listing of applications which are enabled and
can correctly utilise negative rates - this is the field called APPLICATION.

TEMENOS T24 User Guide

Page 24 of 121
System tables

Periodic. Interest Table with negative interest

Applications that can use negative rates

TEMENOS T24 User Guide

Page 25 of 121
System tables

It is possible to modify the fields REST.PERIOD, AMT, BID.RATE and OFFER.RATE of existing
PERIODIC.INTEREST records of a past date. The use of such modified records is application
dependent. Whenever a PERIODIC.INTEREST record of a past date or processing date is modified
and authorised, the IDs of such records are written in a live file PERIODIC.RATE.CHANGE, whose
records are with a key of the Processing Date.

PERIODIC.RATE.CHANGE Record

MARKET.RATE.TEXT
This table contains descriptions of tradable interest rates that are recognised by SWIFT.

Each description will be used as the enrichment to the corresponding ID when it is displayed or printed
during T24 processing.

MARKET.RATE.TEXT record

TEMENOS T24 User Guide

Page 26 of 121
System tables

CATEGORY
CATEGORY codes are used to classify financial transactions in T24 according to the type of
business operation or product.

The use of these codes, together with personal CUSTOMER characteristics, e.g. RESIDENCE,
CUSTOMER.STATUS, INDUSTRY and SECTOR codes, will enable the bank to produce balance
sheets and returns reflecting a co-ordinated and structured view of its operation by directing business
transactions to their appropriate place on the report.

Example of Category record for MM Deposit

The first two digits of the CATEGORY code represent the highest level of classification and the next
three digits represent a sub-classification that provides a clear definition of the profit and loss or
product type.

Care should be taken when defining additional sub-classifications that sufficient detail does not
already exist to provide the required breakdown. For example, you should not define separate
CATEGORY codes for resident and non-resident customers or for local and foreign currency
transactions, since this information is already available on an individual prime record.

TEMENOS T24 User Guide

Page 27 of 121
System tables

A table of possible values and definitions of the first two digits of CATEGORY codes has been pre-
defined within T24 and is included in the documentation of the record ID of this table. The sub-
classifications will be defined separately within each System.

CARD.MANAGEMENT
Applications used to manage CARD processing are:

• CARD.STATUS
• CARD.TYPE
• CARD.CHARGE
• CARD.ISSUE

CARD.STATUS
The application is used for defining various card statuses. The 4-card status like 90-Issue, 91-Re-
issue, 92-Scrap, and 93-cancelled is hard coded at the CARD.ISSUE application level and cannot be
altered. Any new status other than the one that is hard coded can be input using this application.

CARD.STATUS types

CARD.TYPE
This file holds the details for each type of card supported by the card control system.

TEMENOS T24 User Guide

Page 28 of 121
System tables

CARD.TYPE record for Excel cards

A card type is defined by a four-letter code for example:

• AMEX American Express cards

• VISA VISA cards

Each card would normally be valid for a set length of time. The renewal date of cards is calculated
from two fields, the RENEWAL.DATE and the RENEWAL.FQU. These are separate fields so that cards
may be renewed based on a standard frequency field if all cards expire on a given date or on a
frequency period based on their date of issue.

TEMENOS T24 User Guide

Page 29 of 121
System tables

Significant fields in CARD.TYPE to be input when a new card type is input.

Field Name Accepted values Meaning

BILLING.DAY Format (D-nn) means When a repayment date is input in card.
Date minus nn (where Issue – the billing date is “nn” days
nn is a numeric). Date before such date. (I.e. Repayment date
here implies REPAY dt –nn (nn is a numeric)
input in Card Issue
application.
AZ.PRODUCT No change/no input For a valid Az. Product. Parameter – if
field. When card type field card. Type is mentioned then this
field in az product field in card. Type will be automatically
parameter is input –then populated with the AZ product
in card type this field is parameter. NO change/ no INPUT field.
populated.
FORWARD.BACKWARD.KEY 1-Forward This key defines the method to be
followed by the system when the
2-Backward
derived date of a generated schedule is
3-Forward Month a non working day.
4-Calender 1-Is input the system will go forward to
the next working day
2-Is input the system will go back to the
last working day
3-Is input the system will take the next
working day if it is within the month and
if it is not within the same month then
the system will go backward to the last
working day.
4-The system date will be same
whether it is a holiday or not.

CARD.CHARGE
This table holds details of the charging structure to be applied to all CARD.TYPE for issues and
periodic charges.

TEMENOS T24 User Guide

Page 30 of 121
System tables

CARD.CHARGE input screen

For each CARD.TYPE it is possible to define individual TRANSACTION codes for debit/credit and a
profit/loss CATEGORY for charges. Issue and periodic charges can then be set up or defined as zero
to effectively waive charges if required.

Issue charges are raised on-line at the time of issue. A Close of Business process based on a cycle
and frequency raises periodic charges. This may be related to a specific date for all cards of a
particular type or be based on the issue date of individual cards.

Issue charges for cards are raised on authorisation of the issue instruction once only. The default
charge for a card issue is taken from this table or the user in the issue transaction itself may overwrite
it.

All charges are in local currency. The value date of the charge entry will be taken as the
CHARGE.DATE defined on the issue instruction.

In multi-company databases the CARD.CHARGE records are unique to each company based on the
FIN/FTH settings. This will allow the same basic settings (or independent ones) to be used but allows
the CHARGE.CYCLE dates to be different

CARD.ISSUE
CARD.ISSUE is one of the two central applications of the cheque and card control system.
The issue of cards to an ACCOUNT is controlled by the entry of records on this table. Entry to this
table is similar to entering a transaction within other T24 modules. The most significant information

TEMENOS T24 User Guide

Page 31 of 121
System tables

entered on a CARD.ISSUE record is contained in the record ID. This defines the card type being
issued and the card number involved.
The “ID” of the CARD.ISSUE application is CARD. TYPE. CARD. NO. Contained in each record is the
ACCOUNT number to which the card is being issued, the date of issue, any charges incurred at
issue time and the expiry date of the card.
A card must be linked to at least one account, but may be issued to several accounts. They can be in
same currency or in different currencies. The first account will be treated as the principal account
number and charges will be debited from that account. It is possible to modify the account number
with an account that belongs to the same customer or to a different customer. Override message(s), if
the customer of account numbers are different, will be given where appropriate.

The card status field in the application can be input with any of the following values.

Values –enrichment Impact on the stock

90- Issue Stock at hand comes down by one
91-Reissue Like ISSUE, this field will also diminish the stock count by one- This status
will come into picture only when FIRST time card issue is
mutilated/scrapped.
92-Scrap No impact- but whenever in card status the status is changed to SCRAP –
a count of 1 is written to cards scrapped field in STOCK. REGISTER live
file.
93-Cancel No impact- when the card status is changed to CANCEL – a count on
cards cancelled is kept in the STOCK. REGISTER live file.

NB. A card cannot be cancelled or scrapped before being issued. That means the CARD.STATUS
has to be 90 before it can assume other status like 92 (scrapped) or 93 (Cancelled).
An exception to the above is that – status 91 (re-issue) which like ISSUE will diminish the stock by
ONE. This status comes into play only when earlier card input for issue is scrapped or cancelled due
to wrong printing of name, date or any other information of significance.

TEMENOS T24 User Guide

Page 32 of 121
System tables

CARD.ISSUE input screen

A charge entry may be raised for the issue depending on the charging structure defined for the card
type on the CARD.CHARGE table. The system checks against account conditions and limits and will
require overrides when appropriate. Only ACCOUNT records with a CATEGORY defined as
allowed in the CARD.TYPE table may be entered for the card type being processed.

TEMENOS T24 User Guide

Page 33 of 121
System tables

Defaulting fields

ISSUE.DATE When the ISSUE.DATE is entered the EXPIRY.DATE will default based
on the frequency defined in CARD.TYPE
EXPIRY.DATE Manually entered or defaulted by system based on CARD.TYPE settings
as detailed above.
REPAY.DATE When the REPAY.DATE is input, the BILLING.CLOSE field is
automatically populated taking the REPAY.DATE less the number of days
defined in the BILLING DAY field of the CARD.TYPE application.
REPAY.DATE is the date on which the customer is expected to pay a
certain percentage on the total drawings made on the credit card plus
interest and charges.
NB The repay date is selected by the customer and changeable at their
request.
BILLING.CLOSE The date on which the withdrawals of the customer are bunched for
arriving at the billing/repayment amount. Any withdrawals made after the
bill close will be taken up during the next billing date, which is cycled
based on the frequency defined in the card issue.
LST.REPAY.DATE REPAY.DATE is entered as a date and frequency. When the date is
reached it will be cycled and the old date moved to LST REPAY DATE.

LST.BILLING.CLOSE Similar to the LST.REPAY.DATE handling, BILLING.CLOSE.DATE is

populated based on the billing day input and when cycled the old date is
stored in LST BILLING CLOSE.

The impact of input in BILLING.DAY on REPAY.DATE and BILL.CLOSE.DATE is shown in the

table below for clarity:

REPAY. DATE (A) BILLING DAY (B) BILL. CLOSE DATE (C)
(CARD.ISSUE) (CARD.TYPE) (CARD.ISSUE)
[C = (A) – (B)
25.10.2003 D-10 15.10.2003
28.10.2003 D-10 18.10.2003

The dates are also affected by holidays, if the dates entered are not working days the system will
modify the input to working days and record the initial values in ORIG.REPAY.DATE &
ORIG.BILLING.CLOSE

TEMENOS T24 User Guide

Page 34 of 121
System tables

CARD.ISSUE (orig. Bill. Close date)

In REPAY.DATE the date was input as 11 Nov 2001 which would have defaulted a BILLING.CLOSE
of 04 Nov 2001; as the date is a holiday the system has written that to ORIG.REPAY.DATE and
replaced it with 09 Nov 2001 (ORIG.BILLING.CLOSE with the input value; .and BILLING.CLOSE
updated based on the working days).

TEMENOS T24 User Guide

Page 35 of 121
System tables

Change fields

NEW.REPAY.DATE If the customer requests a change in REPAY.DATE already input, then it has
to be through this field. If any change is made in this field after the bill close
date, then such change will be effective from the next bill generation date
because the bill date has already passed and therefore the bill would have
already been generated.
NEW.BILL.CLOSE Similar to REPAY.DATE, when the customer requests a change in
BILL.CLOSE.DATE, it is done through this field.

Cheque Tables
CHEQUE.TYPE
This file holds the details of each type of cheque supported by the cheque control system.

A CHEQUE.TYPE is defined by a four-letter code, for example:

CURR Current Account cheques

EURO Eurocheques

TEMENOS T24 User Guide

Page 36 of 121
System tables

CHEQUE.TYPE record for cheques issued on Nostro Accounts

Each CHEQUE.TYPE may be assigned a maximum and minimum holding, a default issue quantity
(number of cheques in a book) and a day's notice to allow reports to be produced for accounts
requiring automatic re-issue.

A list of ACCOUNT categories to which cheques may be issued is also recorded for each
CHEQUE.TYPE.

CHEQUE.STATUS
The CHEQUE.STATUS file holds the records and descriptions for the various status of the cheques.

TEMENOS T24 User Guide

Page 37 of 121
System tables

Sample CHEQUE.STATUS record

Records showing basic status type

CHEQUE.ISSUE
The issue of cheques to an ACCOUNT is controlled by the records on this table. Entry is similar to
entering a transaction within other T24 modules. The most significant information entered on a
CHEQUE.ISSUE record is contained in the record ID. This defines the CHEQUE.TYPE being
issued and the ACCOUNT involved. The ID also contains an automatically assigned sequence
number for each issue instruction.

TEMENOS T24 User Guide

Page 38 of 121
System tables

CHEQUE.ISSUE record showing 100 Current A/C cheques issued

Contained in each record is the quantity issued, the date of issue, any charges incurred at issue time
and a record of the cheque numbers involved.

When the issue record is authorised the cheque register for the ACCOUNT is updated with the
number issued. A charge entry may be raised for the issue depending on the charging structure
defined for the cheque type on the CHEQUE.CHARGE table. Charges for the issue of cheques can
be based on the current number held by the ACCOUNT as defined on the CHEQUE.REGISTER.

TEMENOS T24 User Guide

Page 39 of 121
System tables

The system checks against account conditions and limits and will require overrides when appropriate.
Only ACCOUNT records with a CATEGORY defined as allowed in the CHEQUE.TYPE table may
be entered for the cheque type being processed.

CHEQUE.REGISTER
This table holds details of cheque types and numbers held by each account on the system. It is
automatically updated by the cheque control system and only restricted functions are allowed to
update the usage of cheques held.

The keys to the file are the ACCOUNT numbers concerned and for each ACCOUNT the number of
cheques issued in the current charging period, the number used and the number currently held is
recorded.

Logging returned cheque numbers on CHEQUE.REGISTER record

CHEQUE.CHARGE
This file holds details of the charging structure to be applied to all CHEQUE.TYPEs for issues and
periodic usage charges.

TEMENOS T24 User Guide

Page 40 of 121
System tables

CHEQUE.CHARGE example

For each CHEQUE.TYPE it is possible to define individual TRANSACTION codes for debit/credit
and a profit/loss CATEGORY for charges. Issue and periodic charges can then be set up on a band
or level basis. Flat amounts can be defined for each or a zero amount entered to effectively waive
charges by default if required.

In this way a flat amount may be defined for issue, or issues may be charged band or level based on
the current holding of the ACCOUNT in the CHEQUE.TYPE concerned.

Similarly periodic usage charges may be based on a flat amount or on the number of cheques used
during the charging period.

The issue charging period and the usage-charging period may be different since they are based on
separate frequency fields.

TEMENOS T24 User Guide

Page 41 of 121
System tables

Periodic charges can be raised for the usage of cheques during a given period. If it is desired, charges
can therefore be defined for both issue and usage. This may be the case for Euro cheques but would
be less usual for other common types of cheques. The calculation of charges and their definition is the
same as those for issue except that the number involved is taken as the number used during the
charging period. Note that no charges will be applied unless there has been a cheque used during the
charging period. This includes the flat amount per period if defined.

In multi-company databases the CHEQUE.CHARGE records are unique to each company based on
the FIN/FTH settings. This will allow the same basic settings (or independent ones) to be used but
allows the CHARGE.CYCLE dates to be different

Company Tables
COMPANY
The COMPANY file contains details of the Company's name, the Mnemonic (by which all the files
maintain at this company's level are prefixed), the file classification details the applications to be run
and COMPANY level defaults and parameters. For conditions that apply where there is more than
one company in the system, see the Multi-Company section of this guide.

COMPANY record Name etc

TEMENOS T24 User Guide

Page 42 of 121
System tables

Company record dates & rates etc

COMPANY level settings

TEMENOS T24 User Guide

Page 43 of 121
System tables

Company record applications

This application is invoked from one of two sources:

1. Automatically from within the installation process for the loading of a new processing
COMPANY record.
2. On-line to enable amendment or enquiry and the loading of a new Consolidation COMPANY
record.

TEMENOS T24 User Guide

Page 44 of 121
System tables

The procedures for setting up a new processing COMPANY are explained in the Installation guide.

Files containing financial records are kept separate for each COMPANY, but can be combined for
reporting purposes.

Branches working on holidays

The method of defining holiday tables relevant to a company has been modified. This is to aid banks
where branches are open on non-official working days, e.g. weekends. The COMPANY application is
used to define the following:

▪ OFFICIAL.HOLIDAY – the holiday table for the country relevant to the company.

▪ BRANCH.HOLIDAY – the holiday table relevant to the company itself

▪ BATCH.HOLIDAY – the holiday table used to control when the batch is run.

▪ BRANCH.CLOSED – defines individual irregular days when the branch may be closed. This allows
branches with different irregular closing days to share the same holiday table.

The BATCH.HOLIDAY must be the same for all companies unless the GLOBAL.PROCESSING
module has been installed, when it is possible to run close of business processing at company (or
groups of company) level in a multi company environment.

The existing fields LOCAL.COUNTRY and LOCAL.REGION have been made no input, and will now be
updated via the above fields.

CURRENT.DAY has been added to the DATES table to indicate the type of day for that company:

▪ “NORMAL”- indicates that the branch is open for business on an official working day
▪ “RESTRICTED”– indicates that the branch is open on a non-official working day
▪ “CLOSED”– indicates that the branch is closed

TEMENOS T24 User Guide

Page 45 of 121
System tables

BUSINESS.DAY has been added to VERSION to determine on what type of business day the
version can be run. For example certain business activities can only take place on an official working
day whereas other can take place on a weekend:

▪ “NORMAL” – the version can only be run on a normal business day.

▪ “RESTRICTED” – the version can be run on a restricted and a normal business day.
▪ “CLOSED” – the version can be run at any time.

Branch holidays

The official holiday table can be imagined as Monday to Friday as working days with weekends and
public holidays.

The branch is open Monday to Saturday and also on public holidays.

The batch is set to run every day, i.e. every day is defined as a working day.

TEMENOS T24 User Guide

Page 46 of 121
System tables

Define dates

Here we can see that the current day is set to NORMAL in this COMPANY..

TEMENOS T24 User Guide

Page 47 of 121
System tables

Set run date for a Version for an FT clearing payment

The above version for FT clearing payments has been set to be able to run only on a normal working
day.

TEMENOS T24 User Guide

Page 48 of 121
System tables

Set run day for a Version for Account Transfer

The above version for account transfers has been set so that it can be run on a restricted working day,
i.e. on a Saturday as well as on normal working days. Note the other options available.

COMPANY.CONSOL
This file holds the descriptions and the details of grouping of Companies for combined CRF reports.

TEMENOS T24 User Guide

Page 49 of 121
System tables

Company Consol Record

The group number is part of the data entered at report production stage.

The default currency for any report produced for the group is entered.

COMPANY.GROUP
COMPANY.GROUP codes are used to identify the various operating companies using the T24
system. The COMPANY.GROUP code is part of the 'T24 Company' key and as such will help in
identifying for a particular operating COMPANY the 'T24 Companies' that have been set up for it.
This will help in reports etc. being grouped/combined.

Thus for each of the T24 COMPANY records for the same operating company, the
COMPANY.GROUP must be the same. Therefore the same COMPANY.GROUP codes will need
to be created at each of the locations where the organisation is operating the T24 system.

The format of the Company Code is:

CC GGG LLLL

TEMENOS T24 User Guide

Page 50 of 121
System tables

Where:

CC Is Country Code
GGG Is Company Group Code
LLLL Is Local Code

Note
Local code must be different for each location/ branch within one country even if the processing is run
in different environments.

The COMPANY.GROUP code thus forms the centre portion of the individual COMPANY records.

COMPANY.GROUP record

INTERCO.PARAMETER
This file contains the details of whether a multi-company accounting environment is being used and if
so the details of the unique part of the ACCOUNT number for each COMPANY.

TEMENOS T24 User Guide

Page 51 of 121
System tables

INTERCO.PARAMETER record

There is only one record on this file and the Id (key) of this record is SYSTEM.

If the record is missing then T24 assumes that a non multi-company accounting environment exists.

Further details are in the User Guide for Multi-company.

INTEREST.BASIS
This system table contains the definitions of each interest basis used by T24. The description is used
as the enrichment whenever any of the codes are used in an application.

Key Days/Numerator Description of Use

A 360/360 This method is where each month is considered to have 30 days for the

TEMENOS T24 User Guide

Page 52 of 121
System tables

numerator and the denominator will also be 360. Subdivided into methods
A1 and A2.

A1 360/360 Similar to A - see examples below for deviation from A.

A2 360/360 Similar to A1 - see examples below for deviation from A1.

This method where the exact number of days will be considered in respect
B 366/360 of the numerator while the denominator will be 360.

This is the method where the exact number of days will be considered in
C 366/366 respect of the numerator while the denominator will be 365 in a non-leap
year and 366 in a leap year.

This method is where each month is considered to have 30 days for the
D 360/366 numerator while the denominator will be 365 in a non-leap year and 366 in
a leap year.

This is the method where the exact number of days will be considered in
E 366/365 respect of the numerator while the denominator will be 365.

This is the method where each month is considered to have 30 days for the
F 360/365 numerator while the denominator will be on a 365 basis. Subdivided into
methods F1 and F2.

F1 360/365 Similar to F - see examples below for deviation from F.

F2 360/365 Similar to F1 - see examples below for deviation from F1.

This is the method where the exact number of days will be considered in
G 366/364 respect of the numerator while the denominator will be 364.

Hirja method. Similar to 360/360 but the day calculations use the 360 year
H 360/356 (30 days per month) only the denominator is changed to 356 instead of
360.

S Note 1 Special (Special interest basis).

Table showing Interest Basis records in T24

Note 1. Basis S – Special Interest Basis

This basis is used to allow the interest amount to be entered manually. The amount entered is
checked against the nominal rate entered, and to avoid mis-typed amounts, is checked against a
tolerance.

Note 2. Conventions

TEMENOS T24 User Guide

Page 53 of 121
System tables

Where actual dates are used the convention in T24 is that the number of days in the year is calculated
taking into account whether the year is a leap year or not. The leap year does not need to be straddled
by the start/end date. If the start date is in a leap year and the end date is in the following year then
the number of days is calculated on 366 for the days in the leap year, plus 365 for the days in the
following year.

A1, A2 and F1, F2 are sub-options of the 360/360 and 360/365 bases respectively. The detail of the
method for treating each month as 30 days differs slightly as described below.

In the options A, B, C, D, E, F, and G specified above the number on the left (Days) represents the
number of days basis for multiplying on the top line of the interest calculation. Whilst the number on
the right (Numerator) is the basis for dividing on the bottom line of the interest calculation and
represents the number of days in the year.

For example, if Interest Basis B (366/360) is selected, then the interest calculation would look as
follows:

Principal Amt x Rate x 366

360

Where 366 are specified as the left factor (Days), interest will be calculated for the actual number of
days in the month.

Where 360 is specified as the left factor (Days), each month will be treated as having 30 days when
calculating interest. In months with 31 days, the 30th day is ignored. In February, either the last or the
penultimate day is counted as 3 days (or 2 days in a leap year) depending upon which 30-day rule is
chosen.

Methods A1 and F1 are the same as A and F respectively. Under these methods, the additional
interest earned in February is calculated on the last day (i.e. 28th or 29th).

Methods A2 and F2 calculate the additional interest earned in February on the penultimate day (i.e.
27th or 28th).

Examples of Dates for each Basis

Dates A B C D E F G A2 F2
01 Jan 1999 - 31 Mar 1999 89 89 89 89 89 89 89 89 89
01 Jan 2000 - 31 Mar 2000 89 90 90 89 90 89 90 89 89

TEMENOS T24 User Guide

Page 54 of 121
System tables

01 Dec 2000 - 30 Jun 2001 209 211 211 209 211 209 211 209 209
01 Dec 1999 - 30 Jun 2000 209 212 212 209 212 209 212 209 209
27 Feb 1998 - 31 Mar 1998 33 32 32 33 32 33 32 33 33
27 Feb 2000 - 31 Mar 2000 33 33 33 33 33 33 33 33 33
28 Feb 1998 - 31 Mar 1998 32 31 31 32 31 32 31 30 30
29 Feb 2000 - 31 Mar 2000 31 31 31 31 31 31 31 30 30

Examples of Dates for each Basis

Securities & Interest Basis

Interest Basis 'C' & 'D' used in securities follow the rules indicated as under:

SEC.TRADE uses 366 days in the denominator when required. The example below illustrates this:

A bond that pays 2 coupons of 10% a year on the 20th of December and 20th of June. The nominal
amount of 1 Million was being traded on the 20th of March 2000. This would result in the following
calculations for the coupon element of the consideration:

Nominal 1,000,000
Rate 10%
Number of days 11 + 31 + 29 + 20 = 91
Basis denominator 365

Interest 1,000,000 x 0.10 x 91 / 365 = 24,931.50

Interest Basis

Coupon Payment Calculation in T24 uses 366 days when required. The above example can be used
to illustrate this:

Nominal 1,000,000
Rate 10%
Number of days 11 + 31 + 29 + 31 + 30 + 31 +20 = 183

TEMENOS T24 User Guide

Page 55 of 121
System tables

Basis denominator 366

Interest 1,000,000 x 0.10 x 183 / 366 = 50,000.00

Interest Basis

Interest Basis ‘G’ is used in Securities as follows:

For Instruments that are issued with coupon dates that occur at set intervals (number of days), these
instruments always pay on the same day of the week. For example a bond is issued with a 2-year life
(728 days, 2 x 52 x 7) and will be paid twice a year. Each period will be of 182 days (26 weeks x 7
days per week); a year will always be 364 days. For such Bonds each coupon period will be an exact
multiple of 7 days. It should be noted that when this Interest Basis is selected then the number of
payments must be a divisor of 52 (weeks in a year), i.e. 1, 2, 4, 13, 26 or 52.

Hirja Basis ‘H’

The rules that will govern the new interest basis, H 30/356, will be as follows:
30/356 For two dates (Y1,M1,D1) and (Y2,M2,D2):
If D1 is 31, change it to 30.
If D2 is 31 and D1 is 30, change D2 to 30.
Then the date difference is (Y2-Y1)x360+(M2-M1)*30+(D2-D1). The denominator used will be 356.

Examples using ‘H’

27 Feb 2003 - 28 Feb 2003 3 days
100,000 / 356 x 6% x 3 = SAR 50.56

The three examples below illustrate, more fully, that by using this new interest basis the calculations
performed by the system will result in the higher calculation of charges. This is caused as a result of
using a lower denominator i.e. 356.

01 Jan 2003 - 31 Dec 2003 359 days (11*30+29)

100,000 / 356 x 6% x 359 = SAR 6,050.56

01 Jan 2003 - 01 Jan 2004 360 days (1*360 )

100,000 / 356 x 6% x 360 = SAR 6,067.42

01 Jan 2003 - 25 Dec 2004 714 days (1*360+11*30+24)

TEMENOS T24 User Guide

Page 56 of 121
System tables

EB.ACCRUAL.PARAM
This application is used to amend the standard accrual calculations performed by T24, which can be
invoked in applications such as LD, SL and PD.

Decisions, such as whether to include the first or last day, and the impact of principal
increases/decrease, together with the option to have user routines called allow this to be very flexible
for bespoke accrual scenarios.

It must be noted that changing the days, which are included, can have an effect on the amount of
interest calculated and that the settings should be checked thoroughly before being used.

As an illustration here are three methods used in Japan:

Ryoha
Interest is earned on the first and last day of the period.

Principal repayment and decreases are taken into effect in interest calculations the next
calendar day after the repayment/decrease.

Principal increases and decrease take effect for interest purposes on the day of the increase.

RYOHA method settings

TEMENOS T24 User Guide

Page 57 of 121
System tables

Kataha-End
Interest is earned for the last day of the period but not the first day.
Principal repayment and decreases take effect in the interest calculations the next calendar
day after the repayment/decrease.
Principal increases take effect for interest purposes on the day of the increase.

KATAHA-END method settings

TEMENOS T24 User Guide

Page 58 of 121
System tables

Kataha-Start
This is the current default option supported by T24 contracts.
Interest is earned for the first day of the period but not the last day.
Principal repayment, decrease and increase all take effect for interest purposes on the day of
the movement.

KATAHA-START method settings

EB.ACCRUAL.PARAM records need to be entered for each of the above interest calculation
methods. The field ACCRUAL.PARAM on LD.LOANS.AND.DEPOSITS, PD.PAYMENT.DUE and
ACCRUAL.ID on SL.LOANS is used to select the relevant EB.ACCRUAL.PARAM record.

TEMENOS T24 User Guide

Page 59 of 121
System tables

EB.SERVICE
The EB.SERVICE records create a link between the activities in PW (Process Workflow) and the
TAG service so an automated activity, or set of activities, can be processed via a web service.
Most of the processing will be based on user defined activities and localised code.

EB.SERVICE record

TEMENOS T24 User Guide

Page 60 of 121
System tables

ENQUIRY SERVICE.LIST
This enquiry record will display the service name, the activities associated with it and the target for the
activity (to be picked up from PW.ACTIVITY) in every row. This should accept a SERVICE.NAME as
selection criteria.

SERVICE.LIST ENQUIRY

TEMENOS T24 User Guide

Page 61 of 121
System tables

CONDITION.PRIORITY
The purpose of this table is to specify, for certain applications, which data elements in other reference
applications could be specified to determine condition groups.

CONDITION.PRIORITY records can be created with the following IDs:

• ACCOUNT
• FIDUCIARY
• FUNDS.TRANSFER
• LETTER.OF.CREDIT
• SC.MANAGEMENT
• SC.SAFEKEEPING
• SC.TRADING
• STATEMENT
• TAX

CONDITION.PRIORITY is a CUS type table. Its records can be shared between Companies which
share the same Customer Company, or there could be Company specific CONDITION.PRIORITY
records by suffixing a hyphen and a Company Code in the ID. For example, for the application
ACCOUNT, it is possible to have a specific record for the Company DE0010001 with the ID:
ACCOUNT-DE0010001.

The (parameters in the) records without a Company ID suffixed would be applicable to the Master
Customer Company (specified as CUSTOMER.COMPANY in the COMPANY application) as well as to
Companies that do not have their own CONDITION.PRIORITY records.

It would not be possible to modify an existing CONDITION.PRIORITY record. However, it would be

possible to specify parameters that are applicable in future (after the COB Processing on a specified
date which could be either the processing date or any future date) by creating
CONDITION.PRIORITY records by suffixing a hyphen and a date after the Company Code in the
ID; for example, the record with ID “ACCOUNT--20040702” (with a Null Company ID for the Customer
Company) would be applicable to the Master Customer Company and the record with ID “ACCOUNT-
DE0010001-20040702” would be applicable to the Company DE0010001; both records to be effective
after the COB processing on 2nd July 2004. The date specified could be either the processing date or it
could be a future date.

It is possible to specify as Priority Items (Field: PRIORITY.ITEM) fields from CUSTOMER

application in all CONDITION.PRIORITY records; fields from ACCOUNT application could be
specified only in the CONDITION.PRIORITY records related to ACCOUNT or STATEMENT; the fields
from SEC.ACC.MASTER could be specified only in the 3 record related to SC application (with IDs

TEMENOS T24 User Guide

Page 62 of 121
System tables

SC.MANAGEMENT, SC.SAFEKEEPING, SC.TRADING). The Priority Items specified in the

CONDITION.PRIORITY records would be defaulted as the field names in the corresponding
XX.GEN.CONDITION records.

While determining the applications’ condition groups, the priority of the data items (specified as
PRIORITY.ITEM) would be determined by their relative position in the CONDITION.PRIORITY
record.

For each Priority Item specified in CONDITION.PRIORITY, it is also possible to specify a validation,
which would ensure that a value entered for a Priority Item (in XX.GEN.CONDITION tables) exists as
a record ID in another table; this could be also used to display an enrichment when the value is
entered.

For example, in the CONDITION.PRIORITY record for ACCOUNT, the PRIORITY.ITEM

“ACCOUNT>CATEGORY” could have a validation specified in the field PRTY.VALIDATION as
“CATEGORY>DESCRIPTION”. In this case, when a value for the field CATEGORY is entered in
ACCT.GEN.CONDITION, the value entered should be a valid record ID in the Application
CATEGORY, and the value of the field DESCRIPTION in that CATEGORY record would be
displayed as an enrichment.

CONDITION.PRIORITY record

XXX.GEN.CONDITION and XXX.GROUP.CONDITION

The XXX.GEN.CONDITION applications provide the parameters to calculate the default groups for
some applications. The priority data items, which are used in the XXX.GEN.CONDITION tables,
are defaulted from the corresponding CONDITION.PRIORITY records.

TEMENOS T24 User Guide

Page 63 of 121
System tables

The XXX.GEN.CONDITION applications and the corresponding CONDITION.PRIORITY

records from which the priority data items are defaulted are listed below:

XXX,GEN.CONDITION Applications CONDITION.PRIORITY record ID from which

priority data items are defaulted
ACCT.GEN.CONDITION ACCOUNT

FD.GEN.CONDITION FIDUCIARY

FT.GEN.CONDITION FUNDS.TRANSFER

LC.GEN.CONDITION LETTER.OF.CREDIT

SCPM.GEN.CONDITION SC.MANAGEMENT

SCSK.GEN.CONDITION SC.SAFEKEEPING

SCTR.GEN.CONDITION SC.TRADING

STMT.GEN.CONDITION STATEMENT

TAX.GEN.CONDITION TAX

Of the above-referred XXX.GEN.CONDITION applications, the parameters specified in

FD.GEN.CONDITION, FT.GEN.CONDITION, LC.GEN.CONDITION,
SCPM.GEN.CONDITION, SCSK.GEN.CONDITION, SCTR.GEN.CONDITION and
TAX.GEN.CONDITION are used to default the condition groups in the CUSTOMER.CHARGE
application.

The parameters specified in ACCT.GEN.CONDITION are used to default the account group
(CONDITION.GROUP) in ACCOUNT; while those specified in STMT.GEN.CONDITION are used to
default the frequency in ACCOUNT.STATEMENT.

TEMENOS T24 User Guide

Page 64 of 121
System tables

Corresponding to each XXX.GEN.CONDITION table, there exists a XXX.GROUP.CONDITION

table (except for STMT.GEN.CONDITION) for defining the various parameters for each group. The
following

XXX.GROUP.CONDITION records exist:

ACCT.GROUP.CONDITION
FD.GROUP.CONDITION
FT.GROUP.CONDITION
LC.GROUP.CONDITION
SCPM.GROUP.CONDITION
SCSK.GROUP.CONDITION
SCTR.GROUP.CONDITION
TAX.TYPE.CONDITION (For TAX.GEN.CONDITION)

All the XXX.GEN.CONDITION and XXX.GROUP.CONDITION tables referred here are of the
FTD type, which might be Company specific or shared between Companies depending on how the
fields DEFAULT.FINAN.COM or SPCL.FIN.FILE are configured in the COMPANY record.

For example, if the FTD type files for the Company DE0010001 are unique, then the
ACCT.GEN.CONDITION records for the Company DE0010001 would have their data items
defaulted from the CONDITION.PRIORITY record with ID: ACCOUNT-DE0010001 if that record
exists; else from the default CONDITION.PRIORITY record with ID: ACCOUNT .

While defining CONDITION.PRIORITY records to be applicable in future, it is possible to specify

which XXX.GEN.CONDITION and XXX.GROUP.CONDITION records need to be retained by
specifying their IDs in the fields GEN.COND.KEEP and GROUP.COND.KEEP respectively. During COB
processing on the specified date, these XXX.GEN.CONDITION records would be automatically
modified with priority data items applicable for the new structure, by retaining existing priority data
items and their values; and new priority data items updated with null values.

Further, in conjunction with dated CONDITION.PRIORITY records, it is also possible to specify

dated XXX.GEN.CONDITION records, which could become effective in future. Such
XXX.GEN.CONDITION records are defined by suffixing a hyphen with a date (either processing
date or a future date) in the ID. Priority data items in these records would be defaulted from the
corresponding dated CONDITION.PRIORITY records; these record IDs should not have been defined
as retention record IDs in the field GEN.COND.KEEP of CONDITION.PRIORITY.

After COB processing on the specified date, the dated XXX.GEN.CONDITION records would
replace the corresponding records without a date in the ID.

TEMENOS T24 User Guide

Page 65 of 121
System tables

Those XXX.GEN.CONDITION records whose IDs are not included in the field GEN.COND.KEEP of
the corresponding dated CONDITION.PRIORITY record or those records which do not have a
corresponding dated XXX.GEN.CONDITION record, would be dropped after the COB processing
on the specified date.

With the exceptions described below, similar to dated XXX.GEN.CONDITION records, it is also
possible to define XXX.GROUP.CONDITION records with a ID of the format “xxx-Date” to be
applicable in future, provided the ID is not already specified in the field GROUP.COND.KEEP of the
corresponding dated CONDITION.PRIORITY record. After COB processing on the specified date,
the dated XXX.GROUP.CONDITION records would replace the corresponding records without a
date in the ID.

There is an exception to the above referred functionality (which existed before the
CONDITION.PRIORITY application has been enhanced to accept dated records): The ID of the two
applications SCPM.GROUP.CONDITION and SCSK.GROUP.CONDITION would be of the
format “xxx.date” (both parts mandatory and connected by a dot), to allow definition of parameters
which would apply on various dates. The first part of the ID would be validated against the first part of
the corresponding XXX.GEN.CONDITION records. When the records in these applications are
input, there would be no validation, against the CONDITION.PRIORITY records.

Those XXX.GROUP.CONDITION records whose IDs are not included in the field
GROUP.COND.KEEP of the corresponding dated CONDITION.PRIORITY record, or which do not
have a corresponding dated XXX.GROUP.CONDITION record (suffixed to the ID with a hyphen
and date), would be dropped after the COB processing on the specified date. However, Customer
specific XXX.GROUP.CONDITION records with ID of the format: “C-Customer ID” would not be
dropped after COB processing.

Example:

CONDITION.PRIORITY for ACCOUNT is based on the data items CATEGORY and SECTOR.

CONDITION.PRIORITY for ACCOUNT to be effective after 20040702 should be based on the

data items CATEGORY and RESIDENCE.

ACCT.GEN.CONDITION and ACCT.GROUP.CONDITION records exist with IDs: 1, 2, 3 and 99.

Existing ACCT.GEN.CONDITION records:

ID 1: ITEM;ACCOUNT>CATEGORY
VALUE:1001

TEMENOS T24 User Guide

Page 66 of 121
System tables

ITEM;CUSTOMER>SECTOR
VALUE:Null

ID 2: ITEM;ACCOUNT>CATEGORY
VALUE:1001
ITEM;CUSTOMER>SECTOR
VALUE:1000

ID 3. ITEM;ACCOUNT>CATEGORY
VALUE:1002
ITEM;CUSTOMER>SECTOR
VALUE:Null

ID 99: ITEM;ACCOUNT>CATEGORY
VALUE:Null
ITEM;CUSTOMER>SECTOR
VALUE:Null

TEMENOS T24 User Guide

Page 67 of 121
System tables

Expected ACCT.GEN.CONDITION records with modified priority data items and values, after
20040702:

ID 1 – To be retained without change in the existing values

ITEM;ACCOUNT>CATEGORY
VALUE:1001
ITEM:CUSTOMER>RESIDENCE
VALUE:Null

ID 2 - To be dropped

ID 3 - To be retained with the following changes in the values

ITEM:ACCOUNT>CATEGORY:
VALUE:1002
ITEM:CUSTOMER>RESIDENCE
VALUE: GB (Earlier value: Null)

ID 99 - To be retained without changes in the existing values

ITEM: ACCOUNT>CATEGORY
VALUE:Null
ITEM: CUSTOMER>RESIDENCE
VALUE:Null

To achieve this, the dated CONDITION.PRIORITY record with ID:ACCOUNT--20040702 should be

defined with the fields:

ITEM: ACCOUNT>CATEGORY
ITEM: CUSTOMER>RESIDENCE
GEN.COND.KEEP: 1
GEN.COND.KEEP: 99
GROUP.COND.KEEP: 1
GROUP.COND.KEEP: 3
GROUP.COND.KEEP: 99
Then, the ACCT.GEN.CONDITION dated record should be created with the following ID:

TEMENOS T24 User Guide

Page 68 of 121
System tables

ID: 3-20040702
ITEM: ACCOUNT>CATEOGRY
VALUE: 1002
ITEM: CUSTOMER>RESIDENCE
VALUE: GB

After the COB processing on 20040702, the ACCT.GEN.CONDITION records with IDs 1 and 99
would be retained since they are defined in the field GEN.COND.KEEP; the record with ID “3—
200040702” would replace the one with ID 3 and the remaining record with ID 2 would be dropped.

The ACCT.GROUP.CONDITION records with the IDs 1, 3 and 99 would be retained since they are
defined in the field GROUP.COND.KEEP; and the remaining record with ID 2 would be dropped.

ACCT.GEN.CONDITION record

Country Tables
COUNTRY
This table contains the static details of each individual COUNTRY, for example the name of the
COUNTRY, local currency etc.

The use of the ISO Country codes is recommended as a standard for the key of this table. Dummy
COUNTRY codes may be used for entities that do not have an official COUNTRY code but have a
CURRENCY code, for example the European Currency Unit.

TEMENOS T24 User Guide

Page 69 of 121
System tables

The CURRENCY table must be set up before this table can be created.

COUNTRY record for Italy

The field HIGH.RISK on the application COUNTRY allows the users to indicate Countries that are
deemed either a high or low risk.

COUNTRY.GROUP
The COUNTRY.GROUP table allows countries to be grouped together for use in determining
residence or non-residence when applying charges.

TEMENOS T24 User Guide

Page 70 of 121
System tables

COUNTRY.GROUP record showing grouping of European countries

For example, charges and commissions can be different depending on whether the CUSTOMER is
resident or non-resident in EU. A COUNTRY.GROUP can be set up which contains a list of all the
countries that constitute the EU. This group id can then be used instead of inputting all EU member
country codes in each charge record.

Currency Tables
CURRENCY.PARAM
This table contains the common details for each individual currency. Details such as the Numeric
Currency Code, Currency Name, Number of Decimal Places and the Interest Basis.

These records must be in place before the records/rates can be entered in the CURRENCY table.

TEMENOS T24 User Guide

Page 71 of 121
System tables

CURRENCY.PARAM record for Pound Sterling

This table is used to ensure that the same numeric code and number of decimals are used in each
CURRENCY file. In a multi company environment there can be more than one CURRENCY file.

The name and Interest basis maybe changed at an individual CURRENCY file level. The numeric
currency code can only be changed on the CURRENCY.PARAM file. Once a record has been
authorised the number of decimal places cannot be changed.

CURRENCY.MARKET
The Markets defined on this table are used to identify the correct exchange and revaluation rates to be
applied to each CURRENCY. Different rates are used in instances where a specific
CURRENCY.MARKET exists, e.g. Financial and Convertible markets or where pricing
considerations require separate rates, e.g. Normal Market rates, Notes, Travellers Cheques.

TEMENOS T24 User Guide

Page 72 of 121
System tables

CURRENCY.MARKET record

Up to nine CURRENCY.MARKETS can be created for each CURRENCY but where only one
market exists, this should be defined as 1, which is the default used by other Applications, e.g.
DATA.CAPTURE and FUNDS.TRANSFER.

Example list of CURRENCY.MARKET codes

Currency
This table contains the exchange rates for a particular currency against the local currency of the
company. Rates are segregated by market type; for example cash exchange rates are much wider
and fluctuate far less than interbank rates.

TEMENOS T24 User Guide

Page 73 of 121
System tables

CURRENCY record for EUR

T24 caters for both Middle rate and Buy/Sell Rate environments. Therefore when installing the System
the User must specify, in the COMPANY record, which method is to be adopted. Regardless of which
rates are entered, both Middle and Buy/Sell Rates are used in calculations, e.g.

TEMENOS T24 User Guide

Page 74 of 121
System tables

• Middle Rate is used for monitoring of rate variances.

• Buy/Sell Rates are used (in conjunction with spreads) to calculate Treasury/Customer rates.

When the Middle Rate and the Default Spread are entered, the Buy/Sell Rates are calculated and
when Buy/Sell Rates are input the Middle Rate and the Default spread will be calculated by the
System.

The field QUOTATION.CODE is one of the key rate setting fields as this indicates whether the currency
is quoted as 1 unit of local or as 1 unit of the currency against local.

UK method
The UK method of quoting currencies against the value of 1 GBP pound is the default and no value is
needed in the field, this means the USD rate will be quoted as GBP 1 = USD 1.91.

Continental Method
However, in the other markets (especially in continental Europe) the rates are quoted base on how
much 1 unit of the foreign currency is worth – this does sometimes mean that 1 unit of the foreign is of
such low value the rate is difficult to use, so typically the rate would be modified to read 100 or 1000
units of foreign per local equivalent. The continental method is set by entering a value of 0,1,2,3,4, or
5 (where 0 is for 1 unit; 1 is for 10 units all the way up to 5 for 100,000 units of foreign) in the field
QUOTATION.CODE.

A further rate, REVAL RATE, may be used to indicate the rate to be used for Asset and Liabilities
revaluation. This field is optional, and if present overrides the Middle Rate when calculating Asset and
Liabilities.
The use of the ISO Currency Codes is standard for the ID of this table although an additional numeric
code must be defined and may be used as an alternative ID for accessing the CURRENCY details.
Up to 999 additional elements may be defined according to local requirements.
The CURRENCY table is also used to define rounding amounts, fixed rates, clearing cut-off times,
precious metals as well as spread breakdowns by customer and treasury divisions.

Customer Tables
CUSTOMER
The CUSTOMER application contains all the basic information about any client with which the bank
has dealings. In this sense, a CUSTOMER record will be opened for correspondent banks, brokers,
guarantors, etc. as well as for current and savings ACCOUNT holders.

TEMENOS T24 User Guide

Page 75 of 121
System tables

Example of CUSTOMER record

Most applications refer to the CUSTOMER record during processing; therefore it must be opened
before any CUSTOMER activity can be recorded in T24. CUSTOMER records for banks,
correspondent banks, agents, etc. should ideally be opened at installation of the system even if these
banks are not actually customers of your institution. The existence of these CUSTOMER records will
minimise the input of data in transaction processing applications like MM.MONEY.MARKET,
FOREX, FUNDS.TRANSFER, etc. where details of banks are always necessary to indicate the
settlement details of the transaction. Details in the CUSTOMER record are descriptive and not

TEMENOS T24 User Guide

Page 76 of 121
System tables

financial, i.e. Customer's Mnemonic, Short Name, Address, Nationality, Relationships, etc. are
recorded rather than details of balances that are available in separate records, e.g. CUSTOMER
ACCOUNT.

The field COMPANY.BOOK (with a default value of the Company ID from where the CUSTOMER
record is input) of CUSTOMER, would be defaulted in the field CUSTOMER.COMPANY of the
automatically created CUSTOMER.CHARGE record; and this would determine which Company’s
XXX.GEN.CONDITION records would be used to calculate the default groups for the auto-created
CUSTOMER.CHARGE record.

The field CUSTOMER.COMPANY in the application CUSTOMER.CHARGE would determine which

Company’s XXX.GEN.CONDITION records would be used to calculate the default groups for the
record. This field in the default CUSTOMER.CHARGE record is updated from the field
COMPANY.BOOK (with a default value of the Company ID from where the CUSTOMER record is
input) of CUSTOMER.

The fields SPOKEN.LANGUAGE, JOB.TITLE and LEGAL.HOLDER.NAME. on the CUSTOMER are

optional and linked to the applications SPOKEN.LANGUAGE and JOB.TITLE. The later field has
been added to cover the possibility that a Customer’s passport name may be different to the name
that they generally use and this is a free format field with no validation.

TEMENOS T24 User Guide

Page 77 of 121
System tables

DE.ADDRESS record showing PRINT.1 address

If any of the CUSTOMER address fields are entered into or changed in the CUSTOMER application,
then on authorisation of a CUSTOMER record the corresponding fields on the DE.ADDRESS
application are automatically updated as the basic PRINT.1 address for delivery.

A further field CONFID.TXT is available. This controls the generation of the standard text in the
ordering customer field of the SWIFT messages in the language of the receiving bank. The standard
text in the ORD record in the languages should be set up in the DE.TRANSLATION file.

The fields PHONE.1, EMAIL.1, SMS.1 and FAX. are multi-valued. It should be noted that only
the first occurrence of these fields will update the appropriate fields in DE.ADDRESS.

LEGAL.ID
The field LEGAL.ID forms part of a multi-valued set with the following fields.

TEMENOS T24 User Guide

Page 78 of 121
System tables

New multi-valued set

The fields LEGAL.DOC.NAME and LEGAL.ISS.AUTH are linked to the EB.LOOKUP table which
will allow the users to define there own valid document types and issuing authority. The key to the
record on the EB.LOOKUP table is an abbreviation of the application following by the field name
(within the application) and then * followed by the user defined document name. For example, if
DOC1 was to be a valid document for the field LEGAL.DOC.NAME, then the record on the
EB.LOOKUP table would be input as CUS.LEGAL.DOC.NAME*DOC1.

The following rules apply to the above fields if the LEGAL.DOC.NAME is present then
LEGAL.ISS.DATE becomes a mandatory field. LEGAL.EXP.DATE is not a mandatory field, but the
date entered must be greater than today’s day and also greater than the LEGAL.ISS.DATE if
populated.

Container CUSTOMER records

An option to create special CUSTOMER records to assist in defining joint CUSTOMER or grouping
of CUSTOMER relationships can be achieved using the multiple relationship fields together with the
linked delivery addressing.

TEMENOS T24 User Guide

Page 79 of 121
System tables

The following example uses a relationship based on a family, though the same setup can of course be
done for a corporate entity relationship.

TEMENOS T24 User Guide

Page 80 of 121
System tables

Container type CUSTOMER record

TEMENOS T24 User Guide

Page 81 of 121
System tables

In the above example there are 4 linked CUSTOMER records, the RELATION.CODE is entered first
and establishes the relationship the linked CUSTOMER has to the container, entering this
automatically updates the REVERS.REL.CODE. Next of course is the id of the linked CUSTOMER
which is entered in REL.CUSTOMER and finally the REL.DIV.OPT field.

Whilst the usage of the relationship fields is fairly intuitive the REL.DIV.OPT field needs further
explanation, hence the numbering of the options in the screenshot above. This field is used to set the
delivery addressing for the container, basically where the advices and statements for this
CUSTOMER record should go. Since it is a multiple client record there are likely to be copies sent to
each CUSTOMER so we need a PRINT.1 address, PRINT.2 address and so on.

Option 1 shows an input of P.1 this means create the PRINT.1 address (on DE.ADDRESS) of the
container CUSTOMER using the PRINT.1 record of the linked CUSTOMER.

Option 2 shows an input of P.2 this means create the PRINT.2 address (on DE.ADDRESS) of the
container CUSTOMER using the PRINT.1 record of the linked CUSTOMER.

Option 3 shows an input of A.3 this means create the PRINT.3 address (on DE.ADDRESS) of the
container CUSTOMER using the PRINT.1 record of the linked CUSTOMER. However, use the
name and short name from the container CUSTOMER and only the address of the linked
CUSTOMER.

Option 4 shows an input of C this means create a DE.PRODUCT record for the container
CUSTOMER and populate the MDR.CUSTOMER field with the id of the linked CUSTOMER.
Essentially send a copy of advices/statement to that CUSTOMER.

NB
• The PRINT.1 address of the linked CUSTOMER record is used at all times as a basis for
creating the PRINT.n records of the container.
• Where more than one address is being created and/or where the ‘C’ option is used then a
DE.PRODUCT record is always created.

TEMENOS T24 User Guide

Page 82 of 121
System tables

DE.ADDRESS records created for the container CUSTOMER

DE.PRODUCT record created for container CUSTOMER

Updating the address details of a linked CUSTOMER will update the linked address of the container.
Any changes, deletions or additions to the names and addresses of the associated records will update
the names and addresses of the affected container records.

TEMENOS T24 User Guide

Page 83 of 121
System tables

EB.ROLE
‘Roles’ can be assigned to a CUSTOMER record that has been linked via a relationship to a
Container CUSTOMER this is achieved by the population of the field ROLE.

Firstly the ‘Roles’ need to be defined, this is achieved by inputting them into the application EB.ROLE.

List of EB.ROLE records

The following fields on the CUSTOMER record need to be populated with the relevant data.

Fields on CUSTOMER record that require input

It should be noted that data is only required in the field ROLE.MORE.IN if the field OTHER.INFO.REQ
on the application EB.ROLE has been populated and the field ROLE NOTES is a standard text box
and is optional.

Once a CUSTOMER record is authorised, with the new fields populated, the system will
automatically build the table CUSTOMER.ROLE.

TEMENOS T24 User Guide

Page 84 of 121
System tables

Completed CUSTOMER.ROLE table

Only the first REL.DELIV.OPT value is used when generating DE.ADDRESS and DE.PRODUCT
items.

CUSTOMER.CHARGE
This application has two functions. Firstly, it records the charge groups for T24 applications and
secondly, it records the details regarding the periodic charges to be levied against the CUSTOMER.

TEMENOS T24 User Guide

Page 85 of 121
System tables

CUSTOMER.CHARGE record

The ID of this application could be a Customer ID or it could be “Customer ID-Company ID”. The
record without a Company ID suffixed, would be the default one, which is automatically created when
a CUSTOMER Record is input. Those with IDs “Customer ID-Company ID” are automatically created
when ACCOUNT is opened from the Company.

The charge groups in the default CUSTOMER.CHARGE record would be used for the application
records processing in the Master Customer Company as well as in Companies for which Company
specific CUSTOMER.CHARGE records do not exist. If a Company specific
CUSTOMER.CHARGE record exists, its charge groups would be used for the application records
processing in that Company.

TEMENOS T24 User Guide

Page 86 of 121
System tables

The field CUSTOMER.COMPANY in the application CUSTOMER.CHARGE would determine which

Company’s XXX.GEN.CONDITION records would be used to calculate the default groups for the
record. This field in the default CUSTOMER.CHARGE record is updated from the field
COMPANY.BOOK (with a default value of the Company ID from where the CUSTOMER record is
input) of CUSTOMER.

A charging frequency date will be entered with an ACCOUNT number to debit. These fields are multi-
valued to allow for multiple charging periods. Within each frequency a sub-valued list of charges may
be taken by entering the relevant charge codes.

A separate ACCOUNT used for all commissions and charges payable can be specified. This
ACCOUNT will be used if specified in the FUNDS.TRANSFER application only.

CUSTOMER.DEFAULT
To minimise the input of data required in the creation of new CUSTOMER records, T24 provides the
User with the CUSTOMER.DEFAULT table. This allows him to define any frequently used
combination of an INDUSTRY, DEPT.ACCT.OFFICER, TARGET, CUSTOMER.STATUS and
COUNTRY (Nationality and Residence) code to be linked together by means of the SECTOR code.
When the SECTOR code field is input on the CUSTOMER record the associated codes will then be
retrieved from this table and automatically assigned to the CUSTOMER record if no other input has
been made. This simplifies the opening of a new CUSTOMER record and reduces the amount of
input necessary.

TEMENOS T24 User Guide

Page 87 of 121
System tables

CUSTOMER.DEFAULT record

When the user creates a new record in this table the application will request, as a minimum, the
definition of one default value.

It is important to note that the CUSTOMER application will only refer to this table during the creation
process of new CUSTOMER records. Any further maintenance on the SECTOR code of authorised
CUSTOMER records will not generate new default values.

If a default value is defined in the VERSION file it will take precedence over the value defined in this
table, when the user is creating a new CUSTOMER record using a special version.

CUSTOMER.STATUS
The CUSTOMER.STATUS codes defined in this table are assigned to CUSTOMER records of T24
to enable the bank to classify their clients by any kind of criteria defined locally.

TEMENOS T24 User Guide

Page 88 of 121
System tables

Example CUSTOMER.STATUS record

This enables standard codes to be used when there is a requirement to highlight specific information
relating to CUSTOMER, for example, "Customer Deceased" or "Customer In Jail".

CUSTOMER – Verification
The field DATE.LAST.VERIFIED on the CUSTOMER record allows the date and time that the
record was last input to be recorded, even though changes have not been made to the live record.

This field will only be populated when input takes place via a VERSION that has the routine
ADD.DATE.TIME applied to the VALIDATION.RTN field and DATE.LAST.VERIFIED in the
VALIDATION.FLD field.

This feature is of particular use when used in conjunction with PROCESS.WORKLOW.

Version with ADD.DATE.TIME routine

Additionally, this feature can also be applied to VERSION.CONTROL. Any linked Versions will then
use this functionality.

TEMENOS T24 User Guide

Page 89 of 121
System tables

VERSION.CONTROL with ADD.DATE.TIME routine

DEPT.ACCT.OFFICER
The purpose of the DEPT.ACCT.OFFICER file is to identify each Department and Account Officer
in the bank by means of a code.

An Account Officer code will be assigned to each CUSTOMER record, but may be overridden at
transaction level when necessary. This enables accurate M.I. reports to be produced at the Account
Officer level.

In the same way, a Department code or an Account Officer code will be assigned to each User. This
will be recorded in the USER Profile and will allow easy identification of any user of the T24 System.

Almost all T24 applications default the DEPT.CODE from the DEPARTMENT.CODE specified in the
USER file.

TEMENOS T24 User Guide

Page 90 of 121
System tables

Fields in DEPT.ACCT.OFFICER file

If more than four numeric characters are required for the DAO key then update the
ACCOUNT.OFFICER record in the EB.OBJECT file with the new length.

GLOBAL.CUSTOMER
The GLOBAL.CUSTOMER table is used to identify in one single place all the multi-national
CUSTOMER records to which the bank wants to assign, on a worldwide basis, a unique identification
number.

The GLOBAL.CUSTOMER number can then be entered in a CUSTOMER record to link together
various CUSTOMER records.

TEMENOS T24 User Guide

Page 91 of 121
System tables

GLOBAL.CUSTOMER input screen

If for example you have defined in your CUSTOMER database different records for Citibank Brussels,
Citibank London, Citibank Tokyo, Citibank Sao Paulo, etc., each of these CUSTOMER records can
be linked together by means of the GLOBAL.CUSTOMER number, which would refer for example,
to 'Citicorp Group.'

Ideally, this list of GLOBAL.CUSTOMER names and numbers should be defined by your Head
Office which could then request all its branches to send on a regular basis, management information
on any activity they have with these clients. Your head office will then be in a position to consolidate
the branches' data on a worldwide basis (e.g. global account profitability, global credit exposure item).

Linking CUSTOMER to GLOBAL.CUSTOMER

Relationships between Customers

Relation
The RELATION table is used to specify the various types of relation that could exist between one
CUSTOMER and another. The purpose of identifying such relationship codes is to provide the bank

TEMENOS T24 User Guide

Page 92 of 121
System tables

with the ability to group various clients together (in the CUSTOMER file) for reporting or information
purposes, by whatever criteria are considered relevant.

RELATION input screen

999 different RELATION codes can be defined in this table, and if necessary, up to 999 different
RELATION codes can be assigned to each CUSTOMER record.

This table can be used to define corporate CUSTOMER relations (Group, Subsidiary, Affiliate,
Branch, etc.) as well as private CUSTOMER relations (Father, Son, Mother, Sister, etc.).

It is also possible to create multiple reverse relationships, though this is aimed primarily where the
CUSTOMER record is created as a ‘container’ i.e as a holder to link together related entities or a
family of clients. See the section on CUSTOMER for further details.

RELATION.CUSTOMER
This table is automatically generated by T24 and holds the relationships between customers. User
input is not allowed.

TEMENOS T24 User Guide

Page 93 of 121
System tables

RELATION.CUSTOMER record list

RELATION.CUSTOMER record

Sector
SECTOR codes are defined on this table and assigned to each CUSTOMER record to group them
into broad classifications like Private Sector, Public Sector, Corporate, and Banks etc.

TEMENOS T24 User Guide

Page 94 of 121
System tables

SECTOR record for Financial Corporations

A further and more detailed classification of CUSTOMER records is available by using INDUSTRY
codes.

The SECTOR codes must be defined carefully because they will be used in the CUSTOMER
application and as the ID to define the CUSTOMER.DEFAULT records.

Finally it must be noted that if required, additional data elements can be created in the CUSTOMER
and other T24 records. This being done by means of the standard LOCAL.TABLE and
LOCAL.REF.TABLE as explained in the System Administration Chapter on “Local References and
Alternate Keys”.

Target
TARGET codes defined on this table are assigned to CUSTOMER records of T24 to indicate how
the CUSTOMER fits in with the Bank's overall marketing strategy. For example, TARGET codes
could be defined as Prime Customer, High Net worth etc.

TEMENOS T24 User Guide

Page 95 of 121
System tables

TARGET record for High Net Worth Customers

Industry
INDUSTRY codes are defined on this table and assigned to each CUSTOMER record to identify the
INDUSTRY in which the CUSTOMER is trading. If a CUSTOMER is trading in various types of
industries only his main one should be specified.
This will enable reports to be produced to provide information on the industries that the bank is
financing and to analyse the risk within them.

Example of INDUSTRY record in Model Bank

A default INDUSTRY code can be linked to a SECTOR code on the CUSTOMER.DEFAULT table.
When this SECTOR code is input on the CUSTOMER record the associated INDUSTRY code will
then be retrieved automatically.

TEMENOS T24 User Guide

Page 96 of 121
System tables

The field HIGH.RISK on the application INDUSTRY allows the users to indicate Industries that are
deemed either a high or low risk.

Up to 9999 INDUSTRY codes may be specified.

Duplicate Contract Checking

It is possible to check for the occurrence of duplicate contracts.

EB.DUPLICATE.TYPE
This file acts as a parameter file to allow for the definition of selected fields to check against within a
given application, for the occurrence of any duplicate contracts.

The application in which to check for duplicates should first be defined on the APPLICATION field of
the EB.DUPLICATE.TYPE file. A specific field (or fields) from the STANDARD.SELECTION
record for that application (although at the moment duplicate checking is only used with FT’s) can then
be input to FIELDS. T24 will then check for the occurrence of any duplicate contracts within the
application against the fields defined.

The PURGE.DAYS field on this file defines the number of days that the record of any duplicate
contracts found will remain on the EB.DUPLICATE file (see below).

Once authorised, the APPLICATION field of the EB.DUPLICATE.TYPE record becomes 'no
change.' It is however possible to change the FIELDS. However at present, EB.DUPLICATE is only
available for searching for FT contracts.

As an aside, if the fields are changed, and a record for that EB.DUPLICATE.TYPE has already
been found, and is subsequently held on the EB.DUPLICATE file, the old fields will not be removed
from the EB.DUPLICATE record. Therefore it is recommended that new EB.DUPLICATE.TYPE
records be made instead of changing existing ones.

TEMENOS T24 User Guide

Page 97 of 121
System tables

EB.DUPLICATE.TYPE record for FUNDS.TRANSFER record to be checked for duplicates

EB.DUPLICATE
The EB.DUPLICATE file stores the records of all duplicate contracts, in accordance with the criteria
defined on the parameter file EB.DUPLICATE.TYPE.

The duplicate FT contracts matching the criteria will be listed under the field heading TRANS.REF.
The period for which the duplicate contract record will remain on this file will have been defined in the
PURGE.DAYS field on EB.DUPLICATE.TYPE.

TEMENOS T24 User Guide

Page 98 of 121
System tables

Override indicates possible duplicate deal

Example of EB.DUPLICATE record created

Error messages
EB.ERROR
The EB.ERROR table defines T24 Application errors in multiple languages. Any event that causes an
application error message to be displayed will now access this table.

Error messages that have been defined on the table can be set-up to contain background information
about the error message and what the necessary steps to take to resolve the problem. This Function
is available in Desktop only. This information will be displayed together with the error message at the
time the error message is triggered.

TEMENOS T24 User Guide

Page 99 of 121
System tables

Background information comments can be set-up in the Error Information field).

Any comments on procedures for resolving the problem can be added into the ERROR.SOL field. The
Alternative Error Code - ALT.ERROR.CD field has been implemented to reduce the duplication of
common error messages. It contains the key of an alternative error record on the EB.ERROR table.
Only the Record Key and the ALT.ERROR.CD fields need to be defined if this field is used. All details
for the error message will be retrieved from the Alternative Error message record.

The EB.ERROR application

Errors can be configured to behave and appear differently depending on the ‘Channel’ that is used to
access T24. For example, a Call Centre or Internet User may access T24 via different channels and
can therefore be presented with a different type of Override and Error message. Further information
on this functionality, including setup instructions, are contained in the Browser Navigation User Guide.

Holiday
The purpose of this table is to indicate the public holidays for each COUNTRY or REGION within a
COUNTRY, for the calendar years over which the bank's current business is spread.

TEMENOS T24 User Guide

Page 100 of 121
System tables

US HOLIDAY record

Each T24 application will refer to this table during input validation to verify that any dates entered by
the User are working days or to force an override to accept non-working days. It is also used to
determine the delivery date, by taking non-working days into consideration.

TEMENOS T24 User Guide

Page 101 of 121
System tables

The REGION and COUNTRY tables must be set up before this table can be created.

You must indicate for each COUNTRY or REGION the public holidays, and which day(s) of the
week make up the weekend. The non-working weekend days are then generated automatically for the
year and for this reason they do not have to be specified individually as public holidays.

With the increasing use of multibook systems, where the T24 system is being run almost each day to
accommodate branch processing and different weekend working across country regions it is now
possible to specify every day as working with the exception of key holidays and to define the
weekends by specified days in each month.

DATES
The DATES application holds a record for each company (plus one for the cob itself) as the next and
previous working days can and do differ between companies in a multibook setup.

DATES records

Local Reference Tables

LOCAL.TABLE
Local elements may be defined for applications that have a LOCAL.REF field, (e.g. the CUSTOMER
file), and enable you to create additional input fields that may be needed to meet local requirements.

TEMENOS T24 User Guide

Page 102 of 121
System tables

LOCAL.TABLE input for Security Type Trading input fields to be linked to CUSTOMER application

This table allows the specific details of such fields to be defined, including the name of the input field,
the minimum and maximum number of characters, the type of characters, all possible input values and
whether the input is to be validated against the key of another table.

LOCAL.REF.TABLE
Once all the definitions have been made in LOCAL.TABLE the next step is to specify where the
fields are added and their inter-relationship with other local fields. This is set in LOCAL.REF.TABLE;

TEMENOS T24 User Guide

Page 103 of 121
System tables

on authorising the record the system will update the relevant STANDARD.SELECTION record (and
internal dictionary) for that application.

LOCAL.REF.TABLE linking Local Table items to CUSTOMER application

Up to 999 elements may be specified for each application that allows LOCAL.REF fields.

Although a more detailed explanation and better examples are to be found in the System
Administration section “Local reference and Alternate Keys” the main points of this file are fairly simple.

The first field (LOCAL.TABLE.NO) is the record on LOCAL.TABLE, which defines the field
characteristics, and the second field defines its relationship with the other local fields.

T24 may allow usage of single, multi-value and sub-value fields but since the local fields are all in one
position (field) on the application these are demoted to single and multi-value only. You cannot
construct a sub-value local field with the same operation as a standard T24 sub-value field.

It is possible to link one or more fields into related groups which expand as a set, this is done in the
second field SUB.ASSOC.CODE shown above.

Charges and commissions

FT.CHARGE.TYPE
This table defines the conditions relating to various types of standard flat charges used by financial
transactions within T24. Each type of charge with related amount(s) must be set up in
FT.CHARGE.TYPE.

TEMENOS T24 User Guide

Page 104 of 121
System tables

Charges may be taken on the basis of “credit less charges” or “debit plus charges” or they may be
waived. Charges in local currency must be entered and foreign currency charges can optionally be
specified. The currency of the account bearing the charge determines the charge currency applied.
Where no charges exist in the account currency, the default local currency charges will apply and the
system will take the currency equivalent using the appropriate rates held on the CURRENCY file.

In all cases the charge amount will be a FLAT amount, regardless of the monetary value of the
transaction, but they may be varied according to the country and zone of the relevant customer and by
currency.

Example of FT.CHARGE.TYPE record

It is also possible to enter a future-dated FT.CHARGE.TYPE allowing changes to parameters to be
input in advance of the effective date being reached. To do this a new record must be input with an ID
of an existing charge type with a suffix of the date when the new record will become effective,
separated by a '-'. On the effective date a start-of-day routine will replace the existing record with the
dated record. For example, a future TLX charge would have a record ID of TLX-20070805. On 5th
August 2007 the TLX-20070805 record would overwrite the old TLX record so that the new parameters
are present on the new TLX record. The NEXT.DATE field holds all future dated record keys for the
charge type.

TEMENOS T24 User Guide

Page 105 of 121
System tables

FT.COMMISSION.TYPE
This table defines the conditions relating to all types of commission used by financial transactions
within T24.

Each commission can be defined as a flat amount or as one that varies according to the amount of the
deal it relates to. In this latter case different percentages can be defined for LEVELS or BANDS of deal
amounts. Minimum and maximum commissions can be specified for each BAND or LEVEL together
with overall minimum and/or maximum commission charges expressed either as fixed amount or as a
percentage. Commissions in local currency must be entered and special foreign currency
commissions can also be defined if required.

TEMENOS T24 User Guide

Page 106 of 121
System tables

Example of FT.COMMISSION.TYPE record

The currency codes specified in this table in association with the percentage or the amount of charges
will always refer to the currency of the transfer, i.e. the debit currency for the inward payments and the
credit currency for all other types of payment. As a minimum, the local currency must be specified and
any currency which has not been defined will then default to these conditions and create the
equivalent amount based on the appropriate rate as held on the CURRENCY file.

It is also possible to enter a future-dated FT.COMMISSION.TYPE allowing changes to parameters

to be input in advance of the effective date being reached. To do this a new record must be input with
an ID of an existing commission type with a suffix of the date when the new record will become
effective, separated by a '-'. On the effective date, a start-of-day routine will replace the existing record

TEMENOS T24 User Guide

Page 107 of 121
System tables

with the dated record. For example, a future PCOMM commission would have a record ID of PCOMM-
20070805. On 5th August 2007 the PCOMM-20070805 record would overwrite the old PCOMM record, so
that the new parameters are present on the new PCOMM record. The NEXT.DATE field holds all
future dated record keys for the commission type.

A valid info basic routine can be specified in the field CHARGE.ROUTINE to calculate the commission
or charge. Once this routine is defined the calculation of commission or charge goes according to the
routine, any other set up in the FT.COMMISSION.TYPE record is ignored.

Example of info basic routine used in FT.COMMISSION.TYPE

This charging routine is developed locally by the client suiting its charging requirement which would be
specific to a country or a bank, to return the charge amount by use of local tables or standard T24
tables. This charge routine has ten parameters. The first nine input parameters are same as that of the
standard T24 routine CALCULATE.CHARGE. The tenth output parameter is the charge amount that
has been calculated. The eighth parameter of the charge routine is an array. The fields 36 to 47 in the
array can be used to pass in and out information specific to the charge routine like the account
number for which the charge or commission is set, period from and period to of the
charge/commission period, narrative etc to the calling application.

TEMENOS T24 User Guide

Page 108 of 121
System tables

Settlement Tables
AGENCY
The AGENCY file contains settlement details for major customers and all banks irrespective of
whether there is any business connection. Details include any arrangements, account relationships
and where possible, the agent’s correspondent bankers for specific currencies. This information is
entered centrally to supply automatic routing instructions for remittances/cover to all banks and
customers with whom the Bank has numerous dealings. This eliminates the need to re-enter the
details at transaction level. It allows full advantage to be taken of electronic delivery facilities by
providing automatically, the settlement agents for remittances/cover involved in outward payments.

Example of AGENCY record

The absence of Agent's correspondent banker’s information in this file will force the user to enter these
details each time at the transaction level.

TEMENOS T24 User Guide

Page 109 of 121
System tables

Any NOSTRO account defined in this table is for information only and will not be used as a default
NOSTRO by the transaction processing application that always uses the NOSTRO.ACCOUNT file.
Record details can be set up on this file using two different Id formats, either the CUSTOMER
number or the BIC CODE prefixed with ‘SW-‘.

Customer Number
The basic details of these banks and major customers must first be defined in the CUSTOMER file
before the creation of the AGENCY details will be allowed. Having created a CUSTOMER record,
which is a Bank, it is advisable to create an AGENCY record with the same key and all available auto
routing details.

BIC Code
The AGENCY records can be created for the BIC code with all the auto routing details. The input of
this record is similar to that of the record created by using the Customer number Id. The exceptions
being that the input are not allowed for NOSTRO.ACCT.NO, OUR.EXT.ACC.NO and THEIR.ACCT.NO
fields.

In the AGENCY file the BIC codes are pre fixed by ‘SW-‘ and should have 14 characters (including
‘SW-‘). The BIC code should be a valid Swift code and can exist on the DE.BIC file. The DE.BIC file
is loaded from the BIC address directory file, supplied by SWIFT. This is detailed in DE.BIC section.

There is a field called VALIDATE.BIC on the DE.BIC.PARAMETER. If the flag is set to YES, then
upon inputting a BIC code (an SW- record), T24 will validate the ID against DE.BIC records. If the
flag is set to NO, then AGENCY will accept any SW- codes as long as they are in the correct format.

Multiple AGENCY record use

It is worth noting that there is an informal linkage between records which comes into effect when the
system is working out the full settlement path for a customer.

Consider an example where a private client wishing to have funds paid to a foreign bank account on a
regular basis. The AGENCY record for this client records which bank the account is held with. We
can then check for an AGENCY record for this bank who may take cover in the foreign currency
through an intermediary bank. Therefore the system can return all this back to the applications without
the need for it to be re-keyed each time.

TEMENOS T24 User Guide

Page 110 of 121
System tables

Using SWIFT BIC Codes in AGENCY record

The Auto routing bank (AUTORTE.BANK) must exist on the AGENCY file and the input can be either
in BIC or CUSTOMER number (or CUSTOMER MNEMONIC). A BIC code can only be used in the
AUTORTE.BANK if the application field is set to FT.

TEMENOS T24 User Guide

Page 111 of 121
System tables

NOSTRO.ACCOUNT
This table defines the NOSTRO account records by Currency and identifies which account is the
default NOSTRO for each function of each application within the specified Currency.

Applying Nostro Accounts to particular functions using NOSTRO.ACCOUNT

The various NOSTRO ACCOUNT records can be recorded for each application.

The definition of NOSTRO.ACCOUNT records within this table eliminates the need to enter the
same details each time for each transaction processed by the various applications of T24.

Note:
FOREX allows fast input of alternate Nostro account values by entering A, B, and C etc. These relate
directly to the first, second, third, and so on, values entered.

TEMENOS T24 User Guide

Page 112 of 121
System tables

Tax Tables
TAX.TYPE
This application allows definition of the types of tax that may be calculated within T24. The TAX table
may have different uses, depending on the local practice. Different types of tax may be calculated
based on different types of transactions and products.

TAX.TYPE record for U.K. VAT

For example, Income tax may be calculated on interest earned, and VAT may be taken on charges
and commissions. There may be several types of VAT, such as GST (Government Service Tax), or a
local regional tax.

Each type of TAX may have different criteria for defining whether a particular CUSTOMER is liable
to the TAX. Conditions for applying TAX for a given set of Customer conditions may be defined using
the applications CONDITION.PRIORITY (record TAX), TAX.GEN.CONDITION. Actual TAX
rates to be applied for Tax Groupings are specified using the applications TAX.TYPE.CONDITION
and TAX.

TAX.GEN.CONDITION

The purpose of this table is to identify, by means of a user defined TAX.GEN.CONDITION number,
a specific group of Customers, which will then be related to the Group Condition Table to define TAX
conditions applicable to that group.

The key to this file is then specified on the TAX.TYPE.CONDITION file for specified TAX types to
allow definition of the applicable TAX rates.

TEMENOS T24 User Guide

Page 113 of 121
System tables

Example of a TAX.GEN.CONDITION record

To create a Group Condition, the user must identify the Group by means of the General Condition
number defined in this table. The Group of Customers will then be identified by means of the details
held within this table.

For a CUSTOMER to be selected, it must conform to every field value defined within the
TAX.GEN.CONDITION to qualify for a specific Group. Amending a CUSTOMER record may
therefore result in reclassification of the CUSTOMER (or ACCOUNT) into another Group or even to
return to the 'normal conditions'.

Tax
The purpose of this table is to define the various TAX rates that could be applicable in your bank on
any type of transaction that the CUSTOMER is doing with you or which will apply on interest paid to
or received from the CUSTOMER. The TAX rate defined for each key will then determine the amount
of TAX to be added to or subtracted from the amount to be given or received by the CUSTOMER.

Tax can either be set to be a flat rate or to be banded. If it is a flat rate the tax is calculated using the
entire principal sum. If the tax is banded then banding needs to be set up for at least one currency and
a default currency must be set from one of them. If the tax is charged in a currency that has no
banding set up it is converted using the mid rate of the default currency.

For each level of a band a CALC.TYPE is set. This can either be LEVEL or BAND. If it is BAND then it
means any amount for the principal to fall between the corresponding UPTO.AMT and the previous

TEMENOS T24 User Guide

Page 114 of 121
System tables

bands UPTO.AMT (or 0 if you are in the first band) are charged to the corresponding BANDED.RATE. If
it is LEVEL then if the principal lies between the current and preceding UPTO.AMT, the tax is
calculated with the associated BANDED.RATE against the entire principal. As you go up the bands, the
CALC.TYPE can only be changed from BAND to LEVEL, not vice-versa. Maximum and minimum
amounts can be applied to each band and to the tax as a whole.

Rounding of the tax amount can be done based on currency by specifying the rounding type
(NATURAL, LOWER or HIGHER) in the field ROUNDING.TYPE and the unit to which the amount
should be rounded in the field ROUNDING.UNIT.

By specifying the rounding type and unit using the fields BASE.ROUND.TYPE and
BASE.ROUND.UNIT, base amount such as interest, commission, charges etc can also be rounded for
tax calculation

It is also possible to indicate whether TAX is to be credited to the tax account in local currency
(TAX.IN.LOCAL) or in the currency of the deal on which it is being applied. If this field is left blank
then TAX will be credited in the currency in which it is calculated. If CURRENCY.MARKET is not blank
then currency conversion will use the mid rate applicable at the time of the calculation using that
currency market, otherwise mid rate from the deal currency market will be used. It is recommended
that a market between 10 and 19 be used to define the tax market so that the standard revaluation
rate for market 1 is used at the Close of Business.

TAX debited to the CUSTOMER will still be posted in the currency in which it is calculated. It is only
the credit to the tax account, which will be posted in local currency.

TEMENOS T24 User Guide

Page 115 of 121
System tables

Example of a TAX input

TAX.TYPE.CONDITION

The TAX.TYPE.CONDITION file links types of CUSTOMER to types of TAX thus enabling T24 to
calculate different levels of TAX depending on the type of CUSTOMER. Using this mechanism, for
example, it is possible to charge a different rate of VAT to residents and non-residents.

TEMENOS T24 User Guide

Page 116 of 121
System tables

TAX.TYPE.CONDITION record for U.K. VAT

To activate this facility you must first set up the different taxes on the TAX.TYPE file. An example of a
TAX on this file would be VAT (value-added tax).

Secondly you must establish the rules by which the different types of CUSTOMERS are to be
determined. To establish these rules you must firstly create a record for TAX on the
CONDITION.PRIORITY file. This record will indicate the fields on the CUSTOMER that are to be
examined when determining the type of CUSTOMER for TAX purposes. For example the user may
decide that the customer's TAX status can be identified from the SECTOR and RESIDENCE codes.

Thirdly you must define the different types of CUSTOMER by setting up the
TAX.GEN.CONDITION file. For example the user may decide that private individuals who are
resident in the local country are a type of CUSTOMER for TAX purposes.

Fourthly you must define the different rates of TAX that may be charged on the TAX table. For
example the user may input records for VAT full rate and VAT reduced rate and VAT zero rate.

TEMENOS T24 User Guide

Page 117 of 121
System tables

Using the APPL.GEN.CONDITION table it is possible to link customer types with the type of
contract to create a contract group code. This code can be used to identify different TAX codes for the
same type of customer for different type of contract.

Finally you link these different tables together on the TAX.TYPE.CONDITION table. At least one
record will be established on this table for each TAX.TYPE. The record then links the types of
CUSTOMER and CONTRACT.GROUP with the TAX rates to be applied. For example a single
record may indicate that for VAT, resident individuals are to be charged 15%, all non-residents are to
be charged 0%, etc.

More than one record may be set up on TAX.TYPE.CONDITION for each type of TAX by the
addition of a numeric sequence. Thus VAT may exist but also VAT-001. This facility is used where
there is more than one set of rates for a particular TAX, for example full rate VAT and reduced rate
VAT.

German Withholding Tax

For details on how to set-up German Withholding Tax processing please refer to the “GWHT” section
of the User Guides.

APPL.GEN.CONDITION
This application is used to define group conditions for contracts based on a combination of decisions
and calls to locally developed subroutines. This allows for example specific tax codes to be applied to
particular types of contract for particular types of customer.

There is one record per application for which many sets of group conditions can be defined. Care
should be taken in defining multiple sets of groups, as the first set of conditions that pass the
validation checks will result in that contract group code being applied.

An associated subroutine will process these decisions and update the field CONTRACT.GRP on the
contract record whenever the contract is changed. If changes to the contract cause the conditions to
be broken then a new CONTRACT.GRP code will be generated, which could result in a different tax
code being applied.

A default group code can be defined as the last group code with no associated conditions if required.
TAX.TYPE.CONDITION allows the CONTRACT.GRP code to be linked to the allocation of specific
tax codes.

This feature is currently available for MM.MONEY.MARKET and LD.LOANS.AND.DEPOSITS

contracts directly and by using a callable routine for other applications.

TEMENOS T24 User Guide

Page 118 of 121
System tables

Example of APPL.GEN.CONDITION record for Money Market application

REVALUATION.PARAMETER
Revaluation can occur at a contract level for contracts arising out of any application within T24
provided that the appropriate revaluation parameters have been set up for it on the
REVALUATION.PARAMETER application and the system is set to be a value dated accounting
system. Additionally, for contracts arising out of securities to be re-valued individually, the securities
system must be set up as a trade dated system.

See the examples in the FOREX User Guide chapter.

EB.EXTRACT.PARAMETER

Extract selected updates of files or complete files

This application allows selected updates of files or complete files to be extracted for use by other
computer systems. The updates are transferred to an area where they can be accessed by other
systems. The files for which this is to be done are named in the ONLINE record.

TEMENOS T24 User Guide

Page 119 of 121
System tables

It can also be used to define files, which are periodically loaded into the extract directory for checking,
defined via the PERIODIC record.

The primary reason for this application is to provide a data source for OFAC checking by third party
systems. The US Office of Foreign Assets Control (OFAC) have regulations regarding dealings with
known narcotics traffickers and terrorists, whereby all customers must be vetted against a published
database before transactions can take place with them.

The entire record is extracted together with all “I descriptor” fields (for example a customer’s name and
address taken from the CUSTOMER record).

Generally, unauthorised updates to target files such as CUSTOMER will be extracted and checked
against the OFAC database before the record is authorised.

The extract process can be triggered by changes to certain fields, such as name and address.

Online extracts definition

EB.EXTRACT
This live file is used to store the extracted records.

TEMENOS T24 User Guide

Page 120 of 121
System tables

Extract records for online transactions will contain all record updates extracted from one T24
transaction with one record per line. JBASE delimiters will be converted to a designated delimiter
character, which defaults to space.

The key to each extract record will be “J.” followed by the T24 JOURNAL file key.

Extract record example

EB.OBJECT

The EB.OBJECT application is used to set the values for standard fields across T24 where they are
being modified from the original settings.

A typical example of this is the use of extended account numbers. Since account number fields are
used across T24 it would take a considerable effort to modify each and every usage of an account
field by application.

Using EB.OBJECT we can set the values to be used across the system and instruct the core IN2
routines to utilise the new settings from one central application.

Note
If extended account numbers are to be used, the user must update the ACCOUNT.MASK held on the
COMPANY record as well. The application AUTO.ID.START must have its ‘ACCOUNT.NUMBER’
record amended so that the ID.START field has the same number of characters as the
ACCOUNT.MASK and the MAX.LENGTH field in EB.OBJECT.

Also remember to change the Account Number field length on any Enquiry or Report so that the
extended account number will fit.

TEMENOS T24 User Guide

Page 121 of 121