T24 Accounts - T3TAC - R11.

1 1
 This course is about the T24 application Accounts and other related
Applications.
The course will enable you to handle Accounts implementation with the
knowledge of :
The dependencies and linkages between Account module and T24 Core and
other applications.
Main business features of the Account module.

T24 Accounts - T3TAC - R11.1 2

 ACCOUNT application caters to creation and maintenance of all types of
accounts handled by T24. In T24, Accounts can be classified as two types,
namely Customer account and Internal type of account. Customer accounts are
accounts opened for and owned by external customers. External customers in
the sense that it should be a valid counter party. Internal accounts are accounts
maintained by the bank for its own purpose, like cash account, Travelers'
Cheque etc.
Accounts module provides for calculation, accrual and application of interest
on customers' accounts. Interest could be either a Fixed or a Floating rate.
Further it can be level or banded. In addition, it is used for calculation of
charges relating to maintenance and servicing of accounts. Rules for interest
and charges can be set for an individual account or for a group of accounts.
T24 Account table stores only the static information of the account. The
financial data is updated in EB.CONTRACT.BALANCES. ECB has the fields
to display the updated account balance field, Date moved fields and Exposure
management fields
It is also used for production of account statements and issue of passbook for
certain class of customer accounts.
It is possible to handle cheque book management in T24 like issuing,
controlling stock, recording payment, noting and effecting stop payment

T24 Accounts - T3TAC - R11.1 3

 instructions.
By linking to another related module called image management, it is possible to verify
signature of account holders. ACCOUNT module has a separate application called
ACCOUNT.CLOSURE for closing accounts. Sweeping of balances between accounts
can also be handled.
A separate course is available for Account sweep and cash pooling.

All the transactional balances and data are held on the EB.CONTRACT.BALANCES
record for the account.

T24 Accounts - T3TAC - R11.1 3

 We need to have Customer records to refer counter party in the case of
customer type of accounts. Customer details such as name, nationality,
residence etc., are not entered in individual account record. These are held in
the customer base record and will be taken from Customer record as and when
required.
Delivery system is used to produce account statements, interest statements and
interest/ charges advices. Formats, addresses and number of copies required
are specified within the delivery system. Interest and charges advices may be
printed or sent via SWIFT. Interest and charges module passes the required
information to delivery system, which transforms it into appropriate messages.
Accounting entries are raised for accrual and capitalisation of interest and
charges. When transactions are input upon various contracts and accounts, the
appropriate account balances are updated on real time basis.
FX contracts require settlement accounts and other contracts like MG, LD and
MM requires drawdown account and liquidation accounts.

T24 Accounts - T3TAC - R11.1 4

 Category codes are used to classify financial products based on the type of
business operation or product. The first two digits of the Category code
represent the highest level classification and the next three digits represent a
sub-classification.
Although it is possible to have Customer type accounts defined in the
Category range of 1000 to 9999, suggested range of sub categories for
different types of accounts are mentioned.
If there is need for defining additional sub-classifications, care is to be taken to
ensure sufficient details do not already exist to provide required breakdown.
For example, we need not define separate CATEGORY codes for resident and
non-resident customers or for local and foreign currency transactions. The
category codes together with other CUSTOMER characteristics like segment
or industry or residence enables Banks to produce profit & loss statements ,
balance sheet and returns reflecting coordinated and structured view of the
operations.
The internal type of accounts falls under the Category range of 10000 to
19999. Internal accounts can not accrue interest. For example sub category
range for cash accounts is in the suggested range of 10000 to 10999, while
suspense accounts, fixed assets account and capital accounts are in the range
of 11000 to 19999.

T24 Accounts - T3TAC - R11.1 5

 Floating interest rates are defined in BASIC.RATE.TEXT and actual rates
applicable are updated in BASIC.INTEREST. In BASIC.INTEREST table,
rate change is indicated with the effective date for such a change, the
underlying Accounts derive the new rate from this table.
It is possible to set negative rate of interest in BASIC.INTEREST. It is used
only in MM, SW and DX applications.
Though negative spread can be specified over basic interest rate for all types
of accounts, it is possible to set negative interest rates only for accounts in
credit balance. To do this, the NEGATIVE.RATES Field on
GROUP.CREDIT.INT or ACCOUNT.CREDIT.INT must be set to Yes or
BLOCK.MARGIN.
If set to YES, this would enable collecting interest from accounts with credit
balances. Negative interest in an account could result due to a negative spread
being higher than the underlying floating rate. For example, a negative spread
of 2% (Minus 2%) on LIBOR which is 1.5%. In this case as the interest being
capitalised is negative, it will be debited from the customer account instead of
making the interest as zero. If set to no, then the rate would be considered as
Zero. If set to BLOCK.MARGIN, negative effect will not be allowed because
of margin. Negative margin can not make the rate more negative or a positive
rate to negative. For Example, If base rate is -7, ( Minus 7%) margin is -2 (
Minus 2%) then net effect will be -7 ( Minus 7%).If margin is +2 ( Plus 2) then

T24 Accounts - T3TAC - R11.1 6

 the effective rate become -5 ( Minus 5).If base rate is +5 ( plus 5%) and margin is -7 (
Minus 7%) then effective rate will be zero not negative.

T24 Accounts - T3TAC - R11.1 6

 FT.COMMISSION.TYPE table is used to indicate pre defined commission to
be collected. For example the charges could be for closing an account or cash
withdrawal charges. The charges could be defined currency wise at a flat charge
for all amounts. It is also possible to set the charges either on level or band
basis. It is possible to set charges and commissions for maintenance of
accounts by linking FT.COMMISSION.TYPE to GENERAL.CHARGE and
collected accordingly. It is also possible to set a Minimum or Maximum
commission to be charged or Overall Min/Max percentage of transaction as
condition for calculation of same.
AC.CHARGE.REQUEST is used as an interbank facility for requesting or
advising many types of charges from other financial institutions.
FT.COMMISSION.TYPE records can be linked to AC.CHARGE.REQUEST
for such charges. TRANSACTION.CHARGE table allows a charge, determined
by the TRANSACTION Id, to be specified for each entry that passes over an
Account during the capitalisation period. The records can also be attached in
TRANSACTION.CHARGE type of General Charge.
Facility is available to accrue or amortise generic charges defined in
FT.COMMISSION.TYPE. For an account or groups of accounts, it is possible
to collect charges on scheduled dates by suitably defining in
IC.CHARGE.PRODUCT and IC.CHARGE. If need be, this could be accrued or
amortised over scheduled period defined in IC.CHARGE.. By using local
routines, it is possible to handle complex charge calculation rules, like
collecting partial charges in case of accounts getting closed before expiry of

T24 Accounts - T3TAC - R11.1 7

 charge period through IC.CHARGE.PRODUCT.

T24 Accounts - T3TAC - R11.1 7

 These are the currency related static tables used by ACCOUNT application.
COUNTRY table is used to record static details of each individual Country,
for example, Country Name, Currency Code, etc.
CURRENCY.PARAM table contains the common details for each individual
Currency such as the Numeric Currency Code, Currency Name, Number of
Decimal Places and the Interest day Basis to ensure that the same details are
used on the different currency files in a multi company environment.
The Markets defined on CURRENCY.MARKET table are used to identify the
correct exchange and revaluation rates to be applied to each Currency. For
example: Different market exchange rate are applicable for notes and travelers
Cheques CURRENCY table holds currency wise details of number of
decimals, exchange rates like buying, selling, middle and revaluation rates for
different currency markets which can be maintained manually or through
interface. .
Consolidation keys for accounts are generated based on the market
mentioned in the account level.
Interest day basis will be defaulted as per the currency used. It is possible to
change at the group level or account level.

T24 Accounts - T3TAC - R11.1 8

 Different interest day basis for calculation of interest is possible depending on
the method followed for calculating number of days in interest period and days
in a year. In the INTEREST.BASIS table, different basis applicable in T24 are
available as A, B,C,D,E,F and None . Here, the number on the left (Days)
(Numerator) represents the basis for number of days in the interest period
whilst number on the right (Denominator) is the number of days taken 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
For A 360/360 , 30 days in each month and 360 days in an year.
For D 360/366 , 30 days in each month and 366 days in an year.
When Interest day Basis NONE is chosen for group of accounts/an account ,
no interest is applied.
Interest day Basis GENERAL and G are used while setting Account specific
interest conditions using ACCOUNT.DEBIT.INT and
ACCOUNT.CREDIT.INT tables. When the account specific conditions are
meant only for a specific period and after which we would like the Group
specific conditions to be automatically applied, we can use the GENERAL

T24 Accounts - T3TAC - R11.1 9

 basis. No interest rate would be allowed to be indicated under this method as the
interest conditions set in the Group level would be automatically applied from the date
indicated in the Ids of these records.

T24 Accounts - T3TAC - R11.1 9

T24 Accounts - T3TAC - R11.1 10
T24 Accounts - T3TAC - R11.1 11
 Preferential conditions for application of interest and charges can be set for
different products to different Customers. CONDITION.PRIORITY table with
Id as ACCOUNT is used to specify data elements from CUSTOMER and
ACCOUNT applications that are used to determine grouping conditions for
accounts.
ACCT.GEN.CONDITION table is used to define rules to the data elements
for grouping of Accounts such that the same interest and charges conditions
are applied to them.
Charges could be based on transactions, or on any debit exceeding a particular
value, or on the turnover of debit transactions in a period, or on the number of
debit transactions in a period, or similar rules for credit operations or on not
maintaining a minimum balance or on statements or any Government levy.
As a first step, charges rules for a Bank are defined in tables like
TRANSACTION.CHARGE, HIGHEST.DEBIT, TURNOVER.DEBIT,
NUMBER.OF.DEBIT, GOVERNMENT.MARGIN, DEBIT.INT.ADDON,
ACCT.STATEMENT.CHARGE, BALANCE.REQUIREMENT,
NUMBER.OF.CREDIT, TURNOVER.CREDIT and
INTEREST.STATEMENT.
Out of these, a combination of charges would be applicable for a group of
accounts or individual accounts which is enabled by key of

T24 Accounts - T3TAC - R11.1 12

 GENERAL.CHARGE table.

T24 Accounts - T3TAC - R11.1 12

 GROUP.CAPITALISATION table is used to specify the next date and
subsequent frequency of capitalisation of debit and credit interest, for a group
of Accounts.
GROUP.CREDIT.INT table allows the specification of a interest rate and
method for credit interest for groups of accounts.
GROUP.DEBIT.INT table allows the specification of a interest rate and
method for debit interest for groups of accounts and provides the link to the
GENERAL.CHARGE table where the charges applicable to the same groups
of Accounts are specified.
GROUP.CONDITION table is used to define Group Level conditions for the
calculation and application of interest, charges and Annual Payment Rate.
ACCOUNT.ACCRUAL table is to provide the system with information at
Company level about how and when to process accruals of interest and charges
on Customer Accounts and whether interest capitalisation is inclusive or
exclusive of the balance on capitalisation date, the value dates of interest
entries generated and the day on which the entries are booked.
ACCT.GROUP.CONDITION can be used to set up select parameters with
regard to operating accounts. Parameters are set group and currency wise.

T24 Accounts - T3TAC - R11.1 13

 Statement related tables are AC.STMT.PARAMETER,
CONDITION.PRIORITY and STMT.GEN CONDITION.
AC.STMT.PARAMETER table is used to define defaults for account
statement details when opening new accounts. When a new account is opened,
an ACCOUNT STATEMENT record, specifying the date and frequency for
printing account statements is generated automatically by the system.
CONDITION.PRIORITY defines the data elements for grouping for statement
purpose STMT.GEN.CONDITION table is used to define rules for
determining the default statement frequency when opening new Accounts.
Account related tables are ACCOUNT. PARAMETER,
ALT.ACCT.PARAMETER and ACCOUNT.CLASS .ACCOUNT.
PARAMETER record contains information relating to Cash flow days, Value
Date Accounting, Alternate Account Identifier Customer Number within
Account Number, etc. ALT.ACCT.PARAMETER forms part of the structure
by which the alternative account can be maintained. ACCOUNT.CLASS is
used to link categories and or sectors for automatic operation of suspense
accounts by various modules, validation of specific class of accounts and
generation of CATEG.ENTRY by some modules. REFERAL and
POSTING.RESTRICT are Account control tables. REFERAL table is used to
establish conditions under which details of an Account or entries over an
Account should be referred to the Account Officer. POSTING.RESTRICT
table is to define any type of restrictions that are to be imposed on Accounts.

T24 Accounts - T3TAC - R11.1 14

 AC.SWEEP.TYPE is used to define user sweep types based on one of the
standard types. Each one can be slightly modified thereby allowing many
variations on the sweeps.

T24 Accounts - T3TAC - R11.1 15

T24 Accounts - T3TAC - R11.1 16
 It is possible to set preferential service conditions for maintenance of accounts.
The conditions are related to various activities which happen during the
lifecycle of an account . Preferential conditions may be set for interest,
charges, other tariff structure, accrual, and statements production. Groups are
determined based on the selected elements from CUSTOMER and ACCOUNT
record. The priority data items from customer and accounts are defined in the
CONDITION.PRIORITY table for the record ACCOUNT.
Conditions for the calculation and application of interest and charges may be
specified at the group level. If an account needs to be set up with different
service conditions from the group to which it belongs, the group conditions
are overridden with special conditions set for individual account level. When
ever an account is opened, it is linked to the appropriate group based on the
details of underlying Customer and nature of account. There must always be a
default group created for accounts.

T24 Accounts - T3TAC - R11.1 17

 Basic elements for interest and charges calculation required are – (1) when
capitalisation is done and (2) at what frequency it is done. This is required
separately for Debit interest and Credit interest as they can differ.
Interest type that is used in the calculation i.e. fixed or floating are set up
currency wise. Interest rates may be set up as level or banded interest rates
with the effective dates . T24 provides the flexibility to calculate interest
based on daily, average or minimum balance available for credit interest
calculation in the account. Similarly it is possible to set debit interest based
on daily, average or maximum balance .
It is possible to set up different type of interest related and ledger fees related
charges. Interest should be defined with effective dates and for each currency.
Interest rates can be set up as fixed or floating. Rate with level and banded
structure. Balance on which interest is calculated can be specified as daily or
average or minimum for credit interest & maximum for debit interest.

T24 Accounts - T3TAC - R11.1 18

T24 Accounts - T3TAC - R11.1 19
 The set up of interest and charges grouping for Accounts structure starts with
CONDITION.PRIORITY table. T24 permits us to decide the order of priority
to apply criteria for creating groups for differential treatment.
Based on the priority and criteria chosen in CONDITION.PRIORITY, the
actual fields are created in ACCT.GEN.CONDITION. Rules and values to
criteria, when specified in this table, will group account records when opened
into appropriate groups. It is mandatory that a default group with no conditions
should be setup before we go on to create conditions attached groups.
Based on these groupings, Capitalisation rules, debit interest conditions and
credit interest conditions for each group need to be setup in
GROUP.CAPITALISATION, GROUP.DEBIT.INT and GROUP.CREDIT.INT.
If needed, account specific rules for all or some of the above 3 can be defined
in ACCT.CAPITALISATION, ACCOUNT.DEBIT.INT and
ACCOUNT.CREDIT.INT files.
Charges related setup is done in related files and linked to
GENERAL.CHARGE which is then attached to GROUP.DEBIT.INT or
ACCOUNT.DEBIT.INT. At least one record for default charges is mandatory
in GENERAL.CHARGE.

T24 Accounts - T3TAC - R11.1 20

 Like forming groups for interest and charges, separate grouping is done for
generation of statements.
CONDITION.PRIORITY with Id as STATEMENT specifies, which data
elements in CUSTOMER and ACCOUNT tables records are used to
determine preference condition groups for statement generation.
The Id for STMT.GEN.CONDITION is pre-determined and indicates the
frequency of statement generation - Daily, Monthly, Quarterly, Six monthly
and Yearly.
Daily frequency generates statements on every working day (every Business
day).
When there is need to set up separate statement generation rules, it is possible
to change the frequency at account level using ACCOUNT.STATEMENT table
which will override the conditions set at group level.

T24 Accounts - T3TAC - R11.1 21

 CONDITION.PRIORITY table is used to define criteria like nationality,
industry , sector etc available in the CUSTOMER application and product
category, currency from the ACCOUNT application.
For example, groups could be saving account of residents , saving account of
non residents , current account of corporates engaged in software industry and
current account of private citizens of US nationality. In these examples,
criteria used are residence , nationality , industry and sector from
CUSTOMER application and savings and current accounts from ACCOUNT
application.
Separate rules should be setup for interest and charges and statement purposes
with record Id in CONDITION.PRIORITY as ACCOUNT and STATEMENT
respectively. If company wise rules are required to be set up then the record Id
of CONDITION.PRIORITY is suffixed with a “-” (hyphen) and company
code namely ACCOUNT-company code and STATEMENT-company code.
Else the data items will default from ACCOUNT and STATEMENT record
Ids .
For example: If separate rules for interest and charges are required for a
company GB0010001 and GB0010002, then two records with ids
ACCOUNT.GB0010001 and ACCOUNT.GB0010002 are required.
If 3 companies setup with defaulting rules different only for third company
namely GB0010003, then 2 records namely ACCOUNT and ACCOUNT-
GB0010003 is setup, where the former is default conditions applied to first 2
companies.
T24 Accounts - T3TAC - R11.1 22
 In CONDITION.PRIORITY , you can rank the proposed selection criteria and
indicate the applications from where the data is to be chosen. Allowed
applications are ACCOUNT and CUSTOMER. Any single value or local
reference fields from these applications can be chosen for making the selection
criteria.
PRIORITY.ITEM is a multi value Field which defines the file and field from
that file used for criteria definition. The format is
APPLICATION>FIELD.NAME. For example, in the
CONDITION.PRIORITY record for ACCOUNT, the PRIORITY.ITEM field
with ACCOUNT>CATEGORY implies that CATEGORY Field from the
application ACCOUNT is an element of criteria.
PRTY.VALIDATION Field indicates details of validation to be displayed as
enrichment for the group definition. For example: In the above when field is
set as “CATEGORY>DESCRIPTION”, then for a value entered in
ACCT.GEN.CONDITION , System validates with CATEGORY table and
DESCRIPTION in that CATEGORY record would be displayed as an
enrichment. The order in which PRIORITY.ITEM is defined in the multi value
set determines the priority of the item. For example : PRIORITY.ITEM.1 and
PRIORITY.ITEM.2 when defined as ACCOUNT>CATEGORY and
CUSTOMER>SECTOR implies that Category from Account is of higher
priority than the other.

T24 Accounts - T3TAC - R11.1 23

 The selection criteria for preference groups can be amended along with or
without change in the ranking conditions. Dated CONDITION.PRIORITY
records are required to be created to achieve this. The effective date could be
either processing date or future date.
Id will be of the format ACCOUNT--<DATE>. The value in the middle field
of Id can be used for company specific definition. Based on the previous
selection criteria, general and group specific conditions would have been built.
As a result of the new selection criteria there would be a need to re-define
rules for some or all of the groups.
While defining CONDITION.PRIORITY records applicable in future , it is
possible to specify which ACCT.GEN.CONDITION and
ACCT.GROUP.CONDITION records need to be retained by specifying their
Ids in GEN.COND.KEEP and GROUP.COND.KEEP Fields.
During COB processing on the specified date, these ACCT.GEN.CONDITION
records would be automatically modified with priority data items applicable
for the new structure, existing priority data items and their values will be
retained...New priority items will be updated with null values.
Advised to leave GEN.COND.KEEP as null so that old records are removed
and new ones redefined. GROUP.COND.KEEP can also be set as ALL to
retain all existing records.

T24 Accounts - T3TAC - R11.1 24

T24 Accounts - T3TAC - R11.1 25
T24 Accounts - T3TAC - R11.1 26
 Lay out of ACCT.GEN.CONDITION and STMT.GEN.CONDITION is
dependent on the settings made in CONDITION.PRIORITY for ACCOUNT
and STATEMENT, respectively.
ACCT.GEN.CONDITION table is used to define rules for grouping together
Accounts for which the same interest and charges conditions apply. T24 allows
the user to form up to 9999 groups with IDs up to 4 numeric digits. One
default group must be defined.
STMT.GEN.CONDITION table is used to define rules for determining the
default statement frequency when opening new Accounts. Accounts that
require the same statement generation frequency are grouped together.
Id for STMT.GEN.CONDITION is pre-determined and indicates the frequency
of statement generation namely . Daily, Monthly, Quarterly, Six-Monthly and
Yearly. Accounts whose details match the conditions specified for Condition
Code 'DAILY' will have a default statement frequency of 'BSNSS' i.e. every
working day.
When CONDITION.PRIORITY record is created with an effective date , after
COB processing on the specified date, the dated Gen condition records would
replace the corresponding record. Those Gen condition records whose IDs are
not included in the GEN.COND.KEEP of the corresponding dated
CONDITION.PRIORITY or those records which do not have corresponding

T24 Accounts - T3TAC - R11.1 27

 Gen condition record, would be dropped after the COB processing.

T24 Accounts - T3TAC - R11.1 27

 Purpose of ACCT.GEN.CONDITION table is to define rules for grouping
together Accounts for the purposes of specifying interest and charges
conditions. The criteria used and their order of priority are specified in
CONDITION.PRIORITY file in the record whose Id is ACCOUNT. Only the
fields selected in the CONDITION.PRIORITY file are included in General
Condition records.
Each General Condition record specifies the combination of field values
defining one Account Group. To define multiple conditions for a group,
MULTIVALUE Field is set to Y and system automatically multi values the
fields.
For example: Group 1 is of current accounts of private individuals residing in
US & UK can be defined as follows. In the record with Group Id as ‘1’ , it
can be defined with first set of fields for current accounts of private individuals
residing in US and another set of fields for current accounts of private
individuals residing in UK. Those accounts which satisfy either of the
condition are classified into the group Id.
The Id of the General Condition record is referred to in other parts of the
system as the Condition Group. Before any Account can be opened, the
Account servicing conditions should have been defined for the group for
capitalisation, debit and credit interest in the currency of the account. At least
one default group to be created .

T24 Accounts - T3TAC - R11.1 28

 .

T24 Accounts - T3TAC - R11.1 28

T24 Accounts - T3TAC - R11.1 29
T24 Accounts - T3TAC - R11.1 30
 Accounts that need to have the same statement generation frequency are
grouped together. For example DAILY frequency may be set up for current
accounts of private individuals residing in USA. It could also be for all current
accounts of all Corporates.
FREQUENCY.TYPE Field identifies whether the statement due date is to be
according to the anniversary of the opening date of the account or the period
end date.
For period end date, the end date depends upon the key of the record.
Monthly - Calendar end date of the month.
Quarterly - Calendar end date for the end of March, June, September or
December.
Six Monthly - Calendar end date for the end of June or December.
Yearly - Calendar end date for the end of December.
If set as ANNIVERSARY, statement are produced on the same day on which
the account was opened . If the account was opened on 15th, then statement
would be produced on 15th of every month under monthly option and 15th of
every quarter under quarterly option.

T24 Accounts - T3TAC - R11.1 31

T24 Accounts - T3TAC - R11.1 32
T24 Accounts - T3TAC - R11.1 33
 Purpose of GROUP.CAPITALISATION table is to specify the next
capitalisation date and subsequent frequency for application of debit and credit
interest, for a group of Accounts. Id is same as that of the corresponding
ACCT.GEN.CONDITION record. It is possible to set separate frequencies for
first and second interest for both debit and credit interest. Out of the four
required frequencies only first debit capitalisation frequency is mandatory.
Interest may be applied any day of the month. Cycles may be different for
debit and credit interest, for example debit interest may be charged monthly
and credit interest paid quarterly unless when credit interest is only calculated
as an offset to debit interest. Frequency can be D(aily) - Every day , B - Every
business day , T - Twice a month on 15th and last day of the month , Wn -
Every n weeks and Mnndd - Every nn months on the dd day. If start of day
capitalisation is needed, then START.OF.DAY.CAP is set as Y. Normally, when
capitalisation date is the first of the month which falls on a holiday, then it will
take place during EOD part of a COB on the next working day. This will be
for what is normally called a split month end. For example if the end of the
month is Friday 31st and the first working day of the next month is Monday
the 3rd, then any accounts set for capitalisation on the first or second of the
month will be capitalised in the start of day processing of the COB starting on
Friday 31st. If the account is not set for start of day capitalisation then the
accounts due for capitalisation on the first or second will be capitalised during
the EOD processing of the COB starting on Monday 3rd.

T24 Accounts - T3TAC - R11.1 34

 It is possible to set different frequencies for interest capitalisation for Credit ,
Credit2, Debit and Debit2 interest. For example, for accounts of Private
individual residing in UK and USA classified as group 1 we can set the
capitalisation frequency as last date of every month for debit interest and to
pay interest for credit interest at the end of every quarter.
On the other hand we can set up for group of current accounts of Corporates to
debit interest every quarter on the last date while for credit balances in the
same accounts, interest is not payable.
SETTLE.ACCT.CLOSE Field is used to indicate whether settlement account
is required while closing accounts falling under this group.

T24 Accounts - T3TAC - R11.1 35

T24 Accounts - T3TAC - R11.1 36
T24 Accounts - T3TAC - R11.1 37
 Rules have to be set up group wise and currency wise to take effect from the
indicated dates for each of the groups created in ACCT.GEN.CONDITION.
Then Id can be 1USD25JAN2008, where 1 is the group Id set up for USD with
the effective date.
General charges and applicable taxes for the group are indicated in
CHARGE.KEY and TAX.KEY Fields. CHARGE.KEY Field is mandatory.
Even if there are no charges to be recovered a null charge key is to be indicated.
TAX.KEY Field hold ids of Tax records (defined in TAX table) or
TAX.TYPE.CONDITION records with a "*" symbol prefixed, which specifies
the calculation and processing of taxes say one or more, applicable to debit
interest. If linked to tax record , then tax rate is applicable on all accounts in
the associated group of accounts. In the latter case, Tax can be collected based
on customer related conditions. CONDITION.PRIORITY needs to be defined
for TAX and grouping rules defined in TAX.GEN.CONDITION. For each
grouping condition, the actual tax rates available in TAX table will be linked to
a TAX.TYPE.CONDITION by defining it in TAX.CODE Field. Hence, when
TAX.KEY in GROUP.DEBIT.INT is defined with an identifier of
TAX.TYPE.CONDITION, then the system will derive the applicable tax rates
based on the customer grouping. No tax is applied if interest is not calculated.
The tax record, if attached must be in existence with an effective date not later
than effective date of GROUP.DEBIT.INT.

T24 Accounts - T3TAC - R11.1 38

 INTEREST.DAY.BASIS gets its default value from respective CURRENCY
table . If it is to be different, then it is possible to indicate the same. If debit
interest need not be calculated, then NONE to be indicated.
Debit interest can be calculated on daily, average or highest balance during the
interest period. The required balance types used for interest calculations to be
defined in DR.BALANCE.TYPE is chosen as AVERAGE for Average balance
taken during the interest period or DAILY for Daily balance taken or
HIGHEST for the highest balance during the interest period.
It is possible to set different rates for range of balances by multi valuing
interest related fields. The calculation method can be effected using LEVEL or
BAND type interest calculation defined through DR.CALCUL.TYPE Field.
For example: Let us take the interest rate to be indicated as 5% for balances
up to USD 5,000 and 6% thereafter. If the account has got a debit balance of
USD 6,000, then under level calculation, 6% interest on entire balance is
applied.
But on the other hand, under band calculation, 5% on first 5,000 and 6% on
the remaining 1,000 is applied.

T24 Accounts - T3TAC - R11.1 39

 When more than one rate of interest is mentioned namely for a level/band
calculation type, then it is possible to define amount up to which the first rate
is applied using DR.LIMIT.AMT. If no limit is specified for the first level and
if second level rates are input , the first rate is applicable up to the overdraft
limit specified for each Account in ACCOUNT.DEBIT.LIMIT table. When
more than 2 levels of rates are defined, then it is a mandatory input.
It is possible to apply fixed or floating rates and different choices are possible
for different balances. It could be fixed for the first slab and floating for the
second slab or floating for the first slab and fixed for the second slab.
Fixed interest rate can be input through DR.INT.RATE Field.
To indicate floating rate, it is linked to BASIC.INTEREST, through
DR.BASIC.RATE Field. Over the floating rate it is possible to apply margin
by adding or subtracting or multiplying using DR.MARGIN.OPER and
indicating the margin in DR.MARGIN.RATE Field.
For example: Current rate 6.75%. If margin rate of 10 is to be multiplied to
this rate, effective rate is 7.425%, being 110% of 6.75
If floating rate is opted, it is possible to indicate a floor rate of interest in
DR.MIN.RATE Field. If this is indicated as 4, then the final rate to be applied
on the account after taking into account the floating rate and its spread, will be
at least 4%.

T24 Accounts - T3TAC - R11.1 40

 If a minimum amount of interest is to be collected from an account, then it is
specified in DR.MIN.VALUE. Interest will be accrued on the account
normally. If it is less than the minimum amount indicated here at the time of
capitalisation, then it can be optionally waived or not. If DR.MIN.WAIVE is
set to “YES”, then debit interest amounts below the minimum value will be
waived and not debited to the account and if it set to “NO”, then value in
DR.MIN.VALUE will be collected.
In the similar manner rules can be set for second interest to be debited from the
respective accounts, over and above the first interest.
All the fields are prefixed with DR2 for this purpose.
For example : A bank may charge additional interest on accounts with average
debit balance under USD 50,000 .
COMPOUND.TYPE Field is used to specify the number of compounding
periods per year. Optional values for the field are DAILY, WEEKn, Mnn or
Nnn. If left blank, no compounding will occur.

T24 Accounts - T3TAC - R11.1 41

 Annual Payment Rate (APR) is the equivalent interest rate considering all the
added costs. This is known as TEG in France. It is arrived at based on
interest rate, total added cost, and terms. For an advance, the APR is the
interest rate plus charges plus any other incidentals payable to the Bank. APR
would be equal to interest rate if there is no additional cost s. If this is required
to be indicated in the underlying accounts, APR.REQUIRED Field should be
set to yes. If APR is not required, this field is set as NO.
MAX.LEGAL.RATE Field is used to indicate the maximum legal rate
applicable to the group. It acts like a cap.
MAX.DEBIT.CHG.RATE Field identifies the maximum allowed charge as a
percentage of the first debit interest amount. For example, if it is set as 40%.,
then the total charges should not exceed 40% of the interest to be collected.
The values that need to be defaulted into these three fields can be stored in
GROUP.CONDITION table. GROUP.CONDITION is used to define Group
Level conditions for calculation and application of interest, charges and APR .
Id of GROUP.CONDITION table chosen should match with the Group Id
indicated in GROUP.DEBIT.INT table.

T24 Accounts - T3TAC - R11.1 42

T24 Accounts - T3TAC - R11.1 43
T24 Accounts - T3TAC - R11.1 44
 GROUP.CREDIT.INT table allows rules for calculation of credit interest for
groups of accounts. It is quite similar to GROUP.DEBIT.INT with a few
additional capabilities. The Id will comprise Group Id, Currency and effective
date.
TAX.KEY Field identifies either a Tax record (defined in TAX table) or
TAX.TYPE.CONDITION record with a "*" symbol prefixed, which specifies
the calculation and processing of tax, applicable to credit interest. Input of
TAX.TYPE.CONDITION helps in deducting different rates of tax for
different group of customers within the associated group of accounts.
INTEREST.TAX.MIN Field defines the amount of interest which can be
earned tax free. If the amount of credit interest earned in a capitalisation period
is greater than this amount then tax, if defined, will be deducted. The
minimum interest taken for tax calculation will be for CR interest and CR2
interest individually and not for the sum of the two.
It is possible to net debit interest against credit interest prior to calculating tax ,
if both are capitalised on the same dates. DR interest can be netted against CR
interest and DR2 interest can be netted against CR2 interest.

T24 Accounts - T3TAC - R11.1 45

 Similar to the features in GROUP.DEBIT.INT, it is possible to set rules for first and
second credit interest as fixed and/ or floating interest rate. The rates could be on a
level or band basis. Similarly, it is possible to waive or pay a minimum amount of
interest. CR.MAX.RATE Field is used to define the capped rate for credit balance
type. If the rate that is derived after applying any spread, is more than this rate then
interest rate will be capped at this value. Credit Interest can be calculated on daily,
average or minimum balance during the interest period by defining in
CR.BALANCE.TYPE Field. If “MINIMUM” is opted , the minimum balance
during a period within a month is used for interest calculations. It is possible to set
negative interest rates on accounts in credit. To achieve this , NEGATIVE.RATES
Field on GROUP.CREDIT.INT must be set to YES. If this field is set as either “No” or
left unpopulated, then when interest rates fall below 0, zero interest will be accrued to
that account. If set to YES, this would enable collecting interest from accounts even
though they have credit balances.
Negative interest rates may occur by CR.BASIC.RATE being specified with a
discount , such that the net effective rate is negative. This is useful for penalising
overdraft accounts maintaining credit balance. If set to BLOCK.MARGIN, negative
effect will not be allowed because of margin. Negative margin can not make the rate
more negative or a positive rate to negative. For Example, If base rate is -7, margin
is -2 then net effect will be -7.If margin is +2 then the effective rate become -5. If base
rate is +5 and margin is -7 then effective rate will be zero not negative.

T24 Accounts - T3TAC - R11.1 46

 Minimum balance in account for interest calculation can be specified in
CR.MINIMUM.BAL along with start and end dates maintaining such
minimum balance is specified in CR.MIN.BAL.ST.DTE and
CR.MIN.BAL.ED.DTE respectively. If accounts are opened or closed between
these dates, then processing is as defined below.
When CR.ACCR.OPEN.AC is set as Yes, then credit interest is calculated on
minimum balance between the opening date and end date provided balance
type is minimum. When set as NO, then no interest is applied to the account
for the month of opening.
Similarly CR.ACCR.CLOSE.AC is used for account closed during the period.
When set as Yes, then end date for minimum balance calculations is taken as
the closure date of the account to enable it to receive interest for the month.
CR.ZERO.INT.BAL Field indicates that credit interest will not be paid for the
entire capitalisation period if the balance in the account falls below the value
indicated here. If a minimum balance is indicated in this field, input into
CR.ZERO.INT.OC Field will determine whether any accounts opened or
closed during the capitalisation period will have interest paid. NO or Null
input will result in no interest being paid. YES input will result in interest
being paid dependent upon the value in CR.ZERO.INT.BAL.

T24 Accounts - T3TAC - R11.1 47

 It is possible to specify that credit interest is to be calculated only for offset
against debit interest and not for crediting the Customer's Account by using
CR.OFFSET.ONLY Field. If the field is set as Y, then first credit interest will
be offset for first debit interest only.
Input to this field has no effect unless the debit and credit capitalisation dates
are the same.
When CR2.OFFSET.ONLY is set to Y, then only the second Credit Interest
specified in the CR2 Fields may be used to offset the second Debit Interest
specified in DR2 Fields .

T24 Accounts - T3TAC - R11.1 48

T24 Accounts - T3TAC - R11.1 49
T24 Accounts - T3TAC - R11.1 50
 General charges related to accounts are of two types namely interest related
charges and account maintenance or ledger fees related charges.
Interest related charges include DEBIT.INT.ADDON,
GOVERNMENT.MARGIN, HIGHEST.DEBIT and INTEREST.STATEMENT
charge. Either DEBIT.INT.ADDON or HIGHEST.DEBIT may be charged but
not both. All these charges are levied each time debit one interest is applied.
Charge rates applicable are those ruling on the date of debit interest
capitalisation.
Ledger fee charges may be applied monthly, quarterly or half yearly as
specified in the CHARGE.CALCULATION Field in Company record, always
at the end of a calendar month.
The charges are BALANCE.REQUIREMENT, NUMBER.OF.CREDIT
TURNOVER.CREDIT, NUMBER OF DEBITS, TURNOVER.DEBIT and
TRANSACTION.CHARGE which are not immediate ones depending on the
Transaction Codes. Either the NUMBER OF CREDIT or
TURNOVER.CREDIT, NUMBER.OF.DEBIT or TURNOVER.DEBIT can be
charged, but not both.
Charges effective on the date of capitalisation are applicable for the whole of
capitalisation period.

T24 Accounts - T3TAC - R11.1 51

 It is possible to specify a supplementary flat percentage charge on debit
interest amount through DEBIT.INT.ADDON table .
HIGHEST.DEBIT table allows specification of a Percentage charge, based
upon the Highest Debit balance recorded on an Account during the application
period for Debit Interest .
Both are applied to Debit 1 interest amount calculated by the System on
Capitalisation date. The applicable DEBIT.INT.ADDON rate is that ruling on
the date of Debit 1 interest application.
DEBIT.INT.ADDON represents the same type of charge as 'HIGHEST.DEBIT'
and for this reason both cannot be specified for application to any one
particular account or group.
Highest Debit record in effect on the date of the debit interest capitalisation is
applicable to the whole capitalisation period. HIGHEST.DEBIT could also be
collected as ledger maintenance charges using HIGHEST.DEBIT.CHG in
GENERAL.CHARGE table. However free, minimum and maximum amounts
of charge can be specified. First the free amount is deducted from the
calculated charge and then adjusted for specified minimum/maximum charge
amount. Separate interest related charges can be defined for specific
currencies, including local currency. The default charge defined in local
currency if defined will be applied to cover all accounts in currencies not

T24 Accounts - T3TAC - R11.1 52

 specifically mentioned for that currency.

T24 Accounts - T3TAC - R11.1 52

T24 Accounts - T3TAC - R11.1 53
T24 Accounts - T3TAC - R11.1 54
T24 Accounts - T3TAC - R11.1 55
 GOVERNMENT.MARGIN is a table used to define supplementary flat
percentage charge calculated on overdraft balances by the system on
capitalisation date and collected on behalf of the Government. The same
percentage charge is applicable for all currencies. It is possible to specify
Minimum and Maximum Amounts for specific currencies as well as default
minimum and maximum local currency equivalent amounts which apply to all
other currencies. If there are no overdraft balances during the Capitalisation
period, no Government Margin charge is made. The Government Margin rate
ruling on the date of the debit interest capitalisation is applicable for the whole
Capitalisation period.
The purpose of INTEREST.STATEMENT table is to specify a flat fee which is
levied at the time of production of a Debit Interest Statement. Specific charges
can be entered by currency. For all currencies not specifically mentioned, a
default charge can be entered in local currency equivalent.
It is possible to have up to 99 records for all the charges discussed. Id
comprises numeric suffixed with month and year. These records are attached to
GENERAL.CHARGE and linked to GROUP.DEBIT.INT. For each of these
charges, profit and loss category and transaction codes are required to be
defined.

T24 Accounts - T3TAC - R11.1 56

T24 Accounts - T3TAC - R11.1 57
T24 Accounts - T3TAC - R11.1 58
 NUMBER.OF.CREDIT table may be used to specify a fixed charge per entry
that passes over an account during the capitalisation period. Alternately,
TURNOVER.CREDIT table can be used to specify a Percentage charge on the
total value of chargeable credit entries which pass over an Account during the
Capitalisation period.
Only one of these two types of charges can be specified for each Account
Entries are chargeable only for those records in TRANSACTION table which
are defined Y in TURNOVER.CHARGE Field.
Only one of these two types of charges can be specified for each Account.
Charge amount , free amount ,minimum and maximum amounts can be
specified for each currency. Default amounts in local currency equivalent may
also be defined and is used for accounts in currencies for which no amounts
are specified separately.

T24 Accounts - T3TAC - R11.1 59

T24 Accounts - T3TAC - R11.1 60
T24 Accounts - T3TAC - R11.1 61
T24 Accounts - T3TAC - R11.1 62
 Similar to credit transactions charges may be set for debit transactions.
NUMBER.OF.DEBIT table may be used to specify a fixed charge per entry for
debit transactions which pass over an Account during Capitalisation period.
Alternatively, TURNOVER.DEBIT table is used to specify a percentage
charge on the total value of chargeable debit entries which pass over an
Account during the Capitalisation period.
Entries are chargeable only for those records in TRANSACTION table which
are defined Y in TURNOVER.CHARGE Field.
Only one of these two types of charges can be specified for each Account.
Charge amount , free amount ,minimum and maximum amounts can be
specified for each currency. Default amounts in local currency equivalent may
also be defined and is used for accounts in currencies for which no amounts
are specified separately.

T24 Accounts - T3TAC - R11.1 63

T24 Accounts - T3TAC - R11.1 64
T24 Accounts - T3TAC - R11.1 65
T24 Accounts - T3TAC - R11.1 66
 Purpose of BALANCE.REQUIREMENT table is to define a fixed charge to
be applied if a specified Balance is not maintained in an account. The required
balance may be defined as the minimum or average Balance over the
capitalisation period. Charges for different Balances amount may be specified
and can also be defined currency wise.
ACCT.STATEMENT. CHARGE indicates charges for supplying full
statement, copy of statement and/or for every sheet of the statement. The
number of free statement pages that may be allowed, minimum and maximum
amounts can also be indicated. These details can be set up for default and
currency wise.
For all the account maintenance charges discussed rates on capitalisation date
is valid for the entire period.
It is possible to have up to 99 records for all the charges discussed. Id
comprises of numeric suffixed with month and year. These records are
attached to GENERAL.CHARGE and linked to GROUP.DEBIT.INT. For each
of these charges, profit and loss category and transaction codes are required to
be defined.

T24 Accounts - T3TAC - R11.1 67

T24 Accounts - T3TAC - R11.1 68
T24 Accounts - T3TAC - R11.1 69
 TRANSACTION.CHARGE table allows a charge, determined by the
Transaction Code, to be specified for each entry that passes over an Account
during the capitalisation period. For example charges for cash withdrawal can
be set up. The Id comprises of a sequence number, an effective date and an
optional general charge code.
If the general charge code is used the transaction charge will be linked
specifically to the accounts linked to the general charge record, otherwise it
becomes generic to all general charges.
Transaction Charge record which comes to effect on the effective date is
applicable for the whole of the capitalisation period. The Charge Amount can
be expressed either on a unit basis, which represents the cost per entry, or as a
Percentage of the total value of the entries or a FT.COMMISSION.TYPE.
If a valid FT.COMMISSION.TYPE record is attached then the transaction
charge is taken based on the conditions specified in the
FT.COMMISSION.TYPE. Category, debit-credit transaction codes defined in
the TRANSACTION CHARGE is taken for processing.
Default free amount in TRANSACTION.CHARGE is also used as a parameter
for calculating charges. If FT.COMMISSION.TYPE record is attached then
Percentage, Default charge amount, Default minimum amount & Default
maximum amount fields cannot be entered. Otherwise these can be defined

T24 Accounts - T3TAC - R11.1 70

 with or without details currency wise.

T24 Accounts - T3TAC - R11.1 70

 TRANSACTION.CHARGE is not attached through GENERAL.CHARGE, it
is attached through TRANSACTION record in CHARGE.KEY Field.
IMMEDIATE.CHARGE Field in TRANSACTION record is set to NO to
enable collecting these charges along with other Account maintenance general
charges , as they cannot be applied immediately.
System maintains an internal file ACCR.ACCT.TRAN.CH with details of
currently accrued transactions based charges for each account. These details
are used at the time of capitalising the charges . Daily transaction charges are
calculated online.
These charges could be selectively collected or waived for a group of accounts
or an individual account through option in GENERAL.CHARGE.

T24 Accounts - T3TAC - R11.1 71

T24 Accounts - T3TAC - R11.1 72
T24 Accounts - T3TAC - R11.1 73
 The charges applied to an account will vary from different categories of
account. Charges are of two types interest related and ledger fee related .
Interest related charges include DEBIT.INT.ADDON or HIGHEST.DEBIT,
GOVERNMENT.MARGIN and INTEREST.STATEMENT Charge.
The ledger fee related charges can be based on BALANCE.REQUIREMENT,
NUMBER.OF.CREDIT or TURNOVER.CREDIT, NUMBER.OF.DEBIT or
TURNOVER.DEBIT, ACCT.STATEMENT.CHARGE and non immediate
TRANSACTION.CHARGE depending on the Transaction Codes.
TRANSACTION.CHARGE is not attached through GENERAL.CHARGE . It
is attached through TRANSACTION record in CHARGE.KEY Field.
All charges are linked through GENERAL.CHARGE . Several such charge
tariff structures may be stored in the file GENERAL.CHARGE. Charges
effective on the date of capitalisation are applicable for the whole of
capitalisation period.
A particular GENERAL.CHARGE record could be linked to a
GROUP.DEBIT.INT record or to a single account through
ACCOUNT.DEBIT.INT. This brings out the whole picture of charge structure
for accounts.

T24 Accounts - T3TAC - R11.1 74

 The GENERAL.CHARGE record applicable to a particular Account is
specified in the relevant GROUP.DEBIT.INTEREST OR ACCOUNT.DEBIT.
INTEREST Record. Id can be up to four digit number and effective date of
charges.
Applicable interest related and account maintenance charges are linked
though fields in GENERAL.CHARGE similar to the names of the different
charges tables.
Additionally HIGHEST.DEBIT could be collected like account maintenance
charges using HIGHEST.DEBIT.CHG Field.
Interest related charges other than GOVERNMENT.MARGIN can be waived
if required , if they maintain a stipulated minimum or average balance.
Depending on value in INT.CHRG.BAL.TYPE Field the minimum or average
balance for the interest Capitalisation period is used for application of charges.
If there is an entry in INT.CHARGE.CCY Field for the Currency of the
Account, then balance as per INT.CHRG.BAL.TYPE is compared with the
balance in the corresponding INT.CHARGE.BAL. Otherwise, the balance is
converted to local currency and compared with the Default Balance in
INT.CHARGE.DEF.BAL Field.

T24 Accounts - T3TAC - R11.1 75

 In case of Foreign currency accounts, Account maintenance charges other than
TRANSACTION. CHARGE can be collected or waived by using the option of
Yes or No in CHARGE.OF.FCY.ACCT Field.
CALCUL.STEP.PERIOD Field specifies whether charges in
BALANCE.REQUIREMENT, NUMBER.OF.CREDIT, NUMBER.OF.DEBIT,
TURNOVER.CREDIT, TURNOVER.DEBIT, HIGHEST.DEBIT.CHG and
ACCT.STATEMENT.CHARGE should be calculated once to cover the full
charge period, as specified in the Company record, or in monthly steps.
If ‘ monthly' is specified, free, minimum and maximum amounts apply to
charges calculated for each month. Otherwise Free, Minimum and Maximum
amounts are only applied to total charges for the period.
COMB.DEBIT.CREDIT Field specifies whether charges for debit and credit
entries specified in NUMBER.OF.CREDIT or TURNOVER.CREDIT and
NUMBER.OF.DEBIT or TURNOVER.DEBIT should be calculated separately
or combined. If 'NO' is specified, debit and credit charges are calculated
separately. Otherwise a combined charge is calculated using charge details
specified in NUMBER.OF.CREDIT or TURNOVER.CREDIT.

T24 Accounts - T3TAC - R11.1 76

 It is possible to selectively apply the charges set through
TRANSACTION.CHARGE set and linked through TRANSACTION table.
TRANS.CODE.CHARGE Field specifies whether charges per entry should be
calculated using the charge records applicable to each Transaction code. The
field can be used optionally to waive charges on transactions.
If it is proposed to collect charges on transactions, it is possible to combine
charges of respective transactions into one and apply rules. The record Id of
TRANSACTION.CHARGE to be combined is specified .
Then the charges are accumulated into one charge amount and free, minimum
and maximum amounts in the TRANSACTION.CHARGE record specified in
COMB.TRNS.CHRG.CDE Field. Otherwise the charges for each Transaction
code is processed separately using Free, Minimum and Maximum amounts in
the individual Transaction Charge records.
.

T24 Accounts - T3TAC - R11.1 77

 WAIVE.CHARGE.NEG.BAL Field specifies whether all charges specified in
BALANCE.REQUIREMENT, NUMBER.OF.CREDIT, NUMBER.OF.DEBIT,
TURNOVER.CREDIT, TURNOVER.DEBIT and STATEMENT.CHARGE
Fields should be waived if the Account has a negative Balance at any time
during the calculation period.
If this field contains Y, all charges specified in the fields listed above are
waived if the Balance is negative at any time during the calculation period
even if it is only negative for one day.
If CALCUL. STEP.PERIOD specifies that charges are calculated in monthly
steps (M), the Balances are checked for each month separately and charges
waived for that month in which the Balance is negative.
If CALCUL.STEP. PERIOD specifies that charges are calculated in one step
for the whole period (P) as specified in the Company record, all charges are
waived if the Balance is negative at any time during the whole period.

T24 Accounts - T3TAC - R11.1 78

 It is possible to combine all charges except TRANSACTION.CHARGE and
apply as single debit. Depending on CHARGE CODE LEVEL, individual or
combined charge amounts are calculated. CHARGE.CODE.LEVEL Field is
set to COM for combining charges and IND for individual transactions of
charges.
LOW.AMT.CHARGE Field specifies the smallest amount of charges specified
in BAL.REQUIREMENT, NUMBER.OF.CREDIT, NUMBER.OF.DEBIT,
TURNOVER.CREDIT, TURNOVER.DEBIT and STATEMENT.CHARGE,
which will be booked, for Accounts in the Currency specified in the
corresponding OFFSET.CURRENCY. If calculated charges are less than this
amount, they will be waived.
In the absence of a defined currency, individual or combined charge amounts
are converted to local currency equivalent. If the result is less than the amount
specified in DEF.LOW.AMT.CHARGE, the charge is waived.
Currency wise charges below stipulated amounts or individual charges can be
waived.

T24 Accounts - T3TAC - R11.1 79

 When Account maintenance charges are combined, it is possible to set rules
for waiving or offsetting. This is achieved depending on the value in the
OFFSET.BAL.TYPE Field. The options available are MINIMUM and
AVERAGE. If accounts maintain the balance indicated charges can be
waived.The Average or Minimum balance for the application period is
calculated and converted to local currency equivalent. If the result is not less
than the DEFAULT.MIN.AV.BAL all charges specified in
BALANCE.REQUIREMENT, NUMBER.OF.CREDIT, NUMBER.OF.DEBIT,
TURNOVER.CREDIT, TURNOVER.DEBIT and STATEMENT.CHARGE are
waived.rea
It is also possible to calculate a notional credit interest amount and can be
offset against the calculated charges. DEF.BAL.NO.OFFSET Field specifies
the balance (in local currency equivalent) required before offset interest is
calculated for Accounts in Currencies with no such details.
Details for waiving charges and calculating offsets for Accounts, in specific
Currencies may be specified in the multi value group of associated
OFFSET.CURRENCY, MIN.AV.BAL, DAY.BASIS, BAL.NO.OFFSET and
LOW.AMT.CHARGE Fields.
PERCT.FOR.OFFSET Field is used to indicate the rate. DEFAULT.
DAY.BASIS or DAY.BASIS are used to indicate the interest day basis to be
used in the calculation.

T24 Accounts - T3TAC - R11.1 80

T24 Accounts - T3TAC - R11.1 80
T24 Accounts - T3TAC - R11.1 81
T24 Accounts - T3TAC - R11.1 82
T24 Accounts - T3TAC - R11.1 83
T24 Accounts - T3TAC - R11.1 84
 We have so far seen parameter tables for setting up rules regarding calculation
and capitalisation of interest and charges. CONDITION.PRIORITY permits
us to decide the order of priority to choose criteria for creating groups for
differential treatment.
Based on the priority criteria chosen in CONDITION.PRIORITY, different
actual groups are created in ACCT.GEN.CONDITION with inclusion of one
default group.
Then debit interest rates are indicated through GROUP.DEBIT.INT for groups
of accounts and ACCOUNT.DEBIT.INT for specific accounts. In the similar
manner credit interest rate is specified through GROUP.CREDIT.INT and
ACCOUNT.CREDIT.INT. The capitalisation rules are set up through
GROUP.CAPITALISATION for groups and ACCT.CAPITALISTION for
accounts for both debit and credit interest.
Various type of interest related and ledger fee related charges are set up and
linked to GENERAL.CHARGE. These charges are attached to GROUP.
DEBIT. INTEREST or ACCOUNT.DEBIT.INTEREST for collection from the
underlying accounts.

T24 Accounts - T3TAC - R11.1 85

T24 Accounts - T3TAC - R11.1 86
T24 Accounts - T3TAC - R11.1 87
 Purpose of the ACCOUNT ACCRUAL table is to provide the system with
information at Company level about how and when to process accruals of
interest on Customer Accounts . Rules can be set for interest capitalisation
inclusive or exclusive of the balance on capitalisation date, the value dates of
interest entries generated and the day on which the entries are booked being
the following day.
MTH.END.UPTO.DAY Field specifies the day when the interest accrual is
processed. If LAST.DAY.INCLUSIVE Field contains Y, the amount booked to
the Customer's Account will include interest calculated on balances with value
up to and including 31st. The entry booked to the Account will have a value
date of 31st. If this field contains NO, the amount booked to the Customer's
Account will only include interest calculated on balances with value up to and
including the last calendar day before 31st. The entry booked to the Account
will have a value date of 31st.
Currently, MTH.END.UPTO.DAY Field can only be set as 31. When interest
capitalisation for an Account is also set as 31, month end accrual processing
and application will both take place on the last working day of every month.

T24 Accounts - T3TAC - R11.1 88

 It is possible to control the statement entries appearing in the customer
statement. APP.POSTING.DAY Field specifies whether interest is to appear on
a customer statement on the date it is calculated or on the following day.
If NEXT is specified, details for producing the interest entries are written in a
temporary file. The entries are booked at part of start of day processing on the
next working day, by the program INT.POST.NEXT.
The Profit and Loss entries are booked on Capitalisation day, regardless of the
contents of this field.
It is possible to specify whether account maintenance charges are to be
accrued every month end or only booked to Profit and Loss when they are
applied. This is achieved through INCLUDE.CHARGES Field.
Account maintenance charges may be applied monthly, quarterly or six
monthly as specified in the Company table, but always at the end of a calendar
month.

T24 Accounts - T3TAC - R11.1 89

 The accrual frequency can be DAILY, MONTHLY or it could be specified that
no accrual is to be made. NONE option is used for no accruals. The frequency
can be set up differently for a select group for any select category also. It could
be different for foreign currency accounts and local currency accounts or on a
common frequency for both.
GRP.ACCR.TYP contains LOCAL, FOREIGN or BOTH based on choice to
indicate accrual types for local currency, foreign currencies and all currencies
respectively. Frequency for each type is specified in GRP.ACCR.FQU Field.
ACCRUAL.GRP Field is defined with appropriate group defined in
ACCT.GEN.CONDITION for which the above rules are to be applied.
In the similar manner for specific categories the corresponding fields
ACCRUAL.CAT, CATEG.TYPE and CAT.ACCR.FQU are used to specify
the accrual frequency for suitable categories.
If there are no group or categories specified then DEFLT.ACCT.TYPE Field is
used to indicate LOCAL, FOREIGN or BOTH.
DEFLT.ACCT.FQU Field is used to indicate the frequency. If NONE option is
used then accrual and capitalisation dates are same.

T24 Accounts - T3TAC - R11.1 90

 VAL.DATE.ADJUST Field helps increase value dates of all entries by the
specified number of days. This is useful for Russian method of calculating
interest on Accounts, where interest is not calculated on the closing balance of
a day, but on the starting balance of next day.
It is possible to set values up to 99 days in this field.
When account balances migrate from legacy system to T24, accrual already
done in the legacy system can now be included as an adjustment for
calculation purposes. For that a separate PL category will be used to book
adjustment accruals.
For Example an account has Credit balance say USD 5000 with accruals
USD500 when migrating from the legacy system to T24, this accrual of
USD500 will be debited to a PL category to adjust credit for calculation of
accruals on any date after migration date. While accruals from migration date
will be done by debit to PL category 50000, adjustment will be done from a
new PL category and total accrual will be shown as asset type in CRF balance
file.

T24 Accounts - T3TAC - R11.1 91

T24 Accounts - T3TAC - R11.1 92
T24 Accounts - T3TAC - R11.1 93
 Select parameters for operating accounts are set up through this table. It is
possible to set parameters group wise and currency wise.
Notice Savings accounts can be defined to insist on a notice period for
withdrawals above an indicated amount. These are possible for accounts
defined as SAVINGS in ACCOUNT.CLASS.
NOTICE.AMOUNT Field specifies the maximum amount which can be
withdrawn without notification being required. Maximum local currency
amount that can be withdrawn in a single transaction without incurring an
override message. Override message is generated when this value is exceeded.
NOTICE.PERIOD Field can be specified either in days or months or working
days to indicate the notice to be given for withdrawing above the notice
amount.
The number of days, months or working days for which funds subject to
notice conditions will be available could be indicated through AVAILABILITY
Field For example: Notice of one month is required for withdrawal and
availability of funds kept for 5 more days, then NOTICE.PERIOD is
mentioned as 1 month and AVAILABILITY as 5 working days. If the amount
is not withdrawn within in this period, fresh further one month notice must be
given.
Notice of withdrawal recorded through NOTICE.WITHDRAWAL

T24 Accounts - T3TAC - R11.1 94

 application.

T24 Accounts - T3TAC - R11.1 94

 Operational restrictions on maximum increase , allowing debits, minimum and
maximum balances can also be stipulated.
MAXIMUM.INCREASE Field defines the maximum annual balance increase
allowed for this category of account. Calculation of this increase is based on
the start of year opening balance through START.YEAR.BAL Field in the
account record and the current online cleared balance through
ONLINE.CLEARED.BAL Field.
For example, if an account balance can only be increased by 10,000.00 per
annum. The opening balance at start of current year is 50,000.00. Override is
raised when balance becomes greater than 60000.00. If today’s balance of
43,000.00 then 17,000.00 can be drawn to reach the limit.
DEBIT.RESTRICT Field can be used to restrict the accounts that belong to
this group and currency from making debit transactions if set to 'Y'. Text of
override message as defined in RESTRICTED.MSG is displayed accordingly.
It is possible to calculate premium interest rates , when multi valuable
PREMIUM.TYPE Field is defined with valid records from
SAVINGS.PREMIUM. SAVINGS.PREMIUM file is used to specify the
premium related parameters for accounts.
Minimum and Maximum balances an account is supposed to maintain are
indicated in MINIMUM.BAL and MAXIMUM.BAL Fields. Wherever

T24 Accounts - T3TAC - R11.1 95

 withdrawals and deposits breach the rules , it will attract override.

T24 Accounts - T3TAC - R11.1 95

 It is possible to defer collecting charges, interest and tax thereon for a specific
period after calculation, so that customer could be notified of ensuing debits.
The system debits this amount to internal account and after the deferred
period, the amount is debited to customer’s account automatically.
DEFER.CHARGE.DAYS and DEFER.DB.INT.DAYS Fields are used to
specify the deferment period. The period can be indicated either in calendar or
working days. The internal account category for posting such debit is indicated
for deferred interest, charges and tax through
CHARGE.PENDING.CATEGORY, DB.INT.PENDING.CAT and
TAX.PENDING.CAT Fields. Internal accounts to be opened in local currency.
It is possible to restrict use of one limit for only one account , instead of many
accounts using the same limit. This is indicated through
SINGLE.LIMIT.DEFLT Field . The value set here will be defaulted to
SINGLE. LIMITFIELD in ACCOUNT, for the new account opened satisfying
the group condition. If SINGLE.LIMIT.FIELD in account is defaulted to "Y"
then only one account is allowed to utilize the limit. If set to "N" then multiple
accounts can utilize the same limit.
When ever there are changes in interest rate, the rate change advices could be
sent to the customer by setting RATE.CHANGE.ADVICE Field as Yes .
Message type for such advice is entered in ADVICE.TYPE Field, with a valid
record in EB.ADVICES table.

T24 Accounts - T3TAC - R11.1 96

 It is possible to indicate transactions, which if done more than the threshold
times in a statement period, would constitute a violation. The violation could
be set up as not eligible for credit interest.
For example: Cash withdrawal transaction happening 10 or more times, within
a statement period of 1 month, then account not eligible for credit interest.
Further, it should also be considered as a violation.
TXN.THRESHOLD Field is used to define the threshold for each transaction
code or group in the TXN.CODE.GRP Field. If the number of qualifying
transactions equals or exceeds this threshold then the account will be deemed
to have broken the conditions for the waiving of credit interest and/or violation
status as specified in the related WAIVE.CR.INT and NO.VIOLATION Fields.
This threshold applies to each statement period.
NO.VIOLATION Field allows the related transaction threshold set, not to be
used for calculating account violations. When set as Yes, then the transactions
in this group will be recorded on the AC.VIOLATION record for the account
with the TXN.STATUS set to null and therefore will not influence the
VIOLATION.STATUS of the account. RETENTION.PERIOD Field decides
how long this record should be in live status.

T24 Accounts - T3TAC - R11.1 97

 The application INFO.ACCT.DR may be used to calculate Debit Interest and
interest related charges on-line up to a given date for a specific Account.
Function 'V' is used to request the calculation, function 'S' allows the results of
calculations to be viewed. No bookkeeping entries are generated by this
application. All details contained in this file are for information only.
DB.INT.CALC.RND Field is used to indicate the type of rounding to apply to
individual debit interest calculations which is the amount stored in the
DR.INT.AMT Field of either INFO.ACCT.DR, ACCR.ACCT.DR or
STMT.ACCT.DR. CR.INT.CALC.RND Field specifies the type of rounding to
apply to individual credit interest calculations, i.e. the amount stored in the
CR.INT.AMT Field of either INFO.ACCT.CR, ACCR.ACCT.CR or
STMT.ACCT.CR.
DB.INT.TOT.RND indicates the type of rounding to apply to the total amount
of debit interest, i.e. the amount stored in the TOTAL.INTEREST Field of
either INFO.ACCT.DR, ACCR.ACCT.DR or STMT.ACCT.DR and
CR.INT.TOT.RND indicates the type of rounding to apply to the total amount
of credit interest, i.e. the amount stored in the TOTAL.INTEREST Field of
either INFO.ACCT.CR, ACCR.ACCT.CR or STMT.ACCT.CR.
Value entered should be a valid record in EB.ROUNDING.RULE table. This
will determine the type of rounding to be applied to the calculated interest
amount. Natural rounding relevant to interest currency is default.

T24 Accounts - T3TAC - R11.1 98

T24 Accounts - T3TAC - R11.1 99
T24 Accounts - T3TAC - R11.1 100
T24 Accounts - T3TAC - R11.1 101
 CONDITION.PRIORITY with Id as STATEMENT specifies, for statement
generation, which data elements in CUSTOMER and ACCOUNT record are
used to determine preference condition groups. When a new account is
opened, an ACCOUNT .STATEMENT record, defaulted with the date and
frequency for printing account statements is generated automatically by the
system. The default frequency is determined by STMT.GEN.CONDITION
table.
The Id for STMT.GEN.CONDITION is pre-determined here and indicates the
frequency of statement generation - Daily, Monthly, Quarterly, Six monthly
and Yearly.
Default conditions for issuing Statement are defined in
AC.STMT.PARAMETER. When an account is opened, they are defaulted to
ACCOUNT.STATEMENT. Separate group for generation of statements can be
created, similar to interest and charges application. It is still possible to change
the frequency at account level using ACCOUNT.STATEMENT which will
override the conditions set at group level.
Accounts whose details match the conditions specified for
STMT.GEN.CONDITION in record 'DAILY' will have a default statement
frequency of 'BSNSS' i.e. every working day.

T24 Accounts - T3TAC - R11.1 102

 The purpose of this table is to define defaults for account statement details
when opening new accounts .When a new account is opened, an
ACCOUNT.STATEMENT record, defaulted with the date and frequency for
printing account statements is generated automatically by the system. The
default frequency is determined by the STMT.GEN.CONDITION table.
AC.STMT.PARAMETER table is used to set the default rules for production
of statements when there has been no movement in accounts, descriptive
statements, interest and charges statements and advices and tax advices and the
minimum number of months for a statement.
IF.NO.MOVEMENT Field is used to choose whether to produce statements
even when there has been no movement in account since last statement. The
value for IF.NO.MOVEMENT is defaulted into ACCOUNT.STATEMENT
record for a newly opened account.
FIRST.STMT Field is used to choose whether the first statement is to be
produced even when there has been no movement in account since account
opening. Some of the application in T24 have a facility to enter one or more
lines of Customer Narrative, each 34 characters long. If the
DESCRIPT.STATEMENT Field contains 'Y', the Customer Narrative may be
printed on Account Statements, in addition to the standard transaction
narrative as defined in the TRANSACTION table and DE.TRANSLATION
table.

T24 Accounts - T3TAC - R11.1 103

 INT.CLOSING.ADVICE Field specifies whether or not an advice should be
produced when interest and charges are applied . The details of format of
advice, address and copies are specified in the delivery system. This value for
INT.CLOSING.ADVICE will default into ACCOUNT.STATEMENT record
for a newly opened account.
INTEREST.SCALE Field specifies whether or not a detailed interest
statement (scale) should be produced whenever interest is applied.
It is also possible to set a minimum frequency for statement generation in
MIN.MONTHS.STMT Field. It controls the minimum frequency for
statements to be produced in PRINT.ACCOUNT.STMT batch job. If there is
no such minimum frequency it is indicated as NONE. The default of null is 6
months or can be mentioned as any number of months between 1 and 9999.

T24 Accounts - T3TAC - R11.1 104

 In a value dated accounting system if FWD.MVMT.REQD Field is Null or
No, then real forward entries with a Value-Date equal to or less than the next
statement date, booked during the statement period alone, will be reported in
the statements.. If it is desired that all the real forward entries irrespective of
value date booked during the statement period, are to be printed in the next
statement, then this field has to be made YES. Value dated accounting is set up
in ACCOUNT.PARAMETER table through VALUE.DATED.ACCTNG Field
with value YES.
For example: Let us assume last statement date is 15.3.2008 and next
statement date is 31.3.2008. For example if there are two transaction with
booking date as 16.3.2008 and value date as 28.3.2008 and second one with
booking date as 20.3.2008 and value date as 6.4.2008. If the field is set to
NULL/NO then only the entry with value date 28.3.2008 will be reported in
the next statement due on 31.3.2008. If this field is YES then both the entries
will be reported in the next statement due on 31.3.2008.
SP.PB.CONS.MAX Field specifies the number of transactions after which
entries are to be consolidated for Passbook printing . If the number of
transactions during the period after last print in a Passbook Savings account
exceeds the number specified in this field then the entries would be
consolidated and printed as total of Debit and / or Credit entries.
The transaction codes used for such consolidation is indicated in
PB.CONS.DR.TRANS and PB.CONS.CR.TRANS. Fields.

T24 Accounts - T3TAC - R11.1 105

T24 Accounts - T3TAC - R11.1 106
 There are three dates in accounting entries.
Booking date is System date when transaction entry is generated. The date
used is from TODAY Field in DATES table for the Company being processed.
Value date is the date from which entry is to be given effect for interest
purposes. This is not used for entries affecting Internal Accounts. If Value date
is not entered in the originating transaction, or not defaulted from application
level rules or TRANSACTION table, the value date is assumed to be the same
as the Booking date.
Exposure date is the date on which the proceeds of a cheque or other credits
can be drawn against . This date can be different from value date and
transaction date. This date can only be present in Credit entries or Debit
entries which are reversals of Credit entries.
If the Exposure date is not entered in the originating transaction, or not
defaulted from application level rules or TRANSACTION table, it is assumed
to be the same as Booking date. Please note that the exposure date does not
affect interest calculation as the value date is relevant for that.

T24 Accounts - T3TAC - R11.1 107

 T24 Account table stores only the static information of the account. The
financial data is updated in EB.CONTRACT.BALANCES.

Cleared balance includes values of all authorised entries over the Account
except any credit or reversal of debit entries with future exposure dates.

Working balance is value of cleared balances and unauthorised debit entries

over the account. Working balance is useful for checking of limits attached to
an Account.

Actual balance is cleared balance and credit entries with future exposure dates.

Available balance is maintained as a ladder to show date wise cash flow in an

account. This will include Forward dated accounting entries produced by
contract applications and STO. Ladder is maintained for the number of days
indicated in CASH.FLOW.DAYS Field of ACCOUNT.PARAMETER.
Nature of balance to be indicated here is parameterised in
ACCOUNT.PARAMETER table. Nature of balance may be with unauthorised
entries or not. The available balance ladder can be updated based on value

T24 Accounts - T3TAC - R11.1 108

 date or exposure date.
Total of forward movements will be held for each available date. These movements
will be all forward contracts that have not updated the working balance. Identifies the
authorised forward movements to the account with an exposure date specified by
AVAILABLE.DATE.Field.

T24 Accounts - T3TAC - R11.1 108

 Rules relating to Accounts and Accounting are set up through this table. Id of
the record is SYSTEM. The number of days entered in CASH.FLOW.DAYS
Field will determine the window period for which cash flow balances are to
be maintained on each EB.CONTRACT.BALANCES record for an account.
Each forward dated entry generated for an account will impact the cash flow
balances if the value date of the entry falls within this period.
As an example, if the number of days entered is 10, then any forward dated
entry raised online that has the value date less than ten calendar days from
today will update the accounts cash flow balances in ECB. If this update
causes either a limit to be exceeded or an unauthorised overdraft to occur, then
an override message will appear. All entries raised online that fall outside the
window will not update the account balances in ECB immediately and no
override messages will appear, but when their value dates do fall within the
window, the start of day process 'SOD.CASHFLOW.UPDATE' will pull them
in and update the account cash flow balances in ECB. If an exception occurs at
this stage, then the CASH.FLOW.EXCEPTION file is updated to indicate this.
If no value is entered here then only Nostro accounts will have cash flow
maintained, and a default of ten calendar days is used for these.

T24 Accounts - T3TAC - R11.1 109

 Accounting can be either trade dated or value dated .
The option of using trade dated accounting is available only for Data Capture,
Teller, Funds Transfer and Interest and Charges and Securities application.
Select applications can be chosen for value dated accounting or a separate
category can be chosen. It is possible to change from trade dated to value dated
accounting and not from value dated to trade dated system.
Under Trade dated accounting, accounting entries are passed on transaction
date itself. Bank’s books and customer statements are updated on booking date.
However, interest calculation is only from value date.
Under Value dated accounting, accounting entries differ only if value date is
forward date. If value date is in future, Account and PL postings are reflected in
books and statements only on value date. Till then they are treated as contingent
balance and shown in Account accordingly.
It is possible to have different value dates for credits and debits. In such cases,
System places funds in suspense accounts for interim period. Suspense accounts
for different category codes for split value dated accounting is using Category
codes defined in ENTRY.CATEGORY and SUS.CATEGORY Fields.
Transaction codes to be used while moving into and then out of suspense
account is indicated in SUSPENSE.TXN.IN and SUSPENSE.TXN.OUT Fields.
VAL.NO.MONTHS Field defines the number of months that value dated
information is to be retained on the system.

T24 Accounts - T3TAC - R11.1 110

 AVAILABLE.BAL.UPD Field identifies how the available balance of account
in ECB should be updated. This is top level setup which can be overruled at
ACCOUNT or ACCT.GROUP.CONDITION (if ACCOUNT is blank).
The options include BOTH where unauthorised debits and credits to be
included in the available balance , NONE when no unauthorised movements to
be included in the available balance field found in ECB. When DEBITS is
chosen only unauthorised debits to make up available balance and for
CREDITS only unauthorised credits to make up available balance The default
will be none when only authorised movements are to be included in the
available balance.
EXPOSURE.DATE.AF Field is used to indicate the choice for setting up the
available funds ladder .Yes or Null is used to indicate funds ladder to be
updated on the basis of exposure date. No to indicate funds ladder updated on
value date.

T24 Accounts - T3TAC - R11.1 111

 CREDIT.CHECK identifies on which balance, overdraft and limit checking
should be made for all accounts. Default is Working balance field found in
ECB.
If nothing is set at ACCOUNT level then the ACCT.GROUP. CONDITION is
checked and if still nothing is set at this level, then ACCOUNT.PARAMETER
is checked. The available choices are AVAILABLE when credit checking is
made using AVAILABLE.BAL, or WORKING when credit checking is made
using WORKING.BALANCE, or FORWARD when credit checking is made
using WORKING.BALANCE plus today's forward movements, or
AVAILWORK when credit checking is made using AVAILABLE.BAL and
WORKING.BALANCE, or AVAILFWD when credit checking is made using
AVAILABLE.BAL and WORKING.BALANCE plus today's forward
movements, or BLANK when the default checking is using
WORKING.BALANCE.
EB.AF.PARAM gives option to update specific un authorised movements for
available balance. What ever the settings done for Available Balance update
for accounts in ACCOUNT.PARAMETER can be overridden by this
parameterisation.
Available funds will hold unauthorised and authorised transactions separately,
so while WORKING.BALANCE ignores unauthorised credits and future
authorised credits, AVAILABLE.BAL may contain either unauthorised credits

T24 Accounts - T3TAC - R11.1 112

 or unauthorised debits or both of them or even neither of them. Please recollect
balance fields are found in ECB.
All the movements will be held as described unless a restriction has been set in
EB.AF.PARAM at transaction or application level.

T24 Accounts - T3TAC - R11.1 112

 Sometimes there is need to keep balance information for reporting purpose as
contingent. It is possible by opening Contingent Accounts. This facility is
available for both customer and internal accounts. This contingent account
processing is used to calculate interest on a customer Limit unutilised and/or
utilised. T24 monitors the limit record and any charges in the unutilised and or
utilised amount are posted to the contingent accounts by way of entries. For
this processing an internal contingent account is used as the other side of each
entry. Interest can be calculated on the customer contingent account.
CONT.DESC, CONT.CAT.STR and CONT.CAT.END Fields are used to
indicate contingent account and range of category codes.
T24 has facility to change the product code without closing an account. For
example a savings account can be converted as current account without
closing the savings account. However, a Nostro account category can be
replaced only by another Nostro category.
A customer of an account can be replaced only with the joint account holder
and not by any other customer. The joint holder can also be amended
subsequently. The main advantage is, after observing the operations in an
account, it is possible to upgrade / downgrade it to another type of account
with different service conditions. ACCT.CATEG.DESC Field is used to have
a description for the account category range defined in ACCT.CATEG.STR
and ACCT.CATEG.END Fields for customer replacement .

T24 Accounts - T3TAC - R11.1 113

 In T24, there is flexibility to use the customer number as part of the account
number. In order to correctly validate the key, the starting position, and length
of customer number should be defined using CUSTOMER.CODE.POS and the
CUST.CODE.LEN. Field. CUSTOMER.CODE.POS specifies the start
position of the customer code within account number. No input in this field
implies that the customer code is not held within the account number, and is
not required to be checked in the account application.
CUSTOMER.CODE.LEN will be used to define the length of the customer
number within the account number.
It is possible to maintain details of customer wise interest and tax on every
account and contract in the live internal file INT.MOVEMENT. Depending on
the transaction codes defined INT.MOVEMENT.PARAM , this file will hold
Credit, Debit and Tax entries. It is maintained on "Deal/account - Date" where
the date can be either the Booking or the Value date. The Tax returns will be
generated based on the contents of this file. If details of interest movement are
required to be maintained for accounts , INT.MVMT.UPDATE Field in
ACCOUNT.PARAMETER can be flagged as Y.
Profit and loss category codes contains category codes for prior period
adjustments.
Charges are calculated from the second month of opening an account by
default. If it is desired to calculate the charges from the month in which the

T24 Accounts - T3TAC - R11.1 114

 account was opened then CHARGE.FIRST.MONTH Field must be set to YES.
NO.UNAU.KEYS indicates the Threshold Limit for number of Unauth keys that will
be held in EB.CONTRACT.BALANCES. With the service,
XXX/AC.ACCOUNTING.SERVICE running (ie start or auto) , if the number of
unauth keys in ECB of an account has crossed the threshold, the entry keys would
moved from ECB to AC.UNAUTH.ENTRY leaving the balance details only in ECB.

T24 Accounts - T3TAC - R11.1 114

 In T24 , it is possible to refer the account numbers through an alternate
account number also.
ALT.ACCT.PARAMETER table is used to setup conditions like check digit
and size of alternate account numbers. Then the multi-valued ALTERNATE.ID
Field in ACCOUNT application will allow entry of alternative account access
identifiers defined in the ALT.ACCT.PARAMETER If
ALTERNATE.ACC.IDS Field in ACCOUNT.PARAMETER is set to Y, T24
account can also be referenced by alternate number.
This facility is helpful when T24 replaces an existing legacy system. The old
account numbers of legacy system could be continued to be used in the place
of new T24 account numbers.
ACCOUNT application displays the alternative access identifiers from the
applications mentioned in the multi-valued ALT.ACCT.TYPE Field and allows
entry of the alternative account identifiers in the linked ALT.ACCT.ID Field.
Validation is performed in accordance with the definitions from the
ALT.ACCT.PARAMETER application.
ALTERNATE.ACCOUNT file is used to provide a link between T24 account
number and another identifier that the user may have for the account.

T24 Accounts - T3TAC - R11.1 115

 Each application has its own default order for draw down, principal
redemption and interest repayment like CUSTOMER.SSI,
SEC.ACC.MASTER, AGENCY etc. When DEFAULT.ORDER is “null”, then
system defined default takes place while no default takes place for None.
When rules are to be set for select application or transaction, then in
ACCOUNT.PARAMETER, SYS.CODE Field holds the code of the
application or transaction with application. For example MM for Money
Market and SC for Securities. SC-SSL is used for Securities with
corresponding security transaction type. MM-DD is for MM Drawdown
Account Default. A value of 'ALL' is allowed to specify all transaction types.
For the above, NOSTRO.DEFAULT specifies how Settlement Accounts are to
be defaulted when using a Nostro Account. If the value is Null, then Nostro
account is always defaulted or 'AGENCY' implies that only default when
Agency conditions exist or 'NONE' implies no Nostro account to be defaulted.
DEF.OVERRIDE Field when set to Y will raise override when default account
does not match the input value.
USE.FIRST.ACCT Field set as Yes implies that the first account is to be
defaulted when there exists more than one possible default account.
CUSTOMER.SSI Field defined as Y indicates whether the system uses
CUSTOMER.SSI application for defaulting the settlement accounts during

T24 Accounts - T3TAC - R11.1 116

 input of contract in applications such as LD, MM, etc.

T24 Accounts - T3TAC - R11.1 116

T24 Accounts - T3TAC - R11.1 117
 Records in this table are either ACCOUNT or CLASS or PL type.
ACCOUNT type records are required for automatic debit/credit by the system
while operating modules like FX,LC,MM,LD and DC. Internal accounts in
local currency must be opened for them. Category should be in the range of
10000 to 19999.
For example : DIFFERENCE is used in DATA.CAPTURE when system has to
raise an entry to balance a batch as part of the end of day processing.
SUSPLMMCR/SUSPLMMDR is used by the Loans and Money Market
systems when the true account is not yet known for the payment entry.
SUSPFXCR/SUSPFXDR is used by the Foreign exchange system when the
true account is not yet known for the payment entry.
When the record type is CLASS, the category and sector code fields are
treated as multi value associate fields and at least one of them should be
defined. Duplications are not allowed within a record.
For example : NOSTRO is used to identify an account as being classified as a
Nostro account. BANK is used to identify counterparty as Bank, so that
suitable SWIFT message could be sent. SAVINGS type to identify class of
account for which instead of statements , pass books could be issued.
PL type records are required for automatic debit / credit by the system while
operating modules like DX

T24 Accounts - T3TAC - R11.1 118

 REFERAL is a table which is used to establish conditions under which details
of an Account or entries over an Account should be referred to the Account
Officer. An end of day report is produced, containing details of transactions
and balances to be referred.
Conditions could be set up to cover various conditions.
One or more transaction codes or ranges thereof can be set up. Specific
movements like Debit, Credit and Reversal can be indicated in the referral
conditions. Minimum and /or Maximum amount of movement can be used.
The referral could be a combination of transaction code, movement type and
amount. If Movement amounts and Transaction Codes are specified then the
entry must meet both conditions for it to be referred. For example a referral
could be set up for miscellaneous debits reversed for amounts above USD 500.
If only certain transaction types should use this referral, then the transaction
codes that relate to these fund movements could be listed. For example, if this
referral should only be used for external funds transfer using SWIFT, then the
transaction codes for the debit side of all Swift payment types can be listed in
multi valuable TRANS.CODE.
If indicated currency is different from the Currency of the Account, then the
amount of the entries passed will be converted to the Referral Currency before
checking whether they should be referred.

T24 Accounts - T3TAC - R11.1 119

T24 Accounts - T3TAC - R11.1 120
T24 Accounts - T3TAC - R11.1 121
 The purpose of POSTING.RESTRICT table is to define various type of
restrictions which may be imposed on Accounts, For example 'POST NO
DEBITS', 'WHEREABOUTS UNKNOWN', 'PENDING CLOSURE', etc.
Posting Restriction codes may be assigned to Customers and Accounts as
required. Any entries meeting the specified conditions will generate an
override to be duly approved.
Posting Restriction do not affect Banks crediting / debiting interest and
charges to the account. If the Bank decides to do that such debits or credits
can be parked in Suspense Account. This is effected through
AC.APPLICATION.LINK application wherein Suspense Category is defined.
Moreover , the applications for which suspension of interest and charges
should be done should be indicated in OVERRIDE table of Posting Restrict.
The system when it applies interest and charges during COB/online, will park
the amounts in Suspense instead of account where posting restrict is effected.
Id can be up to a 2 digit number. Certain range of codes have been predefined
and should not be used for anything else. Posting Restriction codes in the
range of 90-99, will indicate AUTOMATIC CLOSING types. For example
any accounts which has a balance of Zero should be closed automatically.
Posting Restriction codes in the range 80-89 indicate pending closure types. It
means that accounts which will be closed soon, but not to be closed

T24 Accounts - T3TAC - R11.1 122

 automatically.

T24 Accounts - T3TAC - R11.1 122

 The order in which these files should be created is stored within the automated
tool for system build. For easy reference, the order sequence in is in ascending
build reference order as listed in the left.
The values required for population of the tables will be obtained from business
analysis information .
The mandatory files are shown with an asterisk symbol.
Wherever there are dependencies for filling up values in the tables in build
sequence, are shown on the right.
Next to Customer, Account is central to all other applications in T24. We need
to have Customer type of accounts like Savings and Current accounts. We also
need accounts to reflect balance of our Nostro accounts held with outside
banks. In addition, all contract applications in T24 need accounts either in the
form of Customer accounts or Internal accounts for moving money for giving a
loan or taking a deposit. Even if a Customer does not have an account with the
Bank, we need to have at least a Nostro account or internal accounts like
Suspense account or Cash account to deal with the assets and liabilities.

T24 Accounts - T3TAC - R11.1 123

 This diagram shows the dependencies of accounts application on various other
tables which are categorised as either customer related, interest related,
statement related, processing related and the internal tables.
Based on the CONDITION.PRIORITY and ACCT.GEN.CONDITION,
account groups are formed and then rules are set for debit interest, credit
interest and capitalisation. Interest related and ledger maintenance charges are
also set.
To have a control on transactions related to Accounts, posting restrictions and
referral conditions are set up. Service conditions for accounts are also created.
The tables shown last on the right bottom are the internal tables updated by
T24 for Accounts, about which we will discuss later in this unit.

T24 Accounts - T3TAC - R11.1 124

 Let us understand the structure for the interest and charges grouping and see how
they are linked.

We have already seen parameter tables for setting up rules regarding calculation
and capitalisation of interest and charges. CONDITION.PRIORITY allows us to
decide the order of priority and the priority items (attributes) based on which
rules for creating account groups.
Based on the priority items defined in CONDITION.PRIORITY, different
account groups are created in ACCT.GEN.CONDITION including a default
group which is used when no criteria for grouping is set up.

When an account is opened, based on a specific criteria defined, T24 will

automatically assign a group for the Account.
Based on these grouping conditions, the following are setup for each group:
1. Capitalisation rules
2. Debit interest conditions
3. Credit interest details

These are setup in GROUP.CAPITALISATION, GROUP.DEBIT.INT and

GROUP.CREDIT.INT. While the interest conditions are set up at the currency
level for a group, the capitalisation will be set up at group levels.
If required, account specific rules can also be setup for all or some of the above

T24 Accounts - T3TAC - R11.1 125

 three functionalities. They are defined in ACCT.CAPITALISATION,
ACCOUNT.DEBIT.INT and ACCOUNT.CREDIT.INT tables.

Apart from these, various type of interest related and account maintenance related
charges are set up and linked to GENERAL.CHARGE. The GENERAL.CHARGE
records are further attached to GROUP. DEBIT. INT or ACCOUNT.DEBIT.INT for
collection of charges from the underlying accounts. A mandatory “default” record for
default charges is required in GENERAL.CHARGE.

When we talk about GENERAL.CHARGE, we must understand that charges fall into
2 types, those that are levied at the same time as debit interest is applied (Interest
Related Charges) and those which are considered to be fees for maintenance of an
Account (Ledger Fee Charges).
DEBIT.INT.ADDON, GOVERNMENT.MARGIN, HIGHEST.DEBIT Charge and
INTEREST.STATEMENT are the Interest related charges and the others are the
maintenance related charges.
These are defined in separate tables and the ID is further attached to the
GENERAL.CHARGE table.

T24 Accounts - T3TAC - R11.1 125

 Having discussed about the parameter tables and the interest and charges
related tables, let us also learn about the tables used for account statement
generation.

When a new Account is opened, an Account Statement record, specifying the

date and frequency for printing Account statements, is generated automatically
by the system which may be subsequently amended manually, if required. The
purpose of the STMT.GEN.CONDITION is to define rules for determining the
default statement frequency when opening new Accounts.

T24 Accounts - T3TAC - R11.1 126

 Like forming Account groups for interest and charges, separate grouping can
be done for determining the frequency of generation of statements.
CONDITION.PRIORITY record with ID: STATEMENT specifies, for
statement generation, which data elements in CUSTOMER and ACCOUNT
records will be used to determine condition groups. The default frequency for
an Account is determined by STMT.GEN.CONDITION table.
The ID of STMT.GEN.CONDITION records are pre-determined and indicates
the frequency of statement generation - namely, Daily, Monthly, Quarterly,
Six monthly and Yearly. Daily frequency generates statements on every
working day (every Business day). Further, other default conditions for issuing
Statements are defined in AC.STMT.PARAMETER. When an account is
opened, the frequency and other default conditions are updated in the
ACCOUNT.STATEMENT record automatically created by T24. The
frequency and other conditions can be modified at the
ACCOUNT.STATEMENT level.

T24 Accounts - T3TAC - R11.1 127

 The charges applied to an account will vary depending on its group. Charges
are of two types interest related and account maintenance related.
Interest related charges include DEBIT.INT.ADDON or HIGHEST.DEBIT,
GOVERNMENT.MARGIN and INTEREST.STATEMENT Charge.
The account maintenance charges can be based on
BALANCE.REQUIREMENT, NUMBER.OF.CREDIT or
TURNOVER.CREDIT, NUMBER.OF.DEBIT or TURNOVER.DEBIT,
ACCT.STATEMENT.CHARGE and TRANSACTION.CHARGE depending
on the Transaction Codes. TRANSACTION.CHARGE is not attached through
GENERAL.CHARGE . It is attached through TRANSACTION record in
CHARGE.KEY Field.
All charges are linked through GENERAL.CHARGE. Several such charge
tariff structures combinations may be stored in the table GENERAL.CHARGE
. Charges effective on the date of capitalisation are applicable for the whole of
capitalisation period.
A particular GENERAL.CHARGE record could be linked to a
GROUP.DEBIT.INT record or to a single account through
ACCOUNT.DEBIT.INT. This brings out the whole picture of charge structure
for accounts.

T24 Accounts - T3TAC - R11.1 128

T24 Accounts - T3TAC - R11.1 129
 ACCOUNT application is used to open and maintain all accounts. T24
Account table stores only the static information of the account. The financial
data is held in EB.CONTRACT.BALANCES. . ECB has the fields to display
the updated account balance field, Date moved fields and Exposure
management fields.
All movement of money into the accounts takes place though other
applications depending on nature of business. For example through Funds
transfer or Teller application, moving money to and from an account is
possible.
Accounts in T24 are of 2 types namely Customer accounts and Internal
accounts. Customer accounts belong to customers while internal accounts are
opened to represent our Bank’s monies.
It is possible to accrue interest and charges in the case of customer accounts,
while Internal accounts do not permit this.
Customer may be an individual, corporate or a Bank. Customer accounts can
be current account, savings account etc for counterparties who are not Banks.
When the counterparty is a Bank, we can open Vostro accounts to represent
their monies with us or a mirror account to show balances of our Nostro
account with them.
Internal accounts are those owned by the bank for managing its own assets and

T24 Accounts - T3TAC - R11.1 130

 liabilities such as suspense account, cash account etc.

T24 Accounts - T3TAC - R11.1 130

 It is possible to control the display of account number. ACCOUNT.MASK
Field identifies the mask the user wants to apply to customer type accounts.
Input in this field must contain at least 4 '#' characters, to define the length of
the account number. Maximum length 20 with separators.
First character can be ‘R’ which means that the account number will be right
adjusted and it may contain leading zeros.
For example
1. Mask = ##### - #####. No 1234 displayed as 1234
2. Mask = ##### - #####. No.1234567 displayed as 12 - 34567
3. Mask = R##### - #####. No. 1234 displayed as 00000 - 01234
4. Mask = R##### - #####. No. 1234567 displayed as 00012 - 34567
Mask for internal accounts is hardcoded (###-#####-####).

T24 Accounts - T3TAC - R11.1 131

 ACCT.CHECKDIG.TYPE Field in COMPANY identifies the check digit
calculation method. This can optionally include a bank number prefix and a
modules 11 check, or a routine to perform check digit calculation. The
accepted values are
'1' : When LOCAL.CURRENCY starts with BE (i.e. identifies Belgium).
'2' : When LOCAL.CURRENCY starts with LU (i.e. identifies Luxembourg).
'3' : For 10 digit account numbers with a modules 11 check.
'4' : For 11 digit account numbers constructed with a 2 digit bank number
prefix defined in ACC.BKNO.PREFIX, followed by 7 identifying digits and a
2 digit mod 11 check digit.
'5' : For a standard check digit calculation with the account numbers zero filled
to the ACCOUNT.MASK.
'6' : For a 12-14 digit number with 2 check digits, the first 6 digits, the second
on the remaining digits. Check digits are calculated using mod 11.
'99' : No check digit calculation with the account number zero filled to the
ACCOUNT.MASK. When a local subroutine performs the check digit
calculation it can be included as ‘'@routine name’ 'blank': in all other cases.
Once a customer account record has been authorised in this company, it is not
possible to change the field .

T24 Accounts - T3TAC - R11.1 132

 While opening an account of a customer, CUSTOMER.ID, PRODUCT.CODE
and CURRENCY are mandatory. Currency in which the account is opened is
specified by the ISO code of the currency and is validated with the setup in the
static table, CURRENCY. Currency of an account cannot be changed after
authorisation. JOINT.HOLDER.ID Field records details of another customer
as a joint holder of the account. It is possible to multi value the field and add
one or more joint account holders. JOINT.RELATION.CODE Field is used to
indicate the relation between the account holder and joint account holder. Main
account holder can be replaced only with a joint holder, any time later. Product
code defines the type of the account like savings, current, Nostro, Vostro etc.
Category code should be in the range of 1000 and 9999 for all customer type
of accounts. Product codes can be changed subsequent to the opening of the
account. For example a current account of a customer can be changed into a
savings account without closing the account. Customer Id or Mnemonic can be
used to indicate the Customer of an account. While opening an Account,
Currency and product codes could be either chosen from the drop down list or
can be defaulted through suitably designed versions. Account can be accessed
in other applications by using either the ID, or MNEMONIC or ALT.ACCT.ID.
Mnemonic can be alphanumeric. Alternate Account id Format is dependent on
the definitions in the ALT.ACCT.PARAMETER application.
ALT.ACCT.ID refers to the structure of an alternative account numbers. In

T24 Accounts - T3TAC - R11.1 133

 practice where ever T24 has replaced a legacy system it may be for a short term
requirement to allow access to the customers account using the old numbers.

T24 Accounts - T3TAC - R11.1 133

T24 Accounts - T3TAC - R11.1 134
T24 Accounts - T3TAC - R11.1 135
T24 Accounts - T3TAC - R11.1 136
T24 Accounts - T3TAC - R11.1 137
T24 Accounts - T3TAC - R11.1 138
T24 Accounts - T3TAC - R11.1 139
T24 Accounts - T3TAC - R11.1 140
T24 Accounts - T3TAC - R11.1 141
T24 Accounts - T3TAC - R11.1 142
T24 Accounts - T3TAC - R11.1 143
 Retail home page has custom set of menus/enquiries required by a Retail user
to carry on the day today operations. Home Page will help the User to process
many customer related transactions, view the customer details, input
transactions and view/create opportunities for the customer. The Home Page is
designed to assist the Supervisor in authorising transactions, to view enquiries
and delivery messages.
Menus available for Customer, Accounts, CRM Funds Transfer, Standing
Orders, Direct Debits and bulk Standing Orders.
Components of Remittances Home Page is available in the form of tabs, for
easy navigation.
Functionality is provided with essential CRM features for the front end.
The menu can be used for opening of accounts and other related operations. It
is one stop access menu for many T24 usages.

T24 Accounts - T3TAC - R11.1 144

 Interest and charges can also be settled from or to any other account.
INTEREST.LIQU.ACCT Field identifies the Customer Account to which
interest is capitalised. This field is used only when interest is to be capitalised
to a Customer Account which is different from Account number. Account
number to which interest is to be booked should be entered. Account need not
belong to same customer . If this field is left blank, then Id of the Account
number is captured. INTEREST.CCY field identifies the currency of the
interest account entered in field INTEREST.LIQU.ACCT.
It is possible to mention separate interest liquidation account for debit interest
and credit interest. Example: For Account number 14613 debit interest to be
capitalised in 14796 and credit interest to be capitalised in 15173. Same can
now be achieved by inputting values in the following field namely,
INT.LIQU.TYPE, INT.LIQU.ACCT and INT.LIQ.CCY. In INT.LIQU.TYPE,
you have an option to select either, CR, CR1,CR 2 or DR , DR1 and DR2 .
These set of fields will be used only when debit and credit interest liquidation
account are different. Accounts can also be in different currency. When
liquidation accounts are in different currency, conversion takes place at mid
rate for liquidation. Liquidation can also be done through internal accounts.
CHARGE.ACCOUNT and CHARGE.CCY are used to indicate account in
any currency for charge liquidation. It is possible to indicate only non
contingent account in these fields.

T24 Accounts - T3TAC - R11.1 145

 INTEREST.COMP.ACCT Field is used when the balances of several
accounts are to be consolidated before interest is calculated and applied. Main
Account for the purpose of consolidation is indicated in this field. By doing
so, balances of various accounts in the same currency or in the same fixed
currency group are consolidated for interest calculation. The same is applied
to the account number indicated in INTEREST.COMP.ACCT Field.
It is possible to defer collection of charges, interest and taxes for a group of
customers for a specified period after calculation. Customers can also be
notified of the ensuing debits. This can be parameterised through ACCT.
GROUP. CONDITION.

T24 Accounts - T3TAC - R11.1 146

 Booking of interest can be suspended by suitably flagging INT.NO.BOOKING
Field . It indicates whether interest and charges calculated on this Account will
be accrued to Profit and Loss and booked to a Customer's Account as normal,
or will be suspended or not booked to Profit and Loss, or is for information
only. For example a bank may require to know the interest in a Nostro
Accounts and may not actually apply.
If this field contains 'SUSPENSE', interest and charges will be booked to the
Customer's Account, but no Profit and Loss entries will be generated, instead,
the amount which would have been accrued will be stored in a Suspense
Amount field in the Account record. It is used for bad and doubtful debts.
Suspended interest can be settled in full or in part through
ACCT.SUSP.SETTLE application.
If this field namely INT.NO.BOOKING contains 'Y', interest and charges are
calculated for information only. No entries will be passed, either to Profit and
Loss, or to the Customer's Account. This option can be used for Nostro
Accounts.

T24 Accounts - T3TAC - R11.1 147

 T24 has the functionality to Block funds in an Account. Defined amounts can
be locked for specified periods of time, with an override being required where
a transaction takes an Account below the value of the locked funds. This is
achieved through use of the application AC.LOCKED.EVENTS. Details of the
locking are automatically maintained in accounts as date wise ladder in
FROM.DATE and TO.DATE Fields. FROM.DATE will indicate the date of
commencement of locked amount. TO.DATE will indicate the end date of the
event. If FROM.DATE and TO.DATE Field are left blank, then the locked
event will stay forever in the account until the event is manually reversed. If
the date is backdated, the balance will only be checked from the system date,
although the LOCKED.EVENTS ladder in ACCOUNT will be built from this
date.
If an account has locked funds, then any transaction input or locked funds
input will trigger the system to check the Balance in the Account against the
Locked funds. Available Limit can also be considered for Locked amount
checking.
The locked amount check is done on the current balance and then on the
future cash flows if there are any. If Locked amount checking with Limit is
allowed, then the Limit or Balance available refers to Working Balance or T24
Available Balance after taking the locked amount and Limit into consideration.
This functionality is set at ACCOUNT.PARAMETER,

T24 Accounts - T3TAC - R11.1 148

 ACCT,GROUP.CONDITION or on an individual ACCOUNT record using the field
LOCKED.WITH.LIMIT. The default setup is to ignore limit for locked amount
processing. Priority is given to the definition at the lowest level.
If this setting is set as YES, Limit will be included for Locked amount checking.
Default setting is NO where Limit is not included for checking.

T24 Accounts - T3TAC - R11.1 148

 Locked amount check is done on current balance or current available limit against the worst locked balance, if there is
any shortfall, an override is raised:
Override ‘ACCT.BAL.LT.LOCKED’ is raised for an account with no limit or if Limit is not allowed on Locked
amount checking.
OR
Override ‘LIMIT.WORKING.LT.LOCKED’ is raised for an account with a Limit and limit is allowed on Locked
amount checking.
If there are any future cash flows, then the locked amount for future cash flows is done against the locked balance
prevailing on the Available date ladder.
If the Available date is less than the date of the worst locked amount, and there is a shortfall then an override is raised:
Override ‘AVAILABLE.LOCKED.OVERDRAFT’ is raised for an account with no limit or if limit is not allowed with
locked amount checking.
OR
Override ‘AVAIL.LOCKED.LIMIT.OVERDRAFT’ for an account with a limit and limit is allowed with locked
amount checking.

T24 Accounts - T3TAC - R11.1 149

 If Available date is greater or equal to date of the worst locked Amount then
the shortfall on that date is compared to the one from current Balance check
and an override is raised if the shortfall is worse.
If the shortfall on Available funds is greater than the shortfall on Working
Balance, then the worst shortfall is kept.
The content of the following overrides, triggered from AC.LOCKED.EVENTS
input, may be changed by User if Locked amount checking with Limit is set:
Override ‘ACCT.BAL.LT.LOCKED.LIMIT’ for check on current balance
Override ‘AVAIL.LOCKED.LIMIT.OVERDRAFT’ for check on future cash
flows
With Locked amount checking with Limit on, if the Limit is expiring within
the Available funds ladder or the Locked amount ladder, then an override is
raised to indicate that the Limit is expiring:
Override ‘AVAIL.LIMIT.LOCKED.EXPIRING’ to indicate that the Limit is
expiring.

T24 Accounts - T3TAC - R11.1 150

 Posting restrictions can be defined to restrict Debit, Credit or all entries using
POSTING.RESTRICT Field to produce suitable overrides.
REFERAL.CODE Field specifies the conditions under which Account details
or details of entries over the Account are to be included in an end of day report
for referral to the Account Officer responsible.
Referral conditions can be defined depending on transaction such as
transaction code, amount ,sign, or the balance of the Account.

T24 Accounts - T3TAC - R11.1 151

 It is possible to link a overdraft to one account or more than one account.
If SINGLE.LIMIT Field in ACCOUNT is set to “Y” then only one account can
be attached to a limit record. If this is set to “N” or Null, multiple accounts
can be attached to a limit. The combined total all debit account balances
resulting in an overdraft should not exceed the sanctioned limit.

SINGLE.LIMIT Field should be set as Y/N. It can be defaulted from

ACCT.GROUP.CONDITION using SINGLE.LIMIT.DEFLT Field.
SINGLE.LIMIT in account can also be used independently without setting up
ACCT.GROUP.CONDITION.

For certain types of limit product it is possible to net credit account balances
and debit account balances found in ECB.

If an account with a credit balance is to be included in the limit checking, the

ALLOW.NETTING Field should be set to YES. In this instance the total of
credit and debit balances will be netted.
Default value is No, then the debit balances of accounts will be totaled
together, without adjusting for any credit balances, for limit checking

T24 Accounts - T3TAC - R11.1 152

 purposes.

T24 Accounts - T3TAC - R11.1 152

T24 Accounts - T3TAC - R11.1 153
T24 Accounts - T3TAC - R11.1 154
T24 Accounts - T3TAC - R11.1 155
 It is possible to set limits for overdrafts using LIMIT application and link to
account. Scheduled decrease and increase are possible in limits.
If the Customer has a Credit Limit covering an Account, LIMIT.REF Field
identifies the type of limit applicable to the Account and forms part of the key
to the Limit record containing Credit Limit details. This field is also used to
indicate Nostro Accounts. Except for Nostro and Internal Accounts, this field
is accessed by the Limits System whenever a debit transaction is processed for
a Account.
If no Limit Reference is specified, an 'UNAUTHORISED OVERDRAFT'
message is displayed and an Override is required before the transaction will be
accepted.
If a Limit Reference is specified, the corresponding Limit record is checked.
If it covers the new Working Balance, the transaction is accepted, otherwise a
message is displayed and an Override is required before the transaction will be
accepted.

T24 Accounts - T3TAC - R11.1 156

 The balance related fields of Account are available in ECB.
Credit check is made whenever a debit transaction is validated or is validated
and authorised at the same time. An option is available to set credit checking
for an account against working balance and cash flows or available balance via
the CREDIT.CHECK Field in ACCOUNT.PARAMETER. The available
choices are AVAILABLE when credit checking is made using
AVAILABLE.BAL, or WORKING when credit checking is made using
WORKING.BALANCE, or FORWARD when credit checking is made using
WORKING.BALANCE plus today's forward movements, or AVAILWORK
when credit checking is made using AVAILABLE.BAL and
WORKING.BALANCE, or AVAILFWD when credit checking is made using
AVAILABLE.BAL and WORKING.BALANCE plus today's forward
movements, or BLANK when the default checking is using
WORKING.BALANCE
AVAILABLE.BAL always includes authorised debits and credits.
Parameterisation regarding the update of available balances with unauthorised
entries takes place as follows via AVAILABLE.BAL.UPD. BOTH make
unauthorised debits and credits to make up available balance NONE means no
unauthorised movements to update available balance. DEBITS will use only
unauthorised debits to make up available balance. CREDITS will use only
unauthorised credits to make up available balance. It will be selected in the

T24 Accounts - T3TAC - R11.1 157

 order ACCOUNT or in its absence ACCT.GROUP.CONDITION level or in its
absence ACCOUNT.PARAMETER level.

T24 Accounts - T3TAC - R11.1 157

T3TFA - Financial Accounting - R10.2 158
 We can observe that the cashflow Days field is now setup for 5 days with
Available balance updates for unauthorised Debits

T24 Accounts - T3TAC - R11.1 159

 LD loan is booked for $5000. On maturity date 25th Apr 11, account 45675
would be debited for principal and interest.

T24 Accounts - T3TAC - R11.1 160

 The available balance ladder is updated for the unauthorised debit only as per
the Account parameter setup. The credit of loan amount is not updated due to
the setup in Account parameter. Please note the LD record is not yet
authorised.

T24 Accounts - T3TAC - R11.1 161

 We can observe that the LD Deposit of $1000 is to be debited on 23 Apr 11 i.e.
on value date of deposit from Drawdown account.
The override message for this debit already includes the Available balance
ladder update for unauthorised debit of $5000 LD loan booked previously.
Please note both the LD records are pending to be authorised.

T24 Accounts - T3TAC - R11.1 162

 In screenshot 1 -We can see the ECB record of the account with available
balance ladder for unauthorised LD Loan maturity for $5000 and unauthorised
LD Deposit drawndown for $1000

In screenshot 2 -
Upon authorisation of LD deposit, we can find the available balance getting
updated for LD deposit maturity as well

In screenshot 3 -
Upon authorisation of LD deposit, we can find the available balance getting
updated for LD loan liquidation on the start date of the loan

T24 Accounts - T3TAC - R11.1 163

 In this screenshot, we can find a LD deposit booked after the cashflow ladder
days ie the start date and maturity dates are beyond 5 days cash flow ladder
There is no impact on ECB

T24 Accounts - T3TAC - R11.1 164

T24 Accounts - T3TAC - R11.1 165
 We can find the Account parameter record has got a credit check field update
for working balance.

T24 Accounts - T3TAC - R11.1 166

 $1000 is credit to the account used in the previous workshop
We can find the ECB is updated with working balance and available balances
field now.

T24 Accounts - T3TAC - R11.1 167

 Upon booking a debit from the account used earlier, we can find the override
message displays an unauthorised overdraft based on the Working balance.

T24 Accounts - T3TAC - R11.1 168

 It is possible to set first interest rate for balances up to sanctioned overdraft
and second interest rate for balances in excess. ACCOUNT.DEBIT.LIMIT
table allows overdraft limits to be specified for individual Accounts, which can
then be used as the limit for the first rate of debit interest specified in the
appropriate Group Debit Interest condition. If a Group Debit Interest condition
record contains 2 rates, but no limit for the first rate, the overdraft limit
specified for each Account in this table is used as the limit for the first rate.
In this way it is possible to specify a different limit for the first rate for each
Account, without having to specify separate Account Debit Interest condition
records. If there is no limit specified in this table for a particular Account, a
limit of zero is assumed, and the 2nd rate specified is effective for all balances.
Using this facility, it is not possible to specify more than 2 rates in the Group
Debit Interest condition record.
If LINK.TO.LIMIT Field in account is set as yes, debit interest for the account
will be set according to allocated limit amount namely ONLINE.LIMIT to act
as first level for debit interest. If only GROUP.DEBIT.INT has been defined,
system will create a record in ACCOUNT.DEBIT.LIMIT application with
value of ONLINE.LIMIT to act as first level for debit interest. If
ACCOUNT.DEBIT.INT has been defined for an account, system will update
the first band amount in DR.LIMIT.AMT Field there with value of
ONLINE.LIMIT . This is operational if only one account is attached to a

T24 Accounts - T3TAC - R11.1 169

 limit.

T24 Accounts - T3TAC - R11.1 169

T24 Accounts - T3TAC - R11.1 170
T24 Accounts - T3TAC - R11.1 171
T24 Accounts - T3TAC - R11.1 172
 In T24, a Nostro account is opened to reflect transactions of the Nostro
account held with another bank. It is a mirror account of the Nostro account
maintained with another bank. If customer is a Bank then the Sector of the
Customer should conform to settings in ACCOUNT.CLASS with Id as BANK.
For opening Nostro accounts, settings in ACCOUNT.CLASS with Id as
NOSTRO should also be followed. Here, the Product Category code or the
Sector of Banks are mentioned.
If the Product category code of NOSTRO and sector code of Banks are used,
T24 will recognize this as a Nostro and validate it accordingly. Statements
generated by T24 for a Nostro account are not meant to be sent for other bank.
It is produced for internal purpose of reconciliation. RECONCILE.ACCT
Field should be set as Y so that statement could be sent to the reconciliation
department of the bank. When the account statement is received from the other
bank, Nostro reconciliation department could then reconcile that with our
statement.
EXTERNAL.ACCT.NO Field defines actual Account Number in the Books of
the Correspondent Bank with whom a Nostro Account relationship exists. Any
details entered into this field will be accepted without further validation and
are for information purpose only. AGENCY record will be suitably updated
with this value to indicate our account number with the other Bank.
RECON.TOLERANCE Field identifies the tolerance amount allowed when
matching items in Nostro Reconciliation. This field may either be set to 0 if

T24 Accounts - T3TAC - R11.1 173

 tolerance is not required or an amount in the currency of the account.

T24 Accounts - T3TAC - R11.1 173

 If a Nostro account is opened as per ACCOUNT.CLASS rules , T24 has
facility to change the product code without closing an account.
Nostro account category code can be replaced only by another Nostro account
category.
LIMIT.REF is indicated as NOSTRO by the system so that limits need not be
checked.
AGENCY record is opened by the System automatically where this Nostro
account details are captured. If AGENCY record is already existing, then it
updates Nostro account details there as mentioned in our external account
number allotted by the other bank.
CUSTOMER.ID will not be allowed to be changed till AGENCY record is
modified.
RECONCILE.ACCOUNT should be set to Y , so statements are to be sent to
the reconciliation department of the bank. Reconciliation with the actual
statement received can be done automatically or manually.

T24 Accounts - T3TAC - R11.1 174

T24 Accounts - T3TAC - R11.1 175
T24 Accounts - T3TAC - R11.1 176
T24 Accounts - T3TAC - R11.1 177
 When an account remains inactive without any debit or credit transactions
from the Customer side, then it is treated inactive. Entries are accepted only
after overrides. Period in months for deciding inactivity is defined in
INACTIVITY.MONTHS Field in COMPANY table.
INACTIV.MARKER is set whenever the dates of the last credit and debit
entries generated by the Customer from the field
DATE.LAST.CR.CUST and DATE.LAST.DR.CUST are more than the set
months. Number of months for inactive accounts is specified in the Company
record through the INACTIVITY.MONTHS. Field. This marker is set during
the close of business processing.
When this marker is set in an Account , entries will be accepted with an
override.
It can only be reset through ACCT.INACTIVE.RESET application for the
inactive Account number.
Inactive months setting is enabled in product level as well i.e. in
ACCT.GROUP.CONDITION application, a field is introduced for
differentiating groups of accounts by having different inactive months settings.
When INACTIVE MONTHS is defined both in COMPANY application and
ACCT. GROUP.CONDITION application, the period in
ACCT.GROUP.CONDITION application takes precedence.

T24 Accounts - T3TAC - R11.1 178

T24 Accounts - T3TAC - R11.1 178
 It is possible to issue passbooks if the rules in the record SAVINGS in
ACCOUNT.CLASS is met and PASSBOOK Field is set as YES for an
Account.
It is possible to set independent statement requirements that override
STMT.GEN.CONDITION for individual accounts. Frequency for issuing
statement can be set in STMT.GEN.CONDITION as Daily (every working
day), Monthly, Quarterly or Six monthly or Yearly. It can be changed to have
weekly or twice a month frequency also. Each Statement General Condition
record specifies the various combinations of field values defining all Accounts
with a particular default statement frequency. If the details of an Account do
not match the conditions specified in any Statement General Condition record,
a default statement frequency of Monthly is used.
As soon as an account is opened, a record is created in
ACCOUNT.STATEMENT with the id as Account number. This record gets
default rules set up at AC.STMT.PARAMETER. Frequency for issuing
statement is defaulted in STMT.FQU.1 Field from STMT.GEN.CONDITION .
If the passbook has been opted , STMT.FQU.1 Field and other related fields
are left blank.

T24 Accounts - T3TAC - R11.1 179

 Special statements are produced through SPECIAL.STATEMENT Field, even
if there have been no entries since the last Cycle or statement, regardless of
IF.NO.MOVEMENT Field. STMT.FQU.2 Field specifies the next date and
subsequent frequency for producing statements for additional eight statement
cycles. For each cycle, the field could be sub-valued in which case,
a statement containing entries from the statement last printed in
that frequency cycle, would be generated for each sub-valued date. The first
Statement in the additional Cycles would contain entries from the last printed
Cycle 1 Statement.
Records like STMT.PRINTED, STMT2.PRINTED, ACCT.STMT.PRINT and
ACCT.STMT2.PRINT which were used to create statements henceforth will
not be updated by STMT.ENTRIES. Instead, the last sequence number raised
as STMT.ENTRY will be stored and processed date wise in ACCT.ACTIVITY
records. Statement printing process need to pick up sequence number from
the last statement date till today from ACCT.ACTIVITY to print statements.
Statement updates will be moved to ACCOUNT.STATEMENT file for all the
statement frequencies for accounts.

T24 Accounts - T3TAC - R11.1 180

 To deliver statement through SWIFT, SWIFT message type for the Cycle 1
Statement must be specified. It could be 940 Customer statement or 941
Balance Report or 950 Statement. If no value is specified, Message Type 950
would be generated. MESSAGE.TYPE specify the Message type here as either
941 or 942. In the next field how these messages are to be generated incase
special request received. SEND.MSG.TYPE enables the sending of message
MT941 or MT942 whether on an ad-hoc or timed daily basis. If set to "Yes"
with MESSAGE.TYPE as "942" in the previous field then MT942 message
can be generated through DE.MT942. REQUEST or automatically at the time
indicated at MESSAGE. TIME Field. If left blank or set to "No” interim
transaction report cannot be generated. When only one value is used, the floor
limit applies to both debit and credit amounts. If left blank then a value of zero
is used which means all entries are detailed. DR.FLOOR.LIMIT Field is used
in conjunction with the MT942 Fields. DR.FLOOR. LIMITT and
CR.FLOOR.LIMIT is to indicate floor limit for transactions to be included in
interim report. Smaller entries are included in entry totals and count. For
example where a value entered is 100,000 (for a USD Account) in
DR.FLOOR.LIMIT Field then only credit and debit entries where the amount
is greater than USD 100,000 are detailed. In case a value entered in this field
as 100,000 (for a USD Account) and in CR.FLOOR.LIMIT Field 500,000 is
given, then only debit entries where the amount is greater than USD 100,000
& credit entries greater than USD 500,000 are detailed.

T24 Accounts - T3TAC - R11.1 181

T24 Accounts - T3TAC - R11.1 182
T24 Accounts - T3TAC - R11.1 183
 It is possible to set Account level rules for capitalisation through
ACCT.CAPITALISATION. Account specific debit and credit interest rates
and rules are set through ACCOUNT.DEBIT.INT and
ACCOUNT.CREDIT.INT so that special treatment could be given to a select
account.
ACCT.INTERIM.CAP table is used to specify dates of capitalisation for any
Account for which interim interest application is required on a particular day.
Interim interest applications do not affect the normal cycle of interest
applications for the account, specified either at group level or at Account level.
For each Account for which an interim interest application is required, it is
possible to specify each type of interest separately.
Interim interest applications may be requested in advance and will be
processed on the specified day. Interest is calculated up to the date specified.
Values in ACCOUNT.ACCRUAL TABLE specifies whether interest
calculations for application are inclusive or exclusive of the balance of
capitalisation date.
If the date specified is not a working day, then interest application is processed
on the previous working day, unless the Last Day Inclusive Field in the
ACCOUNT.ACCRUAL table contains 'Y' and a month end accrual day falls
before the date specified, in which case the application is processed on the
next working day. In either case, the figures are calculated as if it had been
processed on the date specified. There is no need to use this table to request
interim interest applications for Accounts which are being closed. This is

T24 Accounts - T3TAC - R11.1 184

 handled by the Account Closure routine .

T24 Accounts - T3TAC - R11.1 184

T24 Accounts - T3TAC - R11.1 185
T24 Accounts - T3TAC - R11.1 186
T24 Accounts - T3TAC - R11.1 187
T24 Accounts - T3TAC - R11.1 188
T24 Accounts - T3TAC - R11.1 189
 AC.CHARGE.REQUEST is used to generate charges as independent
transactions either to request payment of charges, interest or other expenses or
to advise of a debit or credit to the account owners’ account.
AC.CHARGE.REQUEST is a fully integrated module to provide advanced
banking services to the user. Used as an interbank facility for requesting or
advising charges of many types from other financial institutions. Instructions
are entered manually by the user and the system will fully interact with the
internal Delivery Module and Swift. Charge request module will calculate any
tax or commission that should apply to the charge and then process the
requested SWIFT and update accounting records.
If REQUEST is the chosen in REQUEST.TYPE , it will raise MT n91 , but
no accounting entries. CHARGE option raises accounting entries and MT n90
for Customer or Vostro accounts and MTn91 for Nostro or Internal accounts.
ADVICE raises MT n90 , but no accounting entry. Request type BOOK does
not produce any delivery message.
Suitable charge defined in FT.COMMISION.TYPE can be used in mandatory
CHARGE.CODE.Field

T24 Accounts - T3TAC - R11.1 190

 CHARGE.DETAIL Field contains a code which details what for the charge
is. For example it could be a telephone charges or agents commission etc. This
is a universally defined code and appears on the SWIFT message. All valid
codes are maintained on the SWIFT.CODE.WORDS file and relate to a
particular message type. If there are no valid codes for a specific message
series, then the EXTRA.DETAILS Field must be used. Either this field or
EXTRA.DETAILS must be populated. Must be a valid code for the message
series MSG.SERIES entered above and correspond to the SWIFT message this
charge wishes to raise as detailed here.
In category 1 and 2 messages for example codes like COMM - Our
commission or INT - Interest related charges can be used;
In respect of category 4 and 7 messages the following codes are among the
valid codes ;
AGENT - Agent's commission. COMM - Our commission.
In category 5 messages the code may contain one or more of the following
BROK - Brokerage. CHGS - Charges. COMM - Commission.

T24 Accounts - T3TAC - R11.1 191

 STATUS Field indicates current status of charge request. STATUS Field is set
to PAID if accounting entries are required, as this is the status that generates
the entries. Four status options are available.
PAID - Charges paid and accounting entries to be raised.
TAKEN - Account entries for the charge have been raised via another
application.
UNPAID - Awaiting payment. A request has been made, but no further action
has been taken. Status could be subsequently changed to any other status with
suitable change in CHARGE.DATE Field.
WOF - If the charge request is refused.
When the STATUS is UNPAID, the transaction will stay on the live file
indefinitely. All other status will put the transaction to the history file during
the Close of Business process.
Request type of CHARGE or BOOK along with Status of PAID will raise
accounting entries. While CHARGE will create delivery message and BOOK
without delivery message.

T24 Accounts - T3TAC - R11.1 192

T24 Accounts - T3TAC - R11.1 193
T24 Accounts - T3TAC - R11.1 194
T24 Accounts - T3TAC - R11.1 195
 Closure of account can be done online or during the Close of business batch
run. Using Account Closure Sub menu , it is possible to give the ID of the
account record which needs to be closed. System defaults Yes in
CLOSE.ONLINE Field and the closure date is system date. If the account is
not closed online then the future date for closing can be indicated here.
POSTING.RESTRICT Field in the ACCOUNT record should have values
between 90-99 for automatic closure.
CAPITAL.DATE Field is used to indicate the date on which system should
start the closure process by capitalising interest and charges.
It is mandatory to mention a Settlement Account which would be used to credit
the balance available in the account closed. This account can be a customer
account or an internal account. If a SETTLEMENT ACCOUNT is specified,
an override will be required if the sum of the balance and outstanding interest
and charges is negative. If the SETTLEMENT ACCOUNT has a different
customer to the account being closed, an override will appear.
When account is closed during online or by automatic closure, closing
statements are produced during COB of the closing date.
Subsequent input to this record will allow the CAPITALISATION DATE and
SETTLEMENT ACCOUNT to be changed. Interest and charges will also be
re-calculated if required. Interest and Charges are calculated on the value dated

T24 Accounts - T3TAC - R11.1 196

 balances and account activity statistics stored in the ACCT.ACTIVITY file, taking
into account all entries over the Account up to and including the last end of day
processing.

T24 Accounts - T3TAC - R11.1 196

 Account charges are not calculated for the month in which the Account is
closed, unless the closure date is the last day of month.
It is possible to specify any predefined charges for closing account.
During close of business on closure Capitalisation date, outstanding interest
and charges are recalculated and capitalised. During the start of day
processing of next day, a funds transfer is generated between the Account and
settlement account, to automatically bring the account balances in ECB to
zero.
During end of day processing, if the ACTUAL and CLEARED.BALANCE
and unauthorized balance related keys in ECB are zero, ACCOUNT is closed.
TOT.UNAUTH.CR, TOT.UNAUTH.DR indicates the total unauthorised credit
and debit to be processed today.
TOT.FWD.UNAU.CR, TOT.FWD.UNAU.DR indicates the total unauthorised
credit and debit to be processed in future date.
The details of unauthorised transaction are available in UNAUTH.KEY and
FWD.UNAU.KEY or in the AC.UNAUTH.ENTRY table (after the threshold
in ACCOUNT.PARAMETER is breached)
If either BALANCE in ECB is not zero , then ACCOUNT remains open and
interest capitalisation processed every day until it can be closed.

T24 Accounts - T3TAC - R11.1 197

 When the ACCOUNT is closed, it is removed from the live file and written to History
file. A closing account statement is produced during cob and remaining Standing
Orders are cancelled.

T24 Accounts - T3TAC - R11.1 197

 When online closure of Account is required, then CLOSE.ONLINE Field is to
be set to Y and CAPITAL.DATE should be current date.
If SETTLEMENT.ACCOUNT is supplied, then, on line final settlement takes
place when ACCOUNT.CLOSURE is authorised.
Closure could be effected through TELLER application. When
SETTLEMENT.ACCOUNT is not supplied, then a TELLER record is created
in IHLD status. On authorisation of TELLER record, the
ACCOUNT.CLOSURE record will also get authorised and settlement entries
will be generated by the system

It is not possible to close an account which has unauthorised entries.

T24 Accounts - T3TAC - R11.1 198

T24 Accounts - T3TAC - R11.1 199
T24 Accounts - T3TAC - R11.1 200
T24 Accounts - T3TAC - R11.1 201
 In this workshop, let us book a FT with future value date between two T24
accounts. Then, try to close the account without authorising that FT. Please
observe the error thrown.

T24 Accounts - T3TAC - R11.1 202

 We can find that the FT is booked with the value date as a future value date

T24 Accounts - T3TAC - R11.1 203

 We can find that the ECB record for the accounts are updated with
unauthorised balances in Debit and Credit related fields.
On trying to close the account we get an error saying “ unauthorised entries
exist for this closing account”. As a result we are unable to open the account.

T24 Accounts - T3TAC - R11.1 204

 Internal accounts are those owned by the bank for managing its own assets and
liabilities such as suspense account, cash account etc. They are not designed
to calculate or apply interest and charges . Cash Account, Capital Account,
Premises and Furniture ,Departmental and other suspense Accounts, Tax
collected and to be remitted to Government are maintained through internal
Accounts. No counterparty is required for opening the accounts. Format of an
internal account consists of currency, category code of the account and a
sequential number.
ACCOUNT.TITLE , SHORT.TITLE, MNEMONIC and
ACCOUNT.OFFICER are mandatory fields for opening of account. It is
advisable to include currency in ACCOUNT.TITLE and SHORT.TITLE.

T24 Accounts - T3TAC - R11.1 205

 PRINT.STMT Field in ACCOUNT.STATEMENT is an optional input, and
input can only be made for Internal Accounts. Input can be Null, Yes or No.
It is possible to selectively mask some entries from appearing in a statement .
For example if a wrong entry is reversed for rectification, we can mask both
entries from appearing in a statement by using AC.PRINT.MASK application.
It is possible to consolidate entries in high volume accounts together and store
details in a detail file that can be archived. If AC.CONSOLIDATE.COND is
set then entries will be consolidated by the following consolidation criteria:
Entry Type - S, C or F (S for statement entries, C for Category entries and F
for Forward entries)
Account Number or P&L category
Currency ,System Id, Transaction Code, Value Date, Exposure Date, Reversal
Marker
Currency Market, Suspense Category, Terminal Number, Account Officer
(P&L only)
Product Category (P&L only),Plus any additional elements defined in
AC.CONSOLIDATE.COND.
Through ADD.CONSOL.FLD, Field we can include additional STMT /
CATEG entry Fields to be used in consolidation of entries. Field must be an

T24 Accounts - T3TAC - R11.1 206

 existing name in STANDARD.SELECTION application.

T24 Accounts - T3TAC - R11.1 206

 When the AC.CONSOLIDATE.COND is attached to an Account, the
STMT.ENTRY records generated for the Account will be cumulatively totaled
and consolidated . Similarly when AC.CONSOLIDATE.COND is attached to
a PL CATEGORY, the CATEG.ENTRY records for the Category will be
cumulatively totaled and consolidated. There could be more than one
consolidated entry at any time for an Account or for a PL Category, since
consolidation is based on both fixed criteria and user-definable criteria.
.

T24 Accounts - T3TAC - R11.1 207

 Id for the table is alphanumeric and can be between 3 and 20 characters.
When S option is chosen, non-F entries are consolidated value-date wise. F
Statement entries will not be consolidated.
To consolidate F Statement entries also, the option F should be specified in
addition to S.
Selected EB.SYSTEM, TRANSACTION and CATEGORY codes and/or
Routines can be excluded from consolidation.
ADD.CONSOL.FLD Field can have values of additional STMT /
CATEG.ENTRY data fields to be used in consolidation of entries.

T24 Accounts - T3TAC - R11.1 208

 There could be multiple consolidated STMT.ENTRY records during a day for
an Account depending on the system enforced/user defined consolidation
criteria. Similarly, there could be multiple consolidated CATEG.ENTRY
records for a PL Category during a day.
In AC.CONSOLIDATE.COND, the field NO.ENTRIES.START specifies
number of entries after which the consolidation will happen.
NO.DETAIL.APP field will be used to mention the applications for which the
details of the consolidated entries will not be maintained.
The record Id created in AC.CONSOLIDATE.COND has to be attached to the
field CONSOLIDATE.ENT of an account or a PL category. Please note, if
attached to an account, its STMT.ENTRY records will be consolidated. If
attached to a Pl category, its CATEG.ENTRY records will be consolidated. For
RE.CONSOL.SPEC.ENTRY, only one record with Id:REDEFAULT is
allowed, this is not to be attached to any category.
Consolidation of CATEG.ENTRY and RE.CONSOL.SPEC.ENTRY is covered
later during the course.

T24 Accounts - T3TAC - R11.1 209

 Entries are consolidated based on the following criteria:
Entry Type - S, F, C or R (Statement, Forward dated,Category or Special
entries), CRF Key (for Category and Special entries only), Account Number or
Product Category, CR or DR, Currency, System ID, Transaction Code, Value
Date, Exposure Date, Reversal Marker, Currency Market, Suspense Category,
Terminal Number (not updated), Booking Date, Account Officer (P&L only),
Product Category (for Category and Special entries only).
Besides the above, additional elements defined in ADD.CONSOL.FLD Field.
The default AC.CONSOLIDATE.COND record with Id: DEFAULT exists for
the purpose of consolidation of
STMT.ENTRY records of NOSTRO and internal accounts.
NO.ENTRIES.START Field in DEFAULT record in
AC.CONSOLIDATE.COND table can be set to 0.
A default record named CLDEFAULT exists for the consolidation process of
entries on Customer accounts. The purpose is to start consolidating entries by
default after the 50th statement entry raised for the day.

T24 Accounts - T3TAC - R11.1 210

 System automatically recalculates and corrects interest when entries with
value dates prior to the last interest application are processed. In such
situations, the old results are stored in CORR.ACCT.CR, CORR.ACCT.DR,
CORR.ACCT.CR2 and CORR.ACCT.DR2 . CORR.ACCT.CR is an internal
file containing details of previous calculations of Credit Interest for
capitalisation which have subsequently been recalculated with different results.
New result stored in STMT.ACCT.CR record is compared with the one
previously calculated, and if there is any difference, the old one is stored
(unchanged) in this file, the corrected one is written to the STMT.ACCT.CR
file and appropriate accounting entries are generated for the differences. Each
time the same capitalisation is corrected, the CORRECTION NUMBER is
incremented by 1. Each CORR.ACCT.CR record is an exact copy of the old
STMT.ACCT.CR record, except for the ID which has the Correction Number
suffixed. CORR.ACCT.CR2 is similar and denote CR2 interest.
CORR.ACCT.DR and CORR.ACCT.DR2 files contain details of the
previous calculation of debit interest, which have been capitalised and
recalculated and corrected. The new details are held on the STMT.ACCT.DR
and STMT.ACCT.DR2 files.
.

T24 Accounts - T3TAC - R11.1 211

 TABLE.CAPITALIS.CORR table is used to request recalculation and
correction of previously applied interest. System automatically recalculates
and corrects interest when entries with Value Dates prior to the last interest
application are processed. It does not automatically recognise back dated
changes to interest rates or conditions.
It is possible to request corrections for all Accounts, specific Accounts or
selected Groups of Accounts. In each case, the date from which the
recalculation should start must be specified. Corrections are calculated up to
each Capitalisation Date between the recalculation start date specified and the
last Capitalisation Date. Correction entries are generated with the correct
Value Date for each Capitalisation period and taken into account in the
recalculation of subsequent periods.
Both automatic and requested recalculations and correction entries are
processed during the end of day programs.

T24 Accounts - T3TAC - R11.1 212

In order to process high volume of transactions in an account, T24 Accounts
table has flag to tag to indicate the account as high volume account. Individual
accounts and groups of accounts will allow the high volume processing option
to be selected. It is possible to switch off the high volume processing at any
time if required and this will cause the account to revert to standard behaviour.
The balances are updated to ECB in multiple sessions to avoid locking
contention
A separate service is run in the background to merge the balances to the master
record. This is completed before the system end of day CRF and static change
processing
The balances are initially updated in the table AC.HVT.TRIGGER from which
they are merged into the master ECB record. Records in AC.HVT.TRIGGER
carry the suffix of session details of the transaction. The suffixed records are
deleted after this merger.
Remember, For enquiries a notional merger is done by just summing up the
balances without any actual merger. This is achieved by another background
service being run.

213
Recollect that Account balances are updated in ECB.
Here T24 updates AC.HVT.TRIGGER with the details of the transaction. The
id of the records in the table is account id with suffix made up of session
number, Day, time (hour) in ID to avoid locking contentions for concurrent
updates. For example, 50644!6627!06!53, 50644!3275!06!54,
50652!3275!06!54
AC.HVT.TRIGGER contains the complete data to be updated to the respective
files related to account namely ECB, STMT.PRINTED, ACCT.ENT.TODAY,
ACCT.ENT.FWD, STMT.VAL.ENTRY, ACCT.ACTIVITY.
While merging the data is written to the respective files and
AC.HVT.TRIGGER details are deleted.

214
Each agent will merge all the records for a single account. The merging service
can run continuously reselecting the driving table.
It will first sort select the driving table to a table for processing, filtering out
any records with forward booking dates. Each session will try to lock the
records, if another process has locked it then it will skip processing leaving the
record to be merged at a later time. When this service is running prior to COB
CRF updates then it must wait for any locks to be cleared.
AC.HVT.MERGE is the service routine to merge the AC.HVT.TRIGGER
records of HVT accounts. The process is to merge the AC.HVT.TRIGGER
records with suffixes to the main ECB record of the account. The other updates
of the account (like ACCT.ACTIVITY, STMT.VAL.ENTRY etc) stored in
AC.HVT.TRIGGER are moved to the respective files. After processing each
suffixed record it is deleted from AC.HVT.TRIGGER.
During COB at the job SYSTEM.END.OF.DAY5 calls this merging service
automatically for a real merge.
To have an online merge, anytime during the day this service can be run in the
background for online merge.
AC.HVT.MERGE.STMT.CONCAT is routine used to consolidate balances for
an Account ID without doing any updates to the file. The enquiries use this
routine to use for notional merging of balances. The list of entries is returned
without actually merging the records.

215
What types of accounts can use the high volume processing?
Customer Accounts
Nostro Accounts
Internal Accounts

The high volume processing is not yet available for AA Accounts.

It is not possible to run credit checking with a high volume account.

216
The field HVT.FLAG in the account controls if an account is included in high
volume processing. IF this is set to No or Null then the account is not
included. If et to Yes then it is included.

An account can be added to high volume processing or removed at any time by

amending this field.

217
In this workshop, we will edit an existing account in T24 and update the
account as HVT account
We will also open a new account with HVT flag marked as YES

218
The existing account is marked with HVT flag as yes.

219
The new account is created with HVT flag marked as yes

220
Create two funds transfer records to credit one of the high volume accounts

After booking the FT we can find the records updating AC.HVT.TRIGGER

file

221
The two FT’s have been entered crediting high volume account 66093891

222
AC.HVT. TRIGGER records are created for both the contracts
Here we find that the id of the AC.HVT.TRIGGER record contains the account
number, session id followed by the T24 date and the time of booking the
contract
The field Account id indicates the account for which the trigger is booked
ECB Record contains the ECB record details to be updated in ECB for this
transaction in the respective account
STMT.VAL.ID contains the ID to the records which will be merged in
STMT.VAL.ENTRY
ACCT.STMT.PRINT contains the id of the record from ACCT.STMT.PRINT
for this transaction which will be merged in the respective account
STMT.PRINTED.ID contains the id of the record from STMT.PRINTED
which will be merged his transaction in the respective account
ACTIVITY.RECORD contains the id of the ACCT.ACTIVITY details

223
STMT.PRINTED is another file that is updated for high volume processing,
multiple records will be created for high volume which will be merged when
the service is run.

The screen shots show the records created for the FT’s crediting account
66093891

224
The EB.CONTRACT.BALANCES record has not been updated with the
transaction details. This will happen only after the merge has been run.

225
Multiple records in ACCT.STMT.PRINT and STMT.VAL.ENTRY are raised
for high volume processing these will be merged when the service is run.

226
Run the TSA.SERVICE BNK/AC.HVT.MERGE.SERVICE

Then check the EB.CONTRACT.BALANCES record has been updated for the
account and the underlying accounting files entries have been merged and the
original entries removed.

227
The EB.CONTRACT.BALANCE record has beee updated with the relevant
transaction details. The balance fields have been updated with the amounts
from the credit transactions.

228
The underling entries on the accounting files have been merged into master
records for the account.

229
The future value date transaction and F stmt entries generated for the HVT
account are also updated through the AC.HVT.TRIGGER.
Remember, While dropping the F stmt entries the AC.HVT.TRIGGER id is
suffixed with ‘DEL’

230
T24 Accounts - T3TAC - R11.1 231
T24 Accounts - T3TAC - R11.1 232
 Accounting entries passed for Accounts are contingent as well as non
contingent in nature. Entries affecting non contingent Account balances are
stored in STMT.ENTRY file , whether it is Customer account or Internal
account. These entries are used to produce Statements for Customers and
internal purposes for reconciliation of internal accounts.
Entries affecting Profit and Loss heads like interest , charges and commission
are stored in CATEG.ENTRY file. These entries update consolidation straight
from Category codes without any intermittent accounts.
RE.CONSOL.SPEC.ENTRY is passed for all other types of transactions.
Asset types help us to know whether the balance under a key is contingent or
non-contingent or accrued income or expenditure in nature. Contingent and
Non contingent Asset types are hard coded. Accrued income and expenditure
Asset types other than for Account interest accruals take value from respective
application level parameter tables. These will use the underlying Profit and
Loss category codes and not any alpha values. Transactions types are
maintained through TRANSACTION table.
Transaction types for RE.CONSOL.SPEC.ENTRY are hardcoded.

T24 Accounts - T3TAC - R11.1 233

 Account Search enquiries provide the list of accounts based on selection
criteria. Today’s Account Balance enquiry has the option of giving either the
customer or account number and we can drill down to view the accounting
entries for the day, entries since last statement date and also projected forward
movements in the account.
Average Account Balance enquiry for a given period can be generated . It
provides account wise debit and credit balances. Entries for Today enquiry
details the accounting entries for the day. We can drill down to look into
individual transactions. Entries for the Given dates enquiry provides the
accounting entries for a given date for an account.
Balance on Statement Date enquiry provides the gist of statement for an
account. We can view the entries for a given account from the last statement
date. Details of the interest rate changes made in an account can be displayed
though the Interest Rate changes for Account enquiry. We can enquire the
details of the locked account under various dates and also the charges that are
unpaid for an account by selecting criteria account.
Further other enquires are available for viewing primary and joint accounts,
Inactive accounts, details of credit and debit interest posted, credit and debit
interest accrued and credit and debit interest corrected.

T24 Accounts - T3TAC - R11.1 234

 STMT.ENT.BOOK Enquiry gives booking date wise debit and credits for a
date and period. When this enquiry is not showing correct balances, the files
that need to be accessed for correction are STMT.PRINTED ,
ACCT.STMT.PRINT and ACCOUNT.STATEMENT.
If VAL.ENT.BOOK is not showing the correct balances, files to be corrected
are STMT.VAL.ENTRY, ACCT.STMT.PRINT and ACCOUNT.STATEMENT.

T24 Accounts - T3TAC - R11.1 235

T24 Accounts - T3TAC - R11.1 236
T24 Accounts - T3TAC - R11.1 237
T24 Accounts - T3TAC - R11.1 238
T24 Accounts - T3TAC - R11.1 239
 It is an internal file containing details of Account Balances in ECB and
Activity used to calculate interest and charges. Details are held in separate
records for each Account for each month in which there has been any Activity
over the Account or in which the Value Dated Balance changes. This file is
also used to record booking date wise balances separately.
Details held in this file is for the calculation of interest which includes Value
Dated Balances, total Debit and Credit Turnover for each Value Date.
Details held for the calculation of charges include the total number of entries
with each different transaction Code processed during the month, and the total
value of the entries with each transaction Code. These details are held in the
record for the month in which the entries are processed, regardless of the Value
Dates of the entries.
Value Dated Balances are also used for calculation of Balance Requirement
charges and for determining whether a high enough Balance has been
maintained for waiving charges and for calculating Credit interest to offset
charges. Interest is calculated on Value Dated Balances. All entries over an
Account are considered to have a Value Date, which is the date on which the
entry affects the (value dated) balance for interest purposes.

T24 Accounts - T3TAC - R11.1 240

 ACCOUNT.COMPENSATION is an internal file containing details of groups
of Customer Accounts whose value dated balances and activity are combined
for the calculation of interest and charges. When Accounts are to be combined
for interest and charges, the main Account is specified in the
INTEREST.COMP.ACCT Field in the Account records for each of the sub-
accounts. Interest conditions applicable to the Main Account are applied to the
combined value dated balances and activity. Only Accounts in the same
Currency can be combined. Value dated balances and activity for each Account
are stored separately in the ACCT.ACTIVITY file and added together at the
time interest and charges are calculated.
ACCOUNT.LIQUIDATION is an internal file containing details of Accounts
which are used for booking the interest and charges calculated on other
Accounts. It provides a cross reference of all Accounts whose interest and
charges are booked to each Liquidation Account. If the interest and charges
calculated on an Account are to be booked to another Account, the Account to
which the amounts should be booked is entered in INTEREST.LIQU.ACCT
Field or INT.LIQU.TYPE,INT.LIQU.ACCT and INT.LIQ.CCY Fields in the
Account record of the originating Account.
ACCOUNT.CHARGE table is used , when charges in an account are to be
liquidated by another account, system maintains this record with details of
liquidation account as ID and main accounts which are liquidated by that.

T24 Accounts - T3TAC - R11.1 241

 ACCOUNT.CLOSED table maintains date wise record of accounts closed
ACCOUNT.OVERDRAWN is updated during close of business, for
processing of limits and accounts . It contains details of overdrawn accounts
which are not covered by a credit limit and credit limits which have been
exceeded. Details include the amount of the overdraft or excess, the date on
which it first became overdrawn and whether or not the balance or excess has
changed.
CUSTOMER.ACCOUNT is an internal file providing a reference between
each Customer and all Accounts belonging to that customer.
CUSTOMER.CCY.ACCT is an internal file providing a reference between
each Customer and all Current Accounts belonging to that customer in each
Currency. It is used by other modules for automatic selection of default
Accounts for receipt of funds etc.
GROUP.ACCOUNT table maintain condition group wise list of accounts.
NEW.COND.REFER when the condition group of an account has changed,
then details of old and new condition groups, account wise maintained.

T24 Accounts - T3TAC - R11.1 242

 ECB contains fields to display the updated account balance field, Date moved
fields and Exposure management fields.
ACCT.STMT.ENTRY is a system updated table that contains IDs of
Statement Entries records, account wise to be reported in the next cycle 1 of
Account Statement.
ACCT.ACTIVITY file will be feeding statement information uploaded from
STMT.ENTRY files.
EB.CONTRACT.BALANCES is a balance look up file which is updated
online and holds balances Asset type wise for consolidation. It also records
months for which ACCT.ACTIVITY balances are available for each account.
ACCOUNT.STATEMENT is a system maintained table which gets updated
for Account Statement date.

AC.STMT.SERVICE.DETAIL is a live file which contains

the details required for the generation of account statement handoff record.
This is further moved to delivery module. Account statements are produced
during COB. A separate process of handing over the Handoff record and also a
mapping process, as a service, runs in parallel with the COB job. This reduces
the time consumption of PRINT.ACCOUNT.STATEMENT job. The service
used for this purpose is AC.STMT.DELIVERY SERVICE.

T24 Accounts - T3TAC - R11.1 243

 Next to Customer, Account is central to all other applications in T24. We need
to have Customer type of accounts like Savings and Current accounts. We also
need accounts to reflect balance of our Nostro accounts held with outside
banks. In addition, all contract applications in T24 need accounts either
Customer type or Internal accounts for moving money be it for giving a loan
or taking a deposit. Even if a Customer does not have an account with the
bank, we need to have at least a Nostro account or internal accounts like
Suspense account or Cash account to deal with its assets and liabilities . This
diagram shows the dependencies of accounts with various applications. They
are grouped as customer related, interest related, statement related and
accounting related.
Based on the Condition. Priority the groups are formed and rules are set for
debit interest, credit interest and capitalisation rules . Interest related and
ledger fee related charges are set.
To control accounts posting restrictions and referral conditions are set up.
Operating rules of accounts are created.

T24 Accounts - T3TAC - R11.1 244

 We have come to the end of the session relating to ACCOUNT and other
related applications . We have seen the dependencies and linkages between
account module and T24 Core and other applications and also main business
features of the Account module.
We have also seen other related modules closely associated with customer type
of accounts like cheque, Account sweep and Image management.

T24 Accounts - T3TAC - R11.1 245

T24 Accounts - T3TAC - R11.1 246